SharePoint 2013 Online App Development

Table of Contents

• Apps
• Developer Site Settings
• ‘Napa’ Office 365 Development Tools
• Using Napa Office 365 Development Tools
• Using Visual Studio 2012

Apps

Apps are new type of solution that help to extend Microsoft Office 2013 product features to fulfill business demands. The new Office solution type Apps for Office are built on web technologies like HTML, CSS, JavaScript, REST, etc. The Office Apps solutions will be supported in Microsoft Excel Web App, Microsoft Outlook 2013, Microsoft Outlook Web App, Microsoft Project Professional 2013, Microsoft Word 2013, Microsoft Excel 2013, Microsoft SharePoint 2013 and Microsoft Exchange 2013.

An App for Office is essentially a webpage that is hosted inside an Office client/web application. You can use Apps to extend the functionality of a document, email message, meeting request, or appointment. Apps can run in multiple environments and clients, including Office desktop clients, Office Web Apps, mobile browsers, and also on-premises and in the cloud.

The following is the SharePoint Administration Center control for managing Apps in Microsoft Office 365 – SharePoint 2013 Online.

Apps Building Blocks

The basic components of an App for Office are XML manifest file and webpage. The manifest defines configuration, settings and points to the webpage that implements the App UI and custom business logic.

App Types and Extensibility

App is classified as four main categories and each category of app will support its corresponding Office products.

• App for SharePoint
• Task pane App for Office
• Content App for Excel
• Mail App for Office

App for SharePoint

SharePoint 2013 presents a Cloud App Model that facilitates you to create apps. Apps for SharePoint are self-contained sections of functionalities using standards-based technologies such as HTML5, JavaScript, and OAuth that extend the capabilities of a SharePoint website.

Apps have a light imprint because they don't actually install on the host server, and that means they don't overload a SharePoint site with unnecessary API calls.

Cloud App Model offers users to discover and download apps from the SharePoint Store or from their organization's private App Catalog and install them on their SharePoint sites.

‘Napa’ Office 365 Development Tools

For creating Apps for Microsoft Office 2013, as we all know now Apps contain manifest XML and webpage file. To do this, we can use any tool which can help us to save the file in text format. But to simplify the development process, Microsoft has given full support in Visual Studio 2012 by using its project templates, development environment, and debugging tools. Apart from Visual Studio 2012, this time Microsoft has come up with new web based development tool called "Napa" Office 365 Development Tools.

Here we’re going to focus on "Napa" Office 365 Development Tools in detail. We will see how to create, manage and deployments are supported in the Napa Office 365 Development Tools.

To get started with Apps development for the Office 365 – SharePoint 2013, login to the Office 365. After successful login, the next page will be Office 365 admin center; in the same page you can find the developer site navigation where you get Napa development tools.

Another option is navigate to the SharePoint 2013 administration center and under the site collection list, you can find the developer site collection URL.

The following screen capture image will help you to navigate to the SharePoint Administrator center.

Once you navigated to the SharePoint Administrator Center, you see the developer site collection. Login to the developer site collection and you can see the navigation for the Napa tool download.

The following is the navigation for the Napa tool download available in the home page of the developer site.

Then you will be navigated to the Office apps store download site of the download.

Following is the step by step process of installing the Napa development tool to your environment.

This will be added to the trusted list of service in the browser (preferably Microsoft Internet Explorer 9 or later version)

License of the office app will be managed under the login in which we have downloaded.

Image Title Name

App Part

What is an App Part? It is a type of Web Part that is represented by the ClientWebPart class. In a way by which an App for SharePoint 2013 can be appeared is through an App part. App Part, now in some of your minds will raise a question - is this replacement for WebPart? If not, what is the difference over WebPart and does it comes with any advantages.

Here it is App Part, not replacement for WebPart. An App Part is essentially a wrapper for an IFrame that would host a page of the App. In addition to acting as a Wrapper, like a WebPart, an App part can have custom properties that users can set in a tool part.

