Configure single sign-on

Single sign-on, also called identity federation, allows you and your users to access Microsoft cloud services with your Active Directory corporate credentials. Without single sign-on, you, the administrator, and your users will need to maintain separate user names and passwords for your online and on-premises accounts. Single sign-on requires both a security token service (STS) infrastructure and Active Directory synchronization.

An STS enables identity federation, extending the notion of centralized authentication, authorization, and SSO to Web applications and services located virtually anywhere, including perimeter networks, partner networks, and the cloud. When you configure an STS to provide single sign-on access with a Microsoft cloud service, you will be creating a federated trust between your on-premises STS and the federated domain you’ve specified in Windows Azure Active Directory.

Windows Azure AD supports single sign-on with either of the following security token services:

• Active Directory Federation Services (AD FS)
  
  
• Shibboleth Identity Provider
  
  

The topics in this section provide detailed information on the following:

• Single sign-on roadmap
  
  
• Prepare for single sign-on
  
  
• Checklist: Use AD FS to implement and manage single sign-on
  
  
• Use Shibboleth Identity Provider to implement single sign-on
  
  
• Use third-party identity providers to implement single sign-on
  
  
• Troubleshoot single sign-on
  
  

There is a clear benefit to users when you set up single sign-on: it lets them use their corporate credentials to access the cloud service that your company has subscribed to. Users don’t have to sign in again and remember multiple passwords.

In addition to the user benefits, there are many benefits to administrators:

• Policy control: The administrator can control account policies through Active Directory, which gives the administrator the ability to manage password policies, workstation restrictions, lock-out controls, and more, without having to perform additional tasks in the cloud.
  
  
• Access control: The administrator can restrict access to the cloud service so that the services can be accessed through the corporate environment, through online servers, or both.
  
  
• Reduced support calls: Forgotten passwords are a common source of support calls in all companies. If users have fewer passwords to remember, they are less likely to forget them.
  
  
• Security: User identities and information are protected because all of the servers and services used in single sign-on are mastered and controlled on-premises.
  
  
• Support for strong authentication: You can use strong authentication (also called two-factor authentication) with the cloud service. However, if you use strong authentication, you must use single sign-on. There are restrictions on the use of strong authentication. If you plan to use AD FS for your STS, see Configuring Advanced Options for AD FS 2.0 for more information.
  
  

A user’s experience with single sign-on varies based on how the user’s computer is connected to your company’s network, what operating system the user’s computer is running, and how the administrator has configured their STS infrastructure.

The following describes user experiences with single sign-on from within the network:

• Work computer on a corporate network: When users are at work and signed in to the corporate network, single sign-on enables them to access the cloud service without signing in again.
  
  

If the user is connecting from outside your company’s network or accessing services from particular devices or applications, such as in the following situations, you must deploy an STS proxy. If you plan to use AD FS for your STS, see Plan for and deploy AD FS for use with single sign-on for more information about how to set up an AD FS proxy.

• Work computer, roaming: Users who are logged on to domain-joined computers with their corporate credentials, but who are not connected to the corporate network (for example, a work computer at home or at a hotel), can access the cloud service.
  
  
• Home or public computer: When the user is using a computer that is not joined to the corporate domain, the user must sign in with their corporate credentials to access the cloud service.
  
  
• Smart phone: On a smart phone, to access the cloud service such as Microsoft Exchange Online using Microsoft Exchange ActiveSync, the user must sign in with their corporate credentials.
  
  
• Microsoft Outlook or other email clients: The user must sign in with their corporate credentials to access their email if they are using Outlook or an email client that is not part of Office; for example, an IMAP or POP client.
  
  If you are using Shibboleth as your STS, make sure to install the Shibboleth Identity Provider ECP extension in order for single sign-on to work with a smart phone, Microsoft Outlook or other clients. For more information, see Configure Shibboleth for use with single sign-on.
  
  

Concepts