{"id":15491,"date":"2014-03-06T08:00:10","date_gmt":"2014-03-06T16:00:10","guid":{"rendered":"http:\/\/www.microsoft.com\/?p=15491"},"modified":"2024-08-09T16:41:19","modified_gmt":"2024-08-09T23:41:19","slug":"announcing-support-for-saml-2-0-federation-with-office-365","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/microsoft-365\/blog\/2014\/03\/06\/announcing-support-for-saml-2-0-federation-with-office-365\/","title":{"rendered":"Announcing support for SAML 2.0 federation with Office 365"},"content":{"rendered":"\n

Editor\u2019s Note:
<\/strong>The Office 2013 Windows client update that is mentioned in this post has updated information here<\/a>.<\/em><\/p>\n\n\n\n

Paul Andrew is a technical product manager on the Office 365 team working on identity and commerce<\/i>. <\/i><\/p>\n\n\n\n

Today we\u2019re 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\u00a0, 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.<\/p>\n\n\n\n

\"SAML_01\"<\/figure>\n\n\n\n

Identity management in Office 365 using federated sign-in through SAML 2.0<\/i><\/p>\n\n\n\n

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).<\/p>\n\n\n\n

SAML 2.0 SP-Lite profile federation<\/h2>\n\n\n\n

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 \u2013 Identity<\/i> 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<\/i>\u2013 Identity<\/i> program. Once qualified, you will be listed by Microsoft as having completed integration testing, and this provides confidence to customers in the federation interoperability.<\/p>\n\n\n\n

LDAP v3 directory synchronization<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

Future roadmap for Office desktop applications and passive authentication<\/h2>\n\n\n\n

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\u2019s 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.<\/p>\n\n\n\n