RE: Security Context in SAML 2.0

["Cahill, Conor P" <conor.p.cahill@intel.com>]

This is not specified because it is totally out of scope for SAML.   The IdP can do whatever it wants to maintain user state at the IdP  (client side or server side) and can even choose to not maintain any state on the user (requiring the user to authenticate each time an SSO request is received).  Similarly, once an SP gets an assertion from the IdP, the SP can do whatever it wants to maintain the users “session” at the SP – including the same option of not maintaining any state and requiring an assertion on each request.

 

In most deployments (all that I am aware of) deployments, the IdP will maintain state of the user’s session and thus remember that they have authenticated the user, which user it is, and how/when they were authenticated.  This will be done using any of the typical session management capabilities available to any web site (cookies, server side state, etc.).

 

Similarly, in most deployments the SP will also maintain a user session that is keyed off the SSO transaction.  However, it isn’t typical for the SP to place the assertion into the cookie to maintain the context since processing and validating an assertion is a non-trivial task.  In addition, a good design practice at the SP is to keep all of the SSO processing code in a separate component rather than mixing it into the primary web engine – that way you can update and manager the SSO module with little impact to the web engine.   So what typically happens is that the SSO takes place and an authenticated session is created for the web engine and the model used by the web engine (cookies, url rewrites, server side state) is used while the user is redirected to the resource they were trying to get to in the web engine.

 

Conor

 

From: giorgi moniava [mailto:giorgimoniava@yahoo.com]
Sent: Monday, June 23, 2008 6:44 AM
To: saml-dev@lists.oasis-open.org; Cahill, Conor P
Subject: Security Context in SAML 2.0

 

Hi all.

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".) But such documents, never give a recommendation or description on how such "security context" should be created, or maintained.

Can anyone elaborate on this? I can imagine this can be done by using cookies, but are there any other methods? Can the IdP's or SP's simply store assertions, and check the vaildity times inside, in order to determine whether a user has a security context or not?

Best Wishes,
Giorgi.