Saturday, March 29, 2014

Office 365 Federation Updates

There was some good information in this blog that really cleared the air on a few topics which I talk a lot about with customers - http://blogs.office.com/2014/03/06/announcing-support-for-saml-2-0-federation-with-office-365/

A lot of times I am asked, can authentication federation with Office 365 can be done with something other than Active Directory Federation Services (ADFS) and Active Directory (AD)? The answer has always been yes as there are other third-party STS servers that have been supported plus other LDAP directories are supported.

However with this recent announcement this story has been cleaned up a bit. Here are the high level facts you need to know:

  • Active Directory (AD) can be used to synchronize your directories to Office 365. You can use DirSync to do this. Everyone knows this. If you have multiple AD forests, you will need to use Forefront Identity Manager (FIM).
  • LDAP directories can also be synchronized with Office 365. Again you will need to use FIM to support this. Recommend that you talk with your licensing person at Microsoft. Remember a full FIM CAL is not needed when all you are using is the FIM synchronization service. I am not a licensing expert on FIM so I recommend you double check.
  • SAML 2.0 is now offered as an authentication federation option now with Office 365. This allows a whole host of STS identity providers to authenticate with Office 365. The important note is that SAML 2.0 support is for “passive authentication” scenarios which as you may know is used for browser based authentication.
  • Office 365 has supported and will continue to support WS-Federation and WS-Trust to support ADFS and other WS-* identity providers.
  • So what about the Rich Clients? When we are talking rich clients we are talking such client applications as Lync client, Office Desktop clients (Word, Excel, PowerPoint, Outlook, etc.), etc. In the Microsoft Office 365 world, it is not just browser only, there are tons of other clients that can to connect to Office 365 service. Authentication using these rich clients is referred to as “active authentication” which currently requires WS-Trust. If you want to have federated authentication and you need to support rich clients, you will need to use an STS identity provider that supports WS-Federation and WS-Trust. You will need to use either Active Directory Federation Services (ADFS) or a qualified solutions partner that can support this level of authentication. A list of third-party approved providers is listed here - http://technet.microsoft.com/en-us/library/jj679342.aspx and information about the program for getting third-party qualified is listed here - http://blogs.office.com/2014/01/30/the-works-with-office-365-identity-program-now-streamlined/.
  • So is the Rich Client scenario ever going to support SAML 2.0 and Passive Authentication? The answer is YES. It is reflected in the public roadmap of these two blogs http://blogs.office.com/2014/02/10/multi-factor-authentication-for-office-365/ and http://blogs.office.com/2014/03/06/announcing-support-for-saml-2-0-federation-with-office-365/. There will be an update to Office 2013 client applications, in the year 2014, which will allow Office 2013 client applications to support SAML 2.0 (or Shibboleth) passive authentication.

These changes in Office 365 federation authentication are great changes to supporting more enterprise scenarios.

No comments: