How to achieve a “real” SSO with MS ADFS from your mobiles

There are already a few very good documentations here in SCN on how to achieve SIngle-Sign-On for e.g. SAP FIORI using Microsoft’s ADFS as Identity Provider (IdP).
This is all working very well with so called Service Provider (SP) initiated SAML logon, but there is one big pain point:
If you want to use X.509 certifictates for external (i.e. internet) authentication, ADFS will always present you its login page with a link to X.509 authentication (if enabled on AFDS per policy).
For our endusers here this was a little bit disturbing (not to say annoying).

This blog describes the necessary steps to achieve a direct logon with X.509 certificate on AFDS e.g. for a FIORI internet scenario.

I assume here that the following steps are aleady done
1) ADFS is reachable from the internet with MS standard mechanisms (Web Application Proxy WAP)
2) Metadata of SAP Service Provider and Idp have been successfully exchanged and trust has been etablished.
3) Our FIORI (or whatever) scenario is reachable in the internet (e.g. by WebDispatcher or Apache)
4) SAML2 configuration on SAP side has been made with the external URL (i.e. metadata.xml contains the external endpoint URLs)

First of all, we have be aware that this kind of logon cannot be achieved using Service Provider initiated logon, we have to change the whole procedure to IdP initiated and add two more parameters to our request: how do we want to authenticate and where do we want to go after successful authentication.

The whole thing now looks like:

https:///adfs/ls/IdpInitiatedSignon.aspx?logintorp=&RequestedAuthenticationContext=urn:oasis:names:tc:SAML:2.0:ac:classes:X509

logintorp = our SAP service provider
RequestedAuthenticationContext = logon method, in our case X.509

There are just a few things to consider:

1) you will most probably get an error message if you use the Relying Party identifyiers provided by the Service Provider’s metadata (http://someurl and https://someurl). it’s just too long. For us it helped to replace the two entries in ADFS wth some very short alias.

2) X.509 authentication for ADFS is using https port 49443. In public WLANs, hotel WLANs, etc. we have no influence whether this port is blocked or not. In this case it might be a good idea to use the well documented SP initiated logon as a fallback, as password logon is using standard 443.

I hope this litte blog brings some improvement for some of you. Feedback is always welcome

Thanks

Jochen