Skip to main content
Microsoft 365
Subscribe
3 min read

Announcing support for SAML 2.0 federation with Office 365

By

Editor’s Note:
The Office 2013 Windows client update that is mentioned in this post has updated information here.

Paul Andrew is a technical product manager on the Office 365 team working on identity and commerce.

Today we’re announcing Security Assertion Markup Language (SAML) 2.0 as a federation option for Office 365 customers. This is part of a set of new features that benefit Office 365 customers who are using an on-premises Identity Provider other than Active Directory. Together, they provide account synchronization, sign-in federation and wider use of passive authentication which enables single sign-on for Office web-based applications and, in the future, for Office desktop clients. To take advantage of these new features , an identity provider needs to support LDAP v3 and SAML 2.0 with the SP-Lite Profile. All Office 365 identity management uses Windows Azure Active Directory (Windows Azure AD). Now, you can configure Windows Azure AD for use with SAML 2.0. Windows Azure AD already supports WS-Federation, WS-Trust and Shibboleth for sign-in federation. SAML 2.0 is an additional, commonly-used federation standard for user sign-in. With it, the application, such as Office 365, shows the sign-in web form on behalf of the identity provider and the identity provider makes the authorization decision. The authorization decision is passed back to Office 365 using a SAML token.

SAML_01

Identity management in Office 365 using federated sign-in through SAML 2.0

In this block diagram of Office 365 identity management,  the account sync needs to occur from the on-premises directory to Windows Azure AD (orange arrow). The federated sign-in happens from Windows Azure AD when a sign-in request occurs (blue arrow).

SAML 2.0 SP-Lite profile federation

Sign-in federation with SAML 2.0 means that customers who have a directory on-premises that uses SAML 2.0 can federate directly with Office 365 for passive authentication scenarios. Passive authentication scenarios are those where the user signs in through a web form shown by the identity provider. Microsoft will continue to also support WS-Federation and WS-Trust for use with Active Directory Federation Services and other WS-* identity providers that are qualified in the Works with Office 365 – Identity program. If you are an identity provider using SAML 2.0 for federation with Office 365, we encourage you to test and get qualified for the requirements of the Works with Office 365– Identity program. Once qualified, you will be listed by Microsoft as having completed integration testing, and this provides confidence to customers in the federation interoperability.

LDAP v3 directory synchronization

Before users can use federated sign-in, their accounts must be synchronized to Windows Azure AD. You can use Forefront Identity Manager 2010 R2 with the Forefront Identity Manager Connector for Generic LDAP to synchronize accounts from a directory that supports LDAPv3. Note that for Office 365 connectivity, Forefront Identity Manager 2010 R2 also requires the Windows Azure Active Directory Connector for FIM 2010 R2. The DirSync tool and writing a PowerShell script that uploads the accounts are other Microsoft solutions for synchronizing accounts to Windows Azure AD.

Future roadmap for Office desktop applications and passive authentication

Most Office desktop applications require active authentication which cannot be accomplished with SAML 2.0. Active authentication currently requires a WS-Trust implementation at the identity provider. This means that today, if you use a SAML 2.0 based identity provider, it’s not possible to support a number of Office 365 usage scenarios that include Office desktop applications. A few weeks ago, in a blog post titled Multi-Factor Authentication for Office 365, we announced future updates to the Office desktop applications to support native multi-factor authentication. These updates will also enable SAML 2.0 passive authentication from Office desktop applications. Note that until these new updates are available in the Office desktop applications, the following scenarios are blocked when using SAML 2.0 or Shibboleth.

  • Lync desktop client
  • Applications such as Word, Excel, PowerPoint, Visio, etc. when accessing files from SharePoint Online
  • Office 365 ProPlus licensing for Office desktop applications
  • PowerShell access to Office 365
  • Outlook desktop client (unless you have an ECP endpoint on your identity provider)
  • Mobile clients connecting to Exchange Online (unless you have an ECP endpoint on your identity provider)

The update to the Office 2013 client applications is expected to be released later in 2014. Until then, these applications require WS-Federation and WS-Trust as implemented by either Active Directory Federation Services or by qualified partner solutions in the Works with Office 365 – Identity program.

Other options for sign-in federation

In addition to SAML 2.0 as discussed in this post, Windows Azure AD also supports the following federation options. You can read about each of these on TechNet in the article Directory Sync with Single Sign-On Scenario.

  • Active Directory Federation Services for federation with Active Directory
  • Shibboleth, which is a directory commonly used in academic organizations
  • Partners qualified in the Works with Office 365 – Identity program

– Paul Andrew @pndrw