Is this SAML SSO implementation correct?

3
votes

I have a site say www.e1.com. www.e1.com is Service Provider. Whenever I click a service in it, I am redirected to a Identity provider, say www.e2.com. Before that,In service provider(www.e1.com) I will check if any cookie is set for the user. For the first time there will be no cookie so it will send empty SessionId value. Thus, I am sending a SAML Request to www.e2.com along with with no id(as no cookie is set. Cookie contains Id)

Now in www.e2.com i.e.In identity provider,I will check whether www.e1.com has sent any Id value. If it is null I will create a session Id and store it in database(In www.e2.com). Then I will redirect browser to my Authentication page where User's Name and password will be asked and accordingly he will be authenticated. If the authentication is successfull, I will redirect browser to Service provider(www.e1.com) with SAML Response which contains session Id.

Now in Service provider the SessionId value will be stored in Cookie and browser will be redirected to consumer service page(service page the user wants to access).

Now if the same user wants to access some other service from same Service provider (within the session), the browser will obviously send the SessionId in Cookie along with the request SAML. Identity Provider will check the SessionId value in his database, If its there in its database then it will give direct access to service to user without entering login credential as the user is already authenticated for the session.

Is this the right way to achieve Single Sign On with SAML? or
If this method has flaws, Can you explain those flaws?

Thanks in advance :)

1
single-sign-onsaml

1 Answers

15
votes

Your understanding is not quite correct :)

Here is the flow:

  1. User tries to access a protected resource on the SP. SP checks if the user has a local (and authenticated session). If not it generates a SAML <AuthRequest> which includes a random id. The SP then redirects the user to the IDP with this AuthnRequest.

  2. The IDP will check if the user has a local authenticated session. If not it will authenticate the user The IDP will send an AuthResponse back to the SP with an inReplyTo attribute which matches the id sent by the SP in it's AuthnRequest

  3. The SP will then create a local session. Subsequent requests to the SP will not involve the IDP unless a) The session expires or b) the SP receives a SingleLogout message from the IDP