Daniel Nashed 25 April 2016 17:14:43
In the last couple of weeks I spent a lot of time with customer Web Federated Login workshops and implementations.
Not sure what happened but suddenly everyone is interested in SAML. It looks like more and more customers are looking into that because they have already implemented SSO for other applications like O365.
In one case a customer had an existing F5 configuration. In one other case we had a customer with Windows 2012 R2 and ADFS 3.0.
Both configurations are not officially supported yet but we got it to work! Specially the F5 configuration was tricky. But in general both are just another SAML 2.0 implementation.
We officially asked if those two configurations can be officially supported. It looks like it is more testing and documentation effort than any code change that is needed.
But it is not yet an officially supported configuration. Implementing ADFS 3.0 is quite similar than ADFS 2.0.
Win2012 R2 ADFS 3.0
ADFS 3.0 in fact is a nicer implementation and does not need any IIS components. Also the SSO portal application is now implemented in a way that the UI can be completely customized. You can add you logo, change the CSS or could even build your complete own page.
Also the installation is easier. ADFS 3.0 comes with Win2012 R2 and just needs to be enabled as a separate role. In contrast earlier versions shipped with SAML 1.1 support and you and to separately download and install SAML 2.0.
The configuration is very similar but you cannot use the cookbooks 1:1. Some configuration details are now set via PowerShell commands.
For example if you need to disable the extended protection when working with Chrome.
Domino SAML Implementation
In two customer situations we ran into an odd issue. When initiating the SAML login from the SSO portal like ADFS (with ADFS 3.0 the portal looks prettier and more customers might directly use the portal) redirecting to the Domino HTTP server caused a strange behavior.
The URL invoked should have been the default server URL but there have been som random chars at the end of the URL. Tracing turned out that this was a day one issue with Domino Web Federated Login (WFL) and it was never thought of that the first request is the login request with a redirect from the Identity provider (IdP) in our case ADFS 3.0 or the F5 applicance.
Even Domino uses a IdP Initiated model the first request was always initiated by Domino.
Here is the flow that Domino uses.
- Browser hits the Domino Server for a resource that needs authentication
- User ist redirected to the IdP for authentication --> the URL contains ?loginToRp to tell the ADFS server where to return to after authentication. This is a ADFS specific parameter which is for example not understood by F5.
At the same time the server sets an undocumented cookie "DOMRELAYSTATE" which contains some data in binary format (base64 encoded) which contains the location to redirect to after login.
- User is authenticated at the IdP. Either via AD name and password or with a Kerberos ticket (Integrated Windows Authentication -- IWA) if configured and the user and workstation are in the current AD.
- Browser redirects back to Domino with the SAML post request
- After verifying the SAML data, the user is authenticated and a LTPA cookie is generated
- At the same time the server reads the "DOMRELAYSTATE" cookie, removes it and redirects the user to his original location
In our problem case the user had no "DOMRELAYSTATE" cookie which caused the server to add some garbage to the URL.
We got a hotfix for the issue which will hopefully make it into one of the next IFs. The SPR for this defect is SPR # MKINA8XN74.
So in general if you want to implement SAML right now I would use ADFS 3.0 and Windows 2012 R2 if you have the choice - even it is not yet supported by Domino.
But ADFS 3.0 is the much better product which is better supported by Microsoft. And it is a much cleaner implementation. No dependency on IIS as well!
- Comments