• ClientWebPart.aspx - In a SharePoint Hosted App, this will act as your App Part Interface.
• Default.aspx - is the start page for the App. This will provide the full page App experience, which will be the landing page after the deployment of the App.
• App.css – This will contain the default styling and based on the requirement, we can use the same CSS file to add any custom styles.
• App.js – In this JavaScript file, it contains the required JavaScript and has few lines of pre-generated code to start your SharePoint App development.

Using ‘Napa’ Office 365 Development Tools

Once after installing the Napa development tool in your development environment, go to the developer site and under the site content section, you find the installed apps.

We can manage permission levels and license management for Napa app as well as all apps installed in the site.

Now let’s take a look at a simple example for how to create an app to show from Office 365 – SharePoint 2013 pages. Let’s start exploring the App development using Napa and in the later part of this chapter, we will see more logical examples.

Click on the Napa and the following page will appear for selecting the name for the app.

The following is the default project generated using Napa, which is powered by Visual Studio 2012.

By default, App solution is generated with four folders and each folder contains related app files. First the content folder which contains the App.css file, Images folder contains the Appicon.png file, Pages folder contains theClientWebPart.aspx and Default.aspx and Scripts folder contains the Apps.js file.

Apart from the default files, as per the development needs, we can add new files to our App development. Right click on the folder under which you need to add file. The support files to add to our existing solution are JavaScript file, Style Sheet and SharePoint Web page.

App properties can be defined in the properties windows, where you can define the name, permission, access and remote endpoints.

Creating App using Napa

1. Open the SharePoint Admin Center
2. Under the site collection, open the developer site.
3. Open the "Napa" Office 365 Development Tools from the developer Site Collection.
4. Now you will be navigated to https://www.napacloudapp.com/.
5. In the following page, you can see “What type of app do you want to build?” with App for SharePoint, Task pane App for Office, Content App for Excel and Mail App for Office project options.
6. Enter the project name and click Create.

After creating the App using Napa, the project will auto create some folders and files as we have explained in beginning of this chapter. The following are the four important files we must know its purpose and needs before programming an App.

• ClientWebPart.aspx
• Default.aspx
• App.css
• App.js
• AppIcon.png

Here in this example, we will write JavaScript code to retrieve the list/library in the SharePoint Web Site and display the list/library titles in dropdown list.

Open the Default.aspx file under the Pages folder and add HTML tag to create a dropdown list. Here in this example, we have created dropdown list in the name ‘ListItemListBox’.

Hide   Copy Code

<asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">
    <div>
     <select id="ListItemListBox"></select>
    </div>
</asp:Content>

Now we need to write JavaScript to retrieve the list names from the current app running context and populate the list names in the dropdown list. Open the file named App.js under the folder name Scripts.

The following is code which will be generated while creating the project using the Napa tool. Each part code is explained with comments to understand the purpose of its existence.

Hide   Shrink    Copy Code

var context;
var web;
var user;

// This code runs when the DOM is ready. It ensures the SharePoint
// script file sp.js is loaded and then executes sharePointReady()
$(document).ready(function () {
    SP.SOD.executeFunc('sp.js', 'SP.ClientContext', sharePointReady);
});

// This function creates a context object which is needed to use the SharePoint object model
function sharePointReady() {
    context = new SP.ClientContext.get_current();
    web = context.get_web();

    getUserName();
}

// This function prepares, loads, and then executes a SharePoint query to get the
// current users information
function getUserName() {
    user = web.get_currentUser();
    context.load(user);
    context.executeQueryAsync(onGetUserNameSuccess, onGetUserNameFail);
}

// This function is executed if the above call is successful
// It replaces the contents of the 'helloString' element with the user name
function onGetUserNameSuccess() {
    $('#message').text('Hello ' + user.get_title());
}

// This function is executed if the above call fails
function onGetUserNameFail(sender, args) {
    alert('Failed to get user name. Error:' + args.get_message());
}

Now let’s see the code to retrieve the list/library names from the current context of the web and populate the same in the dropdown list. We will write a GetListsToDisplay() which get the list/library name loaded from context and on the successful retrieval from the context, the following function will populate to the dropdown list for display. If the loading fail, the GetListsToDisplayFail(sender, args) will display the error message.

Hide   Shrink    Copy Code

function GetListsToDisplay() {
    // Get the available SharePoint lists, and then set them into
    // the context.
    this.web = context.get_web();
    this.lists = this.web.get_lists();
    this.context.load(this.lists);
    this.context.executeQueryAsync(Function.createDelegate
    (this, this.GetListsToDisplaySucess),
    Function.createDelegate(this, this.GetListsToDisplayFail));
}

function GetListsToDisplaySucess(sender, args) {
    // Success getting the lists. Set references to the list
    // elements and the list of available lists.
     var listEnumerator = this.lists.getEnumerator();
     var selectListBox = document.getElementById("ListItemListBox");
     if (selectListBox.hasChildNodes()) {
         while (selectListBox.childNodes.length >= 1) {
             selectListBox.removeChild(selectListBox.firstChild);
         }
     }
    // Traverse the elements of the collection, and load the name of
    // each list into the dropdown list box.
     while (listEnumerator.moveNext()) {
         var selectOption = document.createElement("option");
         selectOption.value = listEnumerator.get_current().get_title();
         selectOption.innerText = listEnumerator.get_current().get_title();
         selectListBox.appendChild(selectOption);
     }
}

function GetListsToDisplayFail(sender, args) {
    // Lists couldn’t be loaded - display error.
    alert('failed to get list. Error:' + args.get_message());
}

And now, click on the Run Project button; appear near the status bar of the Internet Explorer.

Now your project will be packaged and installed on your SharePoint server. If this project is already running, the project uninstalls the previous version and installs the latest version.

The following screen capture will show the result for the code we have written in the JavaScript.

Visual Studio 2012, Tools and Client Components

In Microsoft Visual Studio 2012, you’ll find the agile processes, refined management tools, and robust testing infrastructure that are necessary for creating fast results.

An Office 365 Developer Site is also the best option if you want to deploy directly from Visual Studio 2012 when you are developing and testing your apps for SharePoint, because it's not possible to deploy from Visual Studio 2012 to any site other than a Developer Site.

Note: The features like IntelliTrace is part of Visual Studio Ultimate 2012 version only.

To set up an Office 365 – SharePoint 2013 App development using Visual Studio 2012, we need to install Office Developer Tools for Visual Studio 2012, and the SharePoint Client Components.

When you install Visual Studio 2012, Office Developer Tools for Visual Studio 2012, and the SharePoint Client Components, you get all of templates and tools that you need, and the following resources that enable you to develop apps for SharePoint on your developer computer without installing SharePoint 2013.

The following are the tools and components needed for Office 365 – SharePoint 2013 development along with Visual Studio 2012.

• Office Developer Tools for Visual Studio 2012
• SharePoint Client Components
• Windows Identity Foundation SDK
• Windows Identity Foundation Extensions
• Workflow Tools SDK and Workflow Client SDK

Note: The Visual Studio 2012 Express Edition is not supported for SharePoint 2013 development works.

Now you have six project templates available for SharePoint 2013 development. In the total of six, for five project templates; to develop SharePoint solutions or browse SharePoint connections in Server Explorer, SharePoint must be installed on the local system. The following are the list of five project templates which needed SharePoint 2013 installed locally or SharePoint connection in server explorer to do remote development.

• SharePoint 2013 - Empty Project
• SharePoint 2013 - Silverlight Web part
• SharePoint 2013 - Visual Web Part
• SharePoint 2013 - Import Solution Package
• SharePoint 2013 - Import Reusable 2010 Workflow

The following is the Visual Studio 2012 project template used to develop App for SharePoint 2013 using client components. This does not need SharePoint 2013 installed locally.

• App for SharePoint 2013

Creating App using Visual Studio 2012

In our sample, we will create an App which will automate the Stationary request process in an Office. First, we will create a form to fill the details for a stationary request and we will demonstrate how to add approval process to the form.

1. Open Visual Studio 2012
2. Create New Project and under the Installed Project Templates > Office/SharePoint click on the App for SharePoint 2013 Visual C#.
   
