Menu
I have a basic question regarding SAML2. Typical flow is that user requests a resource from SP that is protected. SP checks if the user has a security context (say cookie ?), if it does not find a security context, it constructs the AuthRequest and then redirects the browser to the IdP. Now IdP likewise first checks if the user has an existing security context. How does the IdP do this? Does the IdP also use a cookie for this purpose?
853
SAML 2.0 document, usually mention a "security context" which a user has with an IdP or an SP. (e.g. a citation: "The user provides valid credentials and a local logon security context is created for the user at the IdP".)
These are the ways how the SP can determine which IdP to redirect the users to: The SP may ask for the user identity such as the user's email address and use the domain of the same, such as [email protected], to determine which Identity Provider (IdP) to use from multiple configured IdPs.
SAML works by exchanging user information, such as logins, authentication state, identifiers, and other relevant attributes between the identity and service provider. As a result, it simplifies and secures the authentication process as the user only needs to log in once with a single set of authentication credentials.
SAML Authentication Response After the IdP authenticates the user, it creates an Base64 encoded SAML Response and forwards it to Service Provider.
Yes. For SAML Web SSO Profile the session is almost always kept as a cookie in the browser at the IDP and SP. However, there are no rules on how to manage this. The IDP could choose to not keep an active session and prompt the user to login for each SSO transaction.
Ian
82
@Ian - Great Answer. However if the IDP does not maintain a session cookie [B/W Browser and Identity Provider (IDP)] than you miss out on a significant benefit of single sign on (SSO). The SSO User Experience (UX) feature that would be lost is described in the following scenario:
0) Assume IDP is registered with Google Apps and Salesforce.
1) Open Browser. NOTE: SAML is browser based. You need a browser for SAML to work.
2) Try to go to Google Apps; (you have no existing session cookie [B/W Browser and Google Apps]) who then Re-directs you to the IDP.
3) You sign on with your valid IDP credentials.
4) the IDP then stores a session cookie [B/W Browser and IDP] in your browser. (This is the step that @Ian mentioned can be skipped by the IDP)
5) The IDP then redirects you back to Google Apps (via HTTP POST) with SAML token embedded in the POST. You are now in Google Apps. (Now you have a session cookie [B/W Browser and Google Apps] stored on your browser)
5) Try to go to Salesforce.
6) Salesforce sees you have no active session cookie[B/W Browser and Salesforce], so they redirect you to the IDP.
* here is my point of added User Experience (UX) *
7) The IDP will look for a session cookie [B/W Browser and IDP], if the IDP is configured to not store maintain one you have to enter your Single Sign On (SSO) aka IDP Credentials AGAIN.
Discussion on Step7: Entering the SSO credentials for each separate service an extra-step times the number of services you are using. I think the main draw of the implementation is to enter credentials only once and get access to everything (the topic of security aside). However if the IDP does not store a session cookie [B/W Browser and IDP] you are still only using one set of credentials (instead of separate credentials for each service), so life is still easier.
@Ajava - You seem to be confused as to how cookies are used. I hope you can follow my steps above and get better idea of how cookies are used with SAML.
Here is also a good link i found that explains cookies: http://lifehacker.com/5461114/fact-and-fiction-the-truth-about-browser-cookies
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
