Clever Geek Handbook

Is this SOM-SAML implementation correctly implemented?

I have a website that says www.e1.com . www.e1.com is a service provider . Whenever I click on its service, I am redirected to an Identity provider like www.e2.com . Before that, in the service provider (www.e1.com), I will check if any cookie is set for the user. There will be no cookie the first time, so it will send an empty SessionId value. So I am sending a SAML request to www.e2.com along with no id (since no cookie is set. Cookie contains Id)

Now in www.e2.com ieIn identity provider I will check if www.e1.com sent any id value. If it's null, I'll create a session id and store it in the database (at www.e2.com). Then I redirect the browser to the Authentication page, where it will ask for a username and password, and accordingly it will be authenticated. If the authentication is successful, I redirect the browser to the Service Provider (www.e1.com) with a SAML response that contains the session ID.

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

>

Now, if the same user wants to access some other service from the same service provider (during a session) the browser will obviously send the SessionId in Cookie along with the SAML request. Identity Provider will check the SessionId value in its database, if there is one in its database, it will provide direct access to the service to the user without entering login credentials, since the user has already been authenticated for the session.

Is this the correct way to achieve SSO with SAML? or
If this method has drawbacks, can you explain these drawbacks?

Thanks in advance.

+3


source to share


1 answer


Your understanding is not entirely correct :)

Here is the stream:



  • The user is trying to access a protected resource in the SP. The SP checks if the user has a local (and authenticated session). Unless it generates SAML <AuthRequest>

    that includes a random id. The SP then redirects the IDP user with this AuthnRequest.

  • IDP will check if the user has an authenticated local session. If it will not authenticate the user. IDP will send AuthResponse

    back to SP with an attribute inReplyTo

    that matches the ID sent by SP in itAuthnRequest

  • The SP will then create a local session. Subsequent SP requests will not include IDP if a) Session expires or b) SP receives a message SingleLogout

    from IDP

+15


source






More articles:


All Articles