3. Than Click Ok.
4. Enter the project name and click Create.

In the next wizard, we have to name the App and have to give the SharePoint 2013 developer site.

Once after entered the SharePoint Site URL, click validate button. It will open Office 365 login page and once after entering the valid credentials, the following success message will appear.

After clicking the finish button in the New App for SharePoint window, the following solution explores view in Visual Studio 2012 for SharePoint 2013 App project.

Once after the project has been created successfully, please click on the App project and validate the Site URL property as below:

Summary

This article is an introduction to custom development with Office 365 SharePoint 2013 Online. We will do some advanced development in future articles.

Ref : http://www.codeproject.com/Articles/690015/SharePoint-Online-App-Development-Part

Choosing a sign-in model for Office 365 (office 365 cloud Identity / synchronized Identity / Federated Identity )

We get a lot of questions about which of the three identity models to choose with Office 365. Which of these models you choose will impact where you manage your user accounts for Office 365 and how those user sign-in passwords are verified. In this post I’ll describe each of the models, explain how to move between them, and provide guidance on how to choose the right one for your needs.

Three identity models for Office 365

In the diagram above the three identity models are shown in order of increasing amount of effort to implement from left to right. Our recommendation for successful Office 365 onboarding is to start with the simplest identity model that meets your needs so that you can start using Office 365 right away. Then, as you determine additional necessary business requirements, you can move to a more capable identity model over time. The way to think about these is that the Cloud Identity model is the simplest to implement, the Federated Identity model is the most capable, and the Synchronized Identity model is the one we expect most customers to end up with. Let’s look at each one in a little more detail.

Cloud Identity. In this model a user is created and managed in Office 365 and stored in Azure Active Directory, and the password is verified by Azure Active Directory. Azure Active Directory is the cloud directory that is used by Office 365. There is no equivalent user account on-premises, and there is nothing that needs to be configured to use this other than to create users in the Office 365 admin center.

Synchronized Identity. In this model the user identity is managed in an on-premises server and the accounts and password hashes are synchronized to the cloud. The user enters the same password on-premises as they do in the cloud, and at sign-in the password is verified by Azure Active Directory. This model uses the Microsoft Azure Active Directory Sync Tool (DirSync).

Federated Identity. This model requires a synchronized identity but with one change to that model: the user password is verified by the on-premises identity provider. This means that the password hash does not need to be synchronized to Azure Active Directory. This model uses Active Directory Federation Services (AD FS) or a third- party identity provider.

You can switch between the models

We recommend that you use the simplest identity model that meets your needs. If your needs change, you can switch between these models easily. Here’s a description of the transitions that you can make between the models.

Cloud Identity to Synchronized Identity. This transition is simply part of deploying the DirSync tool. You may have already created users in the cloud before doing this. If you switch from the Cloud Identity model to the Synchronized Identity model, DirSync and Azure Active Directory will try to match up any existing users. There are two ways that this user matching can happen. The first one occurs when the users in the cloud have previously been synchronized from an Active Directory source. In this case they will have a unique ImmutableId attribute and that will be the same when synchronization is turned on again. Users with the same ImmutableId will be matched and we refer to this as a “hard match.”

The second way occurs when the users in the cloud do not have the ImmutableId attribute set. In this case we attempt a “soft match,” which looks at the email attributes of the user to find ones that are the same. If we find multiple users that match by email address, then you will get a sync error. If you want to be sure that users will match using soft-match capabilities, make sure their PrimarySMTP addresses are the same both in Office 365 and in the on-premises Active Directory. If all of your users are entered in the cloud but not in your Active Directory, you can use PowerShell to extract them and then you can import them into Active Directory so that soft match will work.

Synchronized Identity to Federated Identity. This transition is required if you deploy a federated identity provider, because synchronized identity is a prerequisite for federated identity. The user identities are the same in both synchronized identity and federated identity. Because of this, changing from the Synchronized Identity model to the Federated Identity model requires only the implementation of the federation services on-premises and enabling of federation in the Office 365 admin center. Switching from Synchronized Identity to Federated Identity is done on a per-domain basis. The operation both defines the identity provider that will be in charge of the user credential validation (often a password) and builds the federation trust between Azure Active Directory and the on-premises identity provider. When you switch to federated identity you may also disable password hash sync, although if you keep this enabled, it can provide a useful backup, as described in the next paragraph.

