Introduction

This short article provides details on how Opensso uses cookies to provide a session management infrastructure.  The use cases examined are:

• Single Sign-On using session cookies - but no authorization policies are enforced
• Single Sign-On using session cookies - and authorization policies are enforced
• Use of persistent cookies to support long term sessions

Each use case consists of a diagram showing the processing steps followed by a commentary of the diagram.  Each processing step has a number and this refers to the relevant numbered paragraph in the commentary.

 I would like to thank Dilli Dorai and Pat Patterson for providing the base information used to create the article.

Single Sign-On Session Management using Session Cookies

In this use case a user "logs on" to Opensso to gain access to a web resource.  To make the processing steps slightly easier its assumed no authorization policy decisions are enforced.

The diagram below shows the processing steps.

The details of the processing steps are:

1. Browser requests access from a resource.
2. The policy agent does not find an Opensso session cookie in the HTTP headers and sends a HTTP redirect message back to the browser redirecting the browser to the Opensso Authentication Server.
3. The authentication server sends a challenge to the browser requesting that they authentication themselves.
4. The user enters their credentials and the browser sends a HTTP message to the authentication server. The authentication server validates the entered credentials against the appropriate authentication provider. The server then generates a session cookie.
5. The authentication server then sends a HTTP redirect message back to the browser containing the session cookie. The redirect message defines the redirected location to be the requested resource on the web server
6. On receiving the HTTP message to fetch the requested resource the agent sees that there is an Opensso session cookie in the HTTP header. However in validating the Opensso session cookie the agent can not find the session in its local cache. It therefore contacts the authentication server. The server confirms that it is a valid session and sends back to the agent the session details (so they can be cached in the agent).
7. Once the agent has received confirmation it is a valid session the resource is provided back to the browser.
8. The browser requests another resource from the web server. If a valid session exists in the agent then the resource is provided back to the browser.
9. However if a session has timed out (i.e. not cached locally in the agent) then the agent contacts the authentication server for a refresh of the session information. 
10. The resource is provided to the browser.

Note 1:  The Opensso server can also send a message to the agent to change a session's state (e.g. the system logging out a user) and this purges the session from the agent's session cache.

Session Management with Policy Decisions

For this use case policy decisions are now added into the mix.

The diagram below shows the processing  steps. 

The details of the processing steps are:

1. Browser requests access from a resource.
2. The policy agent does not find an Opensso session cookie in the HTTP headers and sends a HTTP redirect message back to the browser redirecting the browser to the Opensso Authentication Server. 
3. The authentication server sends a challenge to the browser requesting that they authentication themselves.
4. The user enters their credentials and the browser sends a HTTP message to the authentication server.  The authentication server validates the entered credentials against the appropriate authentication provider.  The server then generates a session cookie.
5. The authentication server then sends a HTTP redirect message back to the browser containing the session cookie.  The redirect message defines the redirected location to be the requested resource on the web server
6. On receiving the HTTP message to fetch the requested resource the agent sees that there is an Opensso session cookie in the HTTP header.  However in validating the Opensso session cookie the agent can not find the session in its local cache.  It therefore contacts the authentication server.  The server confirms that it is a valid session and sends back to the agent the session details (so they can be cached in the agent).  Once the session has been validated the agent then requests from the server the policy decisions associated with the resource.
7. Once the agent has received confirmation it is a valid session and that the appropriate policy decisions have been evaluated successfully the requested resource is provided back to the browser.
8. The browser requests another resource from the web server.  If a valid session exists in the agent and valid policy decisions also exists in the agent cache (and the policy is evaluated successfully) then the resource is provided back to the browser.
9. However if a session or policy decision has timed out (i.e. not cached locally in the agent) then the agent contacts the authentication server for a refresh of the session and policy decision information. This is performed as two separate request/response messages between the agent and the server.
10. If the policy decisions evaluate successfully then the resource is provided to the browser.

Note 1:  The Opensso server can also send a message to the agent to change a session's state (e.g. the system logging out a user) and this purges the session from the agent's session cache and the policy decision from the policy cache.

Use of Persistent Cookies 

Now we show are persistent cookies and session cookies are combined together to support a long term session management infrastructure.

The diagram below shows the processing  steps. 


The details of the processing steps are:

1. Browser requests access from a resource.
2. The policy agent does not find an Opensso session cookie in the HTTP headers and sends a HTTP redirect message back to the browser redirecting the browser to the Opensso Authentication Server.  W hen the HTTP message is analysed by the authentication server it can not find an Opensso persistent cookie.
3. The authentication server sends a challenge to the browser requesting that they authentication themselves.
4. The user enters their credentials and the browser sends a HTTP message to the authentication server.  The authentication server validates the entered credentials against the appropriate authentication provider.  The server then generates a persistent cookie and a session cookie.
5. The authentication server then sends a HTTP redirect message back to the browser containing both the session and persistent cookie.  The redirect message defines the redirected location to be the requested resource on the web server
6. On receiving the HTTP message to fetch the requested resource the agent sees that there is an Opensso session cookie in the HTTP header.  However in validating the Opensso session cookie the agent can not find the session in its local cache.  It therefore contacts the authentication server.  The server confirms that it is a valid session and sends back to the agent the session details (so they can be cached in the agent).  Once the session has been validated the agent then requests from the server the policy decisions associated with the resource.
7. Once the agent has received confirmation it is a valid session and that the appropriate policy decisions have been evaluated successfully the requested resource is provided back to the browser.
8. The browser requests another resource from the web server.  If a valid session exists in the agent and valid policy decisions also exists in the agent cache (and the policy is evaluated successfully) then the resource is provided back to the browser.
9. However if a session or policy decision has timed out (i.e. not cached locally in the agent) then the agent contacts the authentication server for a refresh of the session and policy decision information. This is performed as two separate request/response messages between the agent and the server.
10. If the policy decisions evaluate successfully then the resource is provided to the browser.
11. After a session has timed out (or a new browser instance is used) the browser requests a resource
12. The Opensso does not find an Opensso session cookie in the HTTP headers and send a HTTP redirect message back to the browser redirecting the browser to the Opensso Authentication Server.  W hen the HTTP message is analysed by the authentication server it finds an Opensso persistent cookie.  It determines that the persistent cookie has not timed out.  It decrypts the persistent cookie and extracts the information required to generate a new session and persistent cookie.
13. The authentication server then sends a HTTP redirect message back to the browser containing both the session and persistent cookie.  The redirect message defines the redirected location to be the requested resource on the web server
14. On receiving the HTTP message to fetch the requested resource the agent sees that there is an Opensso cookie in the HTTP header. However in validating the Opensso session cookie the agent can not find the session in its local cache.  It therefore contacts the authentication server. The server confirms that it is a valid session and sends back to the agent the session details (so they can be cached in the agent).  Once the session has been validated the agent then requests from the server the policy decisions associated with the resource.
15. Once the agent has received confirmation it is a valid session and that the appropriate policy decisions have been evaluated successfully the requested resource is provided back to the browser.

Note 1:  persistent cookie mode can be set using two different mechanisms in step 4:

• The HTTP redirect message set to the authentication server has iPSPCookie=yes in the HTTP header
• A custom authentication module is used which calls the function AMLoginModule.setPersistentCookieOn()

Note 2:  The Opensso server can also send a message to the agent to change a session's state (e.g. the system logging out a user) and this purges the session from the agent's session cache and the policy decision from the policy cache.

About The Author

John Hughes, Director of SecID Consultants Ltd. He can be contacted at john.hughes@secid.co.uk