What you always wanted to know about SAP ID Service but never dared to ask...

[TorbenEhret]

Question: Why is SAP ID Service so slow and shows this boring screen? Don’t you care about the performance?

Answer: 

Management Summary: Do you really think we develop such a slow authentication service? That’s a pity! Obviously not! When you see this screen the authentication is done and we wait for the SP to take over.

Nerd Summary: In SAP ID Service (or with it’s new product name SAP Cloud Identity) we make use of SAML 2.0 specification with the Web Browser SSO profile for single sign-on for user authentication.

Basically, the Identity Provider (IDP, e.g. SAP ID Service) and the Service Provider (SP, e.g. SAP HANA Cloud Platform) exchange SAML protocol messages through the users’ browser. The SP sends an SAML authentication request message to the IDP, asking to authenticate the user. The IDP typically asks the user for a username and password (any other method of authentication – like certificates). After username and password verification the IDP sends back a SAML authentication response stating that the user has just logged in successful at the IDP, with some proof that the message was indeed sent by the IDP.

So, lets have a closer look at the request flow.

You can visualize the requests in the different browsers with either the integrated developer tools (e.g. Internet Explorer 10 or Chrome) or in Firefox with the Firebug add-on. Other tools work as well, like HTTPwatch or Charles Proxy.

1. Open the developer tool and start the capture of the network traffic (for Chrome users: check the “preserver log on navigation” box).
2. Navigate to https://scn.sap.com or event better https://scn.sap.com/login.jspa (That is just a workaround to use the “normal” SAML login and not the auto-login process)
3. Enter your SAP ID Service/SCN username and password.
4. With a successful authentication the overlay disappear and the main page is shown
5. Stop the capture of the network traffic.

As a next step, we analyze the requests. There are two requests where SAP ID Service is involved.

The first request is a GET request to accounts.sap.com. Here the SP (scn.sap.com) sends the authentication request to the IDP (strongly abbreviated):

https://accounts.sap.com/saml2/idp/sso/accounts.sap.com?SAMLRequest=fVLL...8Rf

Looking at the timeline for the duration: 311ms. Not bad but also not good. In Firefox/Firebug you can hover over the request in the timeline and some more details show up:

There are 132ms listed as “Blocking”.  What does it mean? While I clicked too fast on the „Log on“ link (I was using the https://scn.sap.com entry point) and some JavaScript was still loading. Since several versions all browsers have a limit of concurrent requests to a host. But that limit can be configured manually.

So, without the blocking time the request took 179ms to complete – which isn’t that bad.

The 2^nd request – the POST request – is the more interesting one.

https://accounts.sap.com/saml2/idp/sso/accounts.sap.com

POST Parameters:

SAMLRequest: fVLL...8Rf

j_password: MySecureP@ssw0rd

j_username: MyUserName

With that request username and password is verified by the IDP for that SP and as response the verification about the successful authentication combined with additional attributes is sent back to the SP. All this information has been signed, so the SP can check whether the message has not been tampered along the way.

Looking again at the response times in the timeline:

The sum of the Waiting and Receiving time form about 345ms, which sounds ok.

Where does the screen “You are being logged on” come from, which causes anger?

This screen is the response from the above POST request that is shown as long as the SP is generating its page and sending it to the browser. The page is regenerated when the SP has sent enough page content for the browser to start rendering the page.

Conclusion:

So you can see that by the time this message appears, SAP ID Service has already completely finished its side of things and you are now in fact waiting for the SP to process the SSO response. Maybe there is a better way we could communicate this? Please let us know in the comments below.