Federated Identity to Synchronized Identity. You can convert a domain from the Federated Identity model to the Synchronized Identity model with the PowerShell command Convert-MsolDomainToStandard. Since the password sync option in DirSync is a recent addition, some customers will make this transition to take advantage of that and simplify their infrastructure. This transition can also be a useful backup in case there is a failure with the federated identity provider, because any failure with the federated identity provider—including the physical server, the power supply, or your Internet connectivity—will block users from being able to sign in.

The switch back from federated identity to synchronized identity takes two hours plus an additional hour for each 2,000 users in the domain. Once you have switched back to synchronized identity, the user’s cloud password will be used. We recently announced that password hash sync could run for a domain even if that domain is configured for federated sign-in. Previously Azure Active Directory would ignore any password hashes synchronized for a federated domain. This recent change means that password hash sync can continue for federated domains, so that if you switch from Federated Identity to Synchronized Identity the password validation will be available immediately. If you do not have password sync configured as a backup and you switch from Federated Identity to Synchronized Identity, then you need to configure that, assign passwords with the set-MsolUserPassword PowerShell command, or accept random passwords.

Synchronized Identity to Cloud Identity. You can turn off directory synchronization entirely and move to cloud-managed identities from within the Office 365 admin center or with the PowerShell command Set-MsolDirSyncEnabled. This update to your Office 365 tenant may take 72 hours, and you can check on progress using the Get-MsolCompanyInformation PowerShell command and by looking at the DirectorySynchronizationEnabled attribute value. There is a KB article about this.

When to choose the Cloud Identity model

Choosing cloud-managed identities enables you to implement the simplest identity model, because there is no on-premises identity configuration to do. All you have to do is enter and maintain your users in the Office 365 admin center. This is likely to work for you if you have no other on-premises user directory, and I have seen organizations of up to 200 users work using this model.

You may also choose the Cloud Identity model if you have a very complex on-premises directory and simply want to avoid the work to integrate with it. These complexities may include a long-term directory restructuring project or complex governance in the directory. If you have an existing on-premises directory, but you want to run a trial or pilot of Office 365, then the Cloud Identity model is a good choice, because we can match users when you want to connect to your on-premises directory.

It is most common for organizations with an existing on-premises directory to want to sync that directory to the cloud rather than maintaining the user directory both on-premises and in Office 365. In that case, either password synchronization or federated sign-in are likely to be better options, because you perform user management only on-premises.

To sum up, you would choose the Cloud Identity model if you have no on-premises directory, if you have a very small number of users, if your on-premises directory is undergoing significant restructuring, or if you are trialing or piloting Office 365.

When to use the Synchronized Identity model

The Synchronized Identity model is also very simple to configure. It requires you to have an on-premises directory to synchronize from, and it requires you to install the DirSync tool and run a few other consistency checks on your on-premises directory. This is described in my recent blog post Synchronizing your directory with Office 365 is easy. Before June 2013 this model did not include password synchronization and users provisioned using synchronized identity had to create new cloud passwords for Office 365. This was a strong reason for many customers to implement the Federated Identity model. Now that password synchronization is available, the Synchronized Identity model is suitable for many customers who have an on-premises directory to synchronize with and their users will have the same password on-premises and in the cloud.

In addition to leading with the simplest solution, we recommend that the choice of whether to use password synchronization or identity federation should be based on whether you need any of the advanced scenarios that require federation. I’ll talk about those advanced scenarios next. However if you don’t need advanced scenarios, you should just go with password synchronization. You can also use the Synchronized Identity model when you ultimately want federated identity, but you are running a pilot of Office 365 or for some other reason you aren’t ready to dedicate time to deploying the AD FS servers yet.

To sum up, you would choose the Synchronized Identity model if you have an on-premises directory and you don’t need any of the specific scenarios that are provided for by the Federated Identity model.

When to use the Federated Identity model

As mentioned earlier, many organizations deploy the Federated Identity model just so that their users can have the same password on-premises and in the cloud. With the addition of password hash synchronization to the Synchronized Identity model in July 2013, fewer customers are choosing to deploy the Federated Identity model, because it’s more complex and requires more network and server infrastructure to be deployed.

All of the configuration for the Synchronized Identity model is required for the Federated Identity model. Because of this, we recommend configuring synchronized identity first so that you can get started with Office 365 quickly and then adding federated identity later.

The following scenarios are good candidates for implementing the Federated Identity model. If none of these apply to your organization, consider the simpler Synchronized Identity model with password synchronization.

Existing infrastructure

Scenario 1. You already have an AD FS deployment. If you already have AD FS deployed for some other reason, then it’s likely that you will want to use it for Office 365 as well. This also likely means that you now have multiple SaaS applications that are using AD FS federated sign-in and Azure Active Directory is connecting to the existing infrastructure that you maintain for AD FS with little additional overhead. Of course, having an AD FS deployment does not mandate that you use it for Office 365. You can still use password hash sync for Office 365 and your AD FS deployment for other workloads.

Scenario 2. You already use a third-party federated identity provider. If your company uses a third- party, non-Microsoft, identity provider for authentication, then federated identity is the right way to do that. Third-party identity providers do not support password hash synchronization. Microsoft has a program for testing and qualifying third-party identity providers called Works with Office 365 – Identity.

Scenario 3. You use Forefront Identity Manager 2010 R2. Forefront Identity Manager 2010 R2 can be used to customize the identity provisioning to Azure Active Directory with the Forefront Identity Manager Connector for Microsoft Azure Active Directory. It offers a number of customization options, but it does not support password hash synchronization.

Technical requirements

Scenario 4. You have multiple forests in your on-premises Active Directory. The DirSync tool does not support multiple forests. Because of this, if you are synchronizing multiple forests you need to either use Forefront Identity Manager 2010 R2 with the Forefront Identity Manager Connector for Microsoft Azure Active Directory or the new Azure Active Directory Sync Services. None of these alternate synchronization tools currently support password hash sync; hence users would not automatically have the same password on-premises and online without federated identity. Before proceeding with such a deployment, you may also consider consolidating your forests so that you can use the DirSync tool, which supports only one forest. Forest consolidation is described in this TechNet article.

Azure AD Sync Services can support all of the multi-forest synchronization scenarios, which previously required Forefront Identity Manager 2010 R2. This means that AD FS is no longer required if you have multiple on-premises forests and this requirement can be removed. Read more about Azure AD Sync Services here.

Scenario 5. You have an on-premises integrated smart card or multi-factor authentication (MFA) solution. Azure Active Directory does not have an extensible method for adding smart card or other authentication providers other than by sign-in federation. Often these authentication providers are extensions to AD FS, where Office 365 sign-in can take advantage of them through federation with the AD FS provider. Azure Active Directory does natively support multi-factor authentication for use with Office 365, so you may be able to use this instead.

Scenario 6. Custom hybrid applications or hybrid search is required. Custom hybrid application development, such as hybrid search on SharePoint or Exchange or a custom application on SharePoint, often requires a single authentication token to be used both in the cloud and on-premises. This is more than a common password; it is a single sign-on token that can be passed between applications for user authentication. This is only for hybrid configurations where you are undertaking custom development work and require both the on-premises services and the cloud services to be authenticated at the same time.

Scenario 7. Web-accessible forgotten password reset. For a federated user you can control the sign-in page that is shown by AD FS. It is possible to modify the sign-in page to add forgotten password reset and password change capabilities. This feature is not provided with AD FS but can be manually added during deployment of your AD FS implementation, as described on TechNet. You cannot edit the sign-in page for the password synchronized model scenario. Alternatively, Azure Active Directory Premium is an additional subscription that can be added to an Office 365 tenant and includes forgotten password reset for users in any of the three Identity models.

Policy requirements

