Skip to end of metadata
Go to start of metadata

In a previous article, Wajih detailed how to configure Office 365 and OpenAM in order to delegate authentication of Office 365 users to OpenAM, from a browser. Thanks to recent improvments to Microsoft rich clients, it's now possible to sign in OpenAM from those clients, and enable SSO between them.

Typical such clients include Outlook 2016, Skype Enterprise 2016, Word or Excel 2016, on the Windows platform. But Office 2013 clients with the Microsoft March 2015 update should also work, while not demonstrated here. Basically, rich clients that support the Microsoft ADAL library now support SAML flows.

For more information on Microsoft rich clients support for ADAL, see this page:

On the OpenAM side, the following changes are required in comparison with Wajih's article:

  • OpenAM needs to be upgraded to version 12.0.3 at least, in order to fully support ECP requests. The required fixes are OPENAM-3095 and OPENAM-6196

  • An authentication chain including the HTTP basic authentication module must be used in order to use Outlook's ActiveSync and AutoDiscovery features:
    at Outlook initialization time, a couple of SAML ECP requests are issued by Outlook, which include the user's credentials in an "Authorization: basic .." HTTP header.
    Thanks to the basic authentication module, OpenAM accepts those headers and returns a SAML assertion.


The following screenshots illustrates the required OpenAM configuration:



The following diagram illustrates the Outlook initialization:


The OpenAM Federation debug log will contain the following kind of lines (formatted for convenience):

SAML2Utils.createSOAPMessage: soap message = 

<soap-env:Envelope xmlns:soap-env="">


<ecp:Response xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"






 <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="s2bec6a95cabf8ae4cd30cfa928b60f017b1e926eb" InResponseTo="_7a1301f9-1edf-4b14-b238-8ca290a5b171" Version="2.0"

  IssueInstant="2015-12-10T16:40:35Z" Destination="">

  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> </saml:Issuer>

<samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">

 <samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Value="urn:oasis:names:tc:SAML:2.0:status:Success"> </samlp:StatusCode>






With other rich clients such as Skype Enterprise (formerly Lync), Excel or Word, the authentication flow is as follows:




  • The AutoDiscovery and/or the ActiveSync outlook features (as well as other features actually) can also be tested/demonstrated individually, without running Outlook or any other rich client, to diagnose any issue, thanks to the online Microsoft connectivity analyzer tool

  • If you don't plan to use Outlook, then you don't need support for ECP, which means there's no need to have a basic authentication module in your authentication chain.

  • On the client side, a window pops up at authentication time if you configured basic authentication as the first authentication module in your chain. Otherwise, the configured OpenAM login form is displayed in a Webview.

  • At the time of this article, there's no SOAP single logout endpoint available at Office 365. Moreover, when logging out of the Office 365 console from a browser, the SAML logout request doesn't contain the mandatory session index required to close the session on the OpenAM side. For these reasons, I'd currently suggest to monitor the number of sessions on the OpenAM side, and if possible set maximum timeout and idle timeout values accordingly for the OpenAM sessions.
  • In spite Office 365 accounts have to be defined in the cloud (for example either through the Office 365 administrator's web console or through the Powershell command line tool) and have a valid license, they don't necessarily appear in the Azure Active Directory users' branch. Said differently, to have an account in the Office 365 Active Directory and to be defined as a valid Office 365 user are two different things, at least in the case of Office 365 authentication delegation to an external identity provider.

Last minute: Due to recent changes (not implemented at the time this article was initially published) in Microsoft clients, you may now have to enable "modern authentication" on the Azure Exchange and Skype services in order for the solution to work. See this article for more details on how to do that.

  • No labels