Scenario 8. You require sign-in audit and/or immediate disable. With federated identity using AD FS, each sign-in attempt is logged in the standard Windows event log in the same way that on-premises sign-in attempts are logged. You can also disable an account quickly, because disabling the account in Active Directory will mean all future federated sign-in attempts that use the same Active Directory will fail (subject to internal Active Directory replication policies across multiple domain controller servers and cached client sign-in tokens). Sign-in auditing and immediate account disable are not available for password synchronized users, because this kind of reporting is not available in the cloud and password synchronized users are disabled only when the account synchronization occurs each three hours. An alternative for immediate disable is to have a process for disabling accounts that includes resetting the account password prior to disabling it. The password change will be synchronized within two minutes to Azure Active Directory and the user’s previous password will no longer work. Alternatively, you can manually trigger a directory synchronization to send out the account disable.

Scenario 9. Single sign-on is required. Password synchronization provides same password sign-on when the same password is used on-premises and in Office 365. With single sign-on, you can sign in to your Windows PC that is connected to your Active Directory domain and you do not need to re-enter your password when you connect to Office 365. This requires federated identity and works because your PC can confirm to the AD FS server that you are already signed in. An alternative to single sign-in is to use the Save My Password checkbox. This stores the user’s password in Windows Credential Manager (CredMan), where it is secured by the login credentials for the PC, and the user can sign in to their PC to unlock the passwords that CredMan uses. Note that the Outlook client does not support single sign-on and a user is always required to enter their password or check Save My Password.

Scenario 10. Require client sign-in restrictions by network location or work hours. There are two features in Active Directory that support this. Client Access Policy is a part of AD FS that enables limiting user sign-in access based on whether the user is inside or outside of your company network, or whether they are in a designated Active Directory group and outside of your company network. For users who are to be restricted you can restrict all access, or you can allow only ActiveSync connections or only web browser connections. In addition, Active Directory user policies can set login restrictions and are available to limit user sign-in by work hours. Federation delegates the password validation to the on-premises Active Directory and this means that any policies set there will have effect.

Scenario 11. Policy preventing synchronizing password hashes to Azure Active Directory. A small number of customers will have a security policy that precludes synchronizing password hashes to Azure Active Directory. In that case, you would be able to have the same password on-premises and online only by using federated identity. Microsoft is strongly committed to the security of all customer data. We encourage security professionals to review our Office 365 Trust Center. Also, we have details about how password hashes are synchronized in the TechNet article Implement Password Synchronization, and we have additional security guidance about password hash synchronization published on TechNet.

To sum up, you should consider choosing the Federated Identity model if you require one of the 11 scenarios above.

Recent enhancements change the landscape

Recent enhancements have improved Office 365 sign-in and made the choice about which identity model you choose simpler. The guidance above for choosing an identity model that fits your needs includes consideration of all of these improvements, but bear in mind that not everyone you talk to will have read about them yet.

• In June 2013 password hash sync was added to the DirSync tool so that the same password would be available on-premises and online.
• In October 2013 we released Windows Server 2012 R2 including AD FS.
• In November 2013 we added support for the DirSync tool to run on one of your existing Domain Controllers. This can simplify the deployment for some users with small directories.
• In February 2014 we introduced multi-factor authentication for Office 365, which is available for password hash sync users. Prior to this you would require federated sign-in to support any multi-factor authentication.
• In April 2014 Azure Active Directory Sync Services was released in preview to support multi-forest sync.
• In April 2014 Azure Active Directory Premium including Password Reset was released.
• In April 2014 use of alternate sign-in ID reducing dependency on UPN was added.
• In May 2014 password hash sync added the capability to act as a sign-in backup for federated sign-in.
• By the end of 2014 Office client applications are planned to support passive authentication models.

The three identity models you can use with Office 365 range from the very simple with no installation required to the very capable with support for many usage scenarios. By starting with the simplest identity model that meets your needs, you can quickly and easily get your users onboarded with Office 365. Later you can switch identity models, if your needs change.

Ref: https://blogs.office.com/2014/05/13/choosing-a-sign-in-model-for-office-365/