Appendix B The User Session Life Cycle

In providing access management services, Sun Java™ System Identity Server allows for the creation of session objects which are used to track user interaction with web applications across multiple HyperText Transfer Protocol (HTTP) requests. This chapter describes the life cycle of a session by tracing the protocol interactions of the Identity Server components. It contains the following sections:

Overview

The following sections trace the protocol interaction of Identity Server components as they provide authentication and authorization services to a user requesting access to protected resources via a web browser. In so doing, it also demonstrates the session life cycle.

The Request

To begin the scenario, an unauthenticated user makes a request for a protected resource which is sent to the server. The resource is protected by a policy agent. Code Example B-1 depicts the GET request sent by the browser.

With Identity Server, all access requests are implicitly denied unless explicitly allowed by the presence of a valid session token (programmatically, SSOToken) and the existence of an applicable policy allowing access.


Note	This behavior can be inverted based upon deployment criteria.

Since, in this case, a session token is not provided, the policy agent redirects the request to the Authentication Service. Code Example B-2 depicts the redirect information sent back to the requesting browser. It includes the URI to the Authentication Service and a goto parameter that contains the URL of the original request.

Biding by the HTTP, the user’s browser allows the redirect and makes a request to the Authentication Service URI. Code Example B-3 depicts the GET Request sent to the Authentication Service.

The Authentication

Upon receiving the request for authentication, the Authentication Service determines which authentication module to present the user with based upon Identity Server configuration and the request parameters. As in all new authentication requests, an invalid session token is created by the Session Service to track the user interaction. (This session token also contains an encrypted session identifier which is a randomly-generated string that represents the user.) The session token is set in a cookie (iPlanetDirectoryPro by default) which, along with a form asking the user for the appropriate credentials, is sent by the Authentication Service in response to the request for authentication.


Note	The protocol of the form (HTML, WML, etc.) is determined by the Client Detection Service based on the client requesting the authentication. More information on this service can be found in the Identity Server 2004Q2 Developer’s Guide.

Code Example B-4 depicts the header of the HTML authentication form requesting authentication credentials from the user. (The HTML itself has been deleted for the sake of brevity.)

After receiving the form, the user enters their authentication credentials and posts them to Identity Server. Normally, this process might have occurred over SSL to protect the password attribute. For demonstration purposes, the credentials posted in Code Example B-5 was made over clear HTTP.

Once the credentials are received by the Authentication Service, they are validated by the appropriate authentication module. Assuming they pass muster, the state of the session token is changed to valid, and session information (Login time, Authentication Scheme, Authentication Level, etc.) is stored. The iPlanetDirectoryPro cookie now contains a valid session token, and the server replies to the browser with a redirect to the originally requested resource. Code Example B-6 contains this redirect response.

Biding by the HTTP, the user’s browser allows the redirect back to the original resource and, once again, requests access. This time, the session token created during the authentication process is included with the request.

The Session Token

The policy agent, once again, intercepts the request. Since the request now contains a session token in the same DNS domain as Identity Server, the agent attempts to determine the validity of said token and its associated session. First, it must learn where the session originated. To do this, it contacts the Naming Service. The Naming Service allows clients to find the service URL for the internal services used by Identity Server. This information can then be used for communication regarding a session. The Naming Service decrypts the session and returns the corresponding URLs which will then be used to obtain information about the session from the applicable services. Code Example B-8 contains the POST request for naming information.

Code Example B-9 contains the response to the POST request for naming information. Note the attribute names and their corresponding URL values.

Code Example B-9 Response With Naming Information


HTTP/1.1 200 OK
Content-type: text/html

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseSet vers="1.0" svcid="com.iplanet.am.naming" reqid="9">
<Response><![CDATA[<NamingResponse vers="1.0" reqid="2">
<GetNamingProfile>
<Attribute name="iplanet-am-naming-policy-url" value="http://identityserver.sun.com:58081/amserver/policyservice"></Attrib ute>
<Attribute name="iplanet-am-naming-session-class" value="com.iplanet.dpro.session.service.SessionRequestHandler"></Attribute>
<Attribute name="iplanet-am-naming-session-url" value="http://identityserver.sun.com:58081/amserver/sessionservice"></Attri bute>
<Attribute name="iplanet-am-naming-samlawareservlet-url" value="http://identityserver.sun.com:58081/amserver/SAMLAwareServlet"></Att ribute>
<Attribute name="serviceObjectClasses" value="iplanet-am-naming-service"></Attribute>
<Attribute name="iplanet-am-naming-auth-url" value="http://identityserver.sun.com:58081/amserver/authservice"></Attribut e>
<Attribute name="iplanet-am-naming-profile-class" value="com.iplanet.dpro.profile.agent.ProfileService"></Attribute>
<Attribute name="iplanet-am-naming-samlassertionmanager-url" value="http://identityserver.sun.com:58081/amserver/AssertionManagerServlet /AssertionManagerIF"></Attribute>
<Attribute name="iplanet-am-naming-umservice-url" value="http://identityserver.sun.com:58081/amserver/UserManagementServlet/" ></Attribute>
<Attribute name="01" value="http://identityserver.sun.com:58081"></Attribute>
<Attribute name="iplanet-am-naming-policy-class" value="com.sun.identity.policy.remote.PolicyRequestHandler"></Attribute>
<Attribute name="iplanet-am-naming-logging-class" value="com.sun.identity.log.service.LogService"></Attribute>
<Attribute name="iplanet-am-naming-profile-url" value="http://identityserver.sun.com:58081/amserver/profileservice"></Attri bute>
<Attribute name="iplanet-am-naming-samlsoapreceiver-url" value="http://identityserver.sun.com:58081/amserver/SAMLSOAPReceiver"></Att ribute>
<Attribute name="iplanet-am-naming-logging-url" value="http://identityserver.sun.com:58081/amserver/loggingservice"></Attri bute>
<Attribute name="iplanet-am-naming-fsassertionmanager-url" value="http://identityserver.sun.com:58081/amserver/FSAssertionManagerServl et/FSAssertionManagerIF"></Attribute>
<Attribute name="iplanet-am-platform-server-list" value="http://identityserver.sun.com:58081"></Attribute>
<Attribute name="iplanet-am-naming-samlpostservlet-url" value="http://identityserver.sun.com:58081/amserver/SAMLPOSTProfileServlet" ></Attribute>
<Attribute name="iplanet-am-naming-auth-class" value="com.sun.identity.authentication.server.AuthXMLHandler"></Attribute>
</GetNamingProfile>
</NamingResponse>]]></Response>
</ResponseSet>

Using the information provided by the Naming Service, the policy agent makes a POST request to the Session Service to validate the included session token. Code Example B-10 is the POST request to the Session Service.

Code Example B-10 POST Request To Session Service For Session Validation


POST /amserver/sessionservice HTTP/1.0
Host: identityserver.sun.com
Content-Type: text/xml; charset=UTF-8

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RequestSet vers="1.0" svcid="Session" reqid="10">
<Request><![CDATA[
<SessionRequest vers="1.0" reqid="4">
<GetSession reset="true">
<SessionID>AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg27LiyS8LnHAj4=</SessionID>
</GetSession>
</SessionRequest>]]>
</Request>
<Request><![CDATA[
<SessionRequest vers="1.0" reqid="5">
<AddSessionListener>
<URL>http://application.sun.com:8089/amagent/UpdateAgentCacheServlet?shortc ircuit=false</URL>
<SessionID>AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg27LiyS8LnHAj4=</SessionID>
</AddSessionListener>
</SessionRequest>]]>
</Request>
</RequestSet>

The Session Service receives the request and checks the session token for validity. Assuming the session has not timed out or been invalidated for other reasons, the Session Service responds that the session is valid. This assertion is coupled with supporting information about the session itself.


Note	A Session Listener is also registered for the session. This allows notification of the policy agent should there be a change in the session’s state or validity.

Code Example B-11 Session Service Response Asserting A Session’s Validity


HTTP/1.1 200 OK

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseSet vers="1.0" svcid="session" reqid="10">
<Response><![CDATA[<SessionResponse vers="1.0" reqid="4">
<GetSession>
<Session sid="AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg27LiyS8LnHAj4=" stype="user" cid="uid=user1,ou=people,dc=sun,dc=org" cdomain="dc=sun,dc=org" maxtime="300" maxidle="120" maxcaching="3" timeidle="0" timeleft="17993" state="valid">
<Property name="authInstant" value="2003-10-02T01:38:23Z"></Property>
<Property name="clientType" value="genericHTML"></Property>
<Property name="CharSet" value="UTF-8"></Property>
<Property name="Locale" value="en_US"></Property>
<Property name="UserToken" value="user1"></Property>
<Property name="loginURL" value="http://identityserver.sun.com:58081/amserver/UI/Login"></Property>
<Property name="SessionHandle" value="shandle:AQIC5wM2LY4SfcxlvOiI7LJwWcusZAdkM3CHmIoeehu6urc="></Property >
<Property name="Host" value="192.168.1.100"></Property>
<Property name="AuthType" value="LDAP"></Property>
<Property name="Principals" value="uid=user1,ou=People,dc=sun,dc=org\|AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg 27LiyS8LnHAj4="></Property>
<Property name="cookieSupport" value="true"></Property>
<Property name="Organization" value="dc=sun,dc=org"></Property>
<Property name="USERS_DN" value="uid=user1,ou=people,dc=sun,dc=org"></Property>
<Property name="AuthLevel" value="0"></Property>
<Property name="UserId" value="user1"></Property>
<Property name="HostName" value="192.168.1.100"></Property>
<Property name="Principal" value="uid=user1,ou=people,dc=sun,dc=org"></Property>
</Session></GetSession>
</SessionResponse>]]></Response>
<Response><![CDATA[<SessionResponse vers="1.0" reqid="5">
<AddSessionListener>
<OK></OK>
</AddSessionListener>
</SessionResponse>]]></Response>
</ResponseSet>

The Policy

Having received a reply indicating that the session token presented by the user was valid, the policy agent must now determine if the user can be granted access to the resource being requested. It formulates a request to the Policy Service, requesting decisions regarding resources in its portion of the HTTP namespace. Included with this request is additional environmental information which might impact conditions set on a configured policy, such as IP address or DNS name. Code Example B-12 is the POST request sent to the Policy Service URI for information.

Code Example B-12 POST Request For Policy Information


POST /amserver/policyservice HTTP/1.0
Host: identityserver.sun.com
Content-Type: text/xml; charset=UTF-8

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RequestSet vers="1.0" svcid="Policy" reqid="11">
<Request><![CDATA[
<PolicyService version="1.0">
<PolicyRequest requestId="3" appSSOToken="AQIC5wM2LY4SfczlhkwdQHfKgzxYu0qWY+DFCB9VGmknzvM=">
<GetResourceResults userSSOToken="AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg27LiyS8LnHAj4=" serviceName="iPlanetAMWebAgentService" resourceName="http://application.sun.com:8089/" resourceScope="subtree">
<EnvParameters>
<AttributeValuePair>
<Attribute name="requestDnsName"/>
<Value>drnick</Value>
<Value>drnick.sun.com</Value>
</AttributeValuePair>
<AttributeValuePair>
<Attribute name="requestIp"/>
<Value>192.168.1.100</Value>
</AttributeValuePair>
</EnvParameters>
</GetResourceResults>
</PolicyRequest>
</PolicyService>]]>
</Request>
</RequestSet>

After receiving the request, the Policy Service checks for policies that contain resource definitions which apply to the request.


Note	Policies are cached in Identity Server. If the policies have not been written to the cache, they are loaded from Directory Server.

Once policies are found that apply to the request, the Policy Service checks to see if the user identified by the session token is a member of any of the Policy Subjects. If policies are found that match the resource and the user is a valid subject, additional conditions of the policy are evaluated. (For example, Is it the right time of day?, Are they coming from the correct network?, etc.) If all the conditions are met, the Policy Service determines that the user can be granted access and responds to the policy agent with the allow decision. Code Example B-13 is the response from the Policy Service verifying that the user can have access to the protected resource.

Code Example B-13 Allow Policy Response


HTTP/1.1 200 OK

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseSet vers="1.0" svcid="policy" reqid="11">
<Response><![CDATA[<PolicyService version="1.0">
<PolicyResponse requestId="3">
<ResourceResult name="http://application.sun.com:8089/">
<PolicyDecision>
<ActionDecision timeToLive="1065121515571">
<AttributeValuePair>
<Attribute name="POST"/>
<Value>allow</Value>
</AttributeValuePair>
<Advices>
</Advices>
</ActionDecision>
<ActionDecision timeToLive="1065121515571">
<AttributeValuePair>
<Attribute name="GET"/>
<Value>allow</Value>
</AttributeValuePair>
<Advices>
</Advices>
</ActionDecision>
</PolicyDecision>
</ResourceResult>
</PolicyResponse>
</PolicyService>]]>
</Response>

The Requested Page

Having received a decision from the Policy Service, the policy agent must act on this access information. In this case, an allow decision was issued for GET and POST operations. This matches the operation requested by the user, thus the policy agent will allow access. The decision is cached, along with the session token, so that subsequent requests can be checked using the cache and need not contact Identity Server. The cache will expire after an administrator-defined interval has passed or upon an explicit notification of change in policy or session status. However, before the user is granted access, the action must be logged so an audit trail is maintained. The policy agent issues a logging request to the Logging Service. Code Example B-14 is that request.

The Logging Service receives the request and, based upon configuration, logs the request to an optionally signed file, or JDBC store. A response is then returned to the policy agent notifying it of the log. Code Example B-15 is that response.

Now, the policy agent allows access to the requested resource. Code Example B-16 is the HTML page for the requested resource. (The HTML itself has been deleted in the interest of brevity.)

Single Sign-On Requests

This section follows two threads. The first occurs when the authenticated user requests a protected resource on a different server in the same DNS domain for which a session token has already been validated; this first thread uses the single sign-on functionality. The second thread occurs when the authenticated user requests a protected resource on a different server in a different DNS domain; this second thread uses the cross domain single sign-on functionality.

Thread One: Single Sign-On

Having received the requested page, the user makes a request for a protected resource on a different server. Code Example B-17 is this second request. Note that the session token is included with the request. This makes single sign-on possible.

Since a session token is present, the policy agent does not need to get user authentication. Therefore, in this case, the procedure detailed in The Authentication is skipped. The agent, though, has not seen the session token before (i.e.: it has no cached entry), so it will follow the procedures as detailed in The Session Token, The Policy and The Requested Page.


Note	The following is heavily edited from the procedures detailed in The Session Token, The Policy and The Requested Page.

The Naming Service is contacted. Code Example B-18 is the request to the Naming Service for URLs of the internal services used by Identity Server. The Naming Service decrypts the session and returns the corresponding URLs which will then be used to obtain session data.

Code Example B-18 POST Request For Naming Service

POST /amserver/namingservice HTTP/1.0
Host: identityserver.sun.com

...
<NamingRequest vers="1.0" reqid="2" sessid="AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg27LiyS8LnHAj4=">
....

HTTP/1.1 200 OK

<ResponseSet vers="1.0" svcid="com.iplanet.am.naming" reqid="9">
....
</ResponseSet>

Based upon the reply from the Naming Service, the appropriate Session Service is contacted. Code Example B-19 is the request sent to the Session Service containing the session identifier.

Code Example B-19 POST Request To Session Service


POST /amserver/sessionservice HTTP/1.0

...
<SessionID>AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg27LiyS8LnHAj4=</SessionID>
....

HTTP/1.1 200 OK

....
<Session sid="AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg27LiyS8LnHAj4=" stype="user" cid="uid=user1,ou=people,dc=sun,dc=org" cdomain="dc=sun,dc=org" maxtime="300" maxidle="120" maxcaching="3" timeidle="0" timeleft="17991" state="valid">
....

Assuming a valid session reply from the Session Service, a POST Request is made to the Policy Service. Code Example B-20 is the request to the Policy Service for policy information pertaining to the authenticated user.

Code Example B-20 POST Request To Policy Service


POST /amserver/policyservice HTTP/1.0

...
<GetResourceResults userSSOToken="AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg27LiyS8LnHAj4=" serviceName="iPlanetAMWebAgentService" resourceName="http://webservice.sun.com:8090/" resourceScope="subtree">
...

In this case, a policy allowing access to the protected resource is not found and the Policy Service responds appropriately. Code Example B-21 is the negative response.

Code Example B-21 Response From Policy Service Negating Access


HTTP/1.1 200 OK

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseSet vers="1.0" svcid="policy" reqid="11">
<Response><![CDATA[<PolicyService version="1.0">
<PolicyResponse requestId="3">
<ResourceResult name="http://webservice.sun.com:8090/">
<PolicyDecision>
</PolicyDecision>
</ResourceResult>
</PolicyResponse>
</PolicyService>]]>
</Response>
</ResponseSet>

As the policy agent has been set up for logging, it logs this denial of access. Code Example B-22 is the request to the Logging Service to write a log indicating the user is not allowed access to the requested resource.

Code Example B-22 POST Request To Logging Service


POST /amserver/loggingservice HTTP/1.0

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RequestSet vers="1.0" svcid="Logging" reqid="12">
<Request><![CDATA[
<logRecWrite reqid="2"><log logName="amAuthLog" sid="AQIC5wM2LY4SfcyueSeNMEFDFRRLub8BfjaxeyDvTPXlVnA="></log><logRecord><re cType>Agent</recType><recMsg>User user1 was denied access to http://webservice.sun.com:8090/index.html.</recMsg></logRecord></logRecWrit e>]]></Request>
</RequestSet>

HTTP/1.1 200 OK

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseSet vers="1.0" svcid="iplanet.webtop.service.logging" reqid="12">
<Response><![CDATA[OK]]></Response>
</ResponseSet>

The policy agent then issues a Forbidden message to the user. Code Example B-23 is the HTML page for this message. Optionally, the user could then be redirected to an administrator-specified page indicating they were denied access.

Code Example B-23 HTML Page With Access Denied Message


HTTP/1.1 403 Forbidden

<HTML><HEAD><TITLE>Forbidden</TITLE></HEAD>
<BODY><H1>Forbidden</H1>
Your client is not allowed to access the requested object.
</BODY></HTML>

Thread Two: Cross Domain Single Sign-On

Having been denied access to the second requested page, the user makes a request for a protected resource on a server in a different DNS domain. Since Identity Server uses HTTP Domain cookies (http://www.ietf.org/rfc/rfc2965.txt) to transfer the session token between applications, the token is not automatically handed up to the policy agent with the request as it was in Thread One: Single Sign-On.

It is the job of Cross Domain Single Sign-On (CDSSO) protocol within Identity Server to transfer the token into the new DNS domain so it is usable for applications in that domain. Code Example B-24 is the request for access to a protected application in a different DNS domain without the session token.

Code Example B-24 GET Request For Protected Application In Different DNS Domain


GET /index.html?sunwMethod=GET HTTP/1.1
Host: webservice.java.com:8088

The policy agent sees that no session token is present. However, in this case, the agent is configured for CDSSO so, rather than redirect to the Authentication Service, it redirects to the CDSSO Controller Service which uses Liberty Protocols to transfer sessions, and hence, the redirect includes the relevant Liberty parameters. Code Example B-25 is the redirect with the Liberty parameters (by way of the browser).

Code Example B-25 Redirect To The CDSSO Controller Service Via The Browser


HTTP/1.1 302 Moved Temporarily
Location: http://identityserver.sun.com:58081/amserver/cdcservlet?goto=http%3A%2F%2Fw ebservice.java.com%3A8088%2Findex.html%3FsunwMethod%3DGET&refererservlet=ht tp%3A%2F%2Fwebservice.java.com%3A8088%2Findex.html%3FsunwMethod%3DGET&Reque stID=29980&MajorVersion=1&MinorVersion=0&ProviderID=http%3A%2F%2Fwebservice .java.com%3A8088%2Famagent&IssueInstant=2003-10-02T04%3A25%3A06Z&ForceAuthn =false&IsPassive=false&Federate=false

Biding by the HTTP, the user’s browser allows the redirect. This time the request contains the session token, as it is a cookie in the primary domain. Code Example B-26 is the HTTP redirect from the browser to the CDSSO Controller Service with the session token.

Code Example B-26 HTTP Redirect From Browser With Session Token


GET /amserver/cdcservlet?goto=http%3A%2F%2Fwebservice.java.com%3A8088%2Findex.h tml%3FsunwMethod%3DGET&refererservlet=http%3A%2F%2Fwebservice.java.com%3A80 88%2Findex.html%3FsunwMethod%3DGET&RequestID=29980&MajorVersion=1&MinorVers ion=0&ProviderID=http%3A%2F%2Fwebservice.java.com%3A8088%2Famagent&IssueIns tant=2003-10-02T04%3A25%3A06Z&ForceAuthn=false&IsPassive=false&Federate=fal se HTTP/1.1
Host: identityserver.sun.com:58081
Cookie: iPlanetDirectoryPro=AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg27LiyS8LnHAj4%3D

The CDC Servlet (in the CDSSO Controller Service) receives the session token, formulates a Liberty Post Profile response detailing session information, and replies to the browser. Code Example B-27 is the reply.

Code Example B-27 POST Reply To The Browser


HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Thu, 02 Oct 2003 01:38:28 GMT
Content-type: text/html
Pragma: no-cache
Transfer-encoding: chunked

<HTML>
<BODY Onload="document.Response.submit()">
<FORM NAME="Response" METHOD="POST" ACTION="http://webservice.java.com:8088/index.html?sunwMethod=GET">
<INPUT TYPE="HIDDEN" NAME="LARES" VALUE="<ENCODED_LIBERTY_DOC>"/>
</FORM>
</BODY></HTML>

The user’s browser automatically submits the form containing the Liberty document to the policy agent, based upon the Action and the Javascript included in the Body tags onLoad. Code Example B-28 is the Browser POST to the policy agent.

Code Example B-28 Browser POST To Policy Agent


POST /index.html?sunwMethod=GET HTTP/1.1
Host: webservice.java.com:8088
Referer: http://identityserver.sun.com:58081/amserver/cdcservlet?goto=http%3A%2F%2Fw ebservice.java.com%3A8088%2Findex.html%3FsunwMethod%3DGET&refererservlet=ht tp%3A%2F%2Fwebservice.java.com%3A8088%2Findex.html%3FsunwMethod%3DGET&Reque stID=29980&MajorVersion=1&MinorVersion=0&ProviderID=http%3A%2F%2Fwebservice .java.com%3A8088%2Famagent&IssueInstant=2003-10-02T04%3A25%3A06Z&ForceAuthn =false&IsPassive=false&Federate=false
Content-Type: application/x-www-form-urlencoded

LARES=<ENCODED_LIBERTY_DOC>

The policy agent receives the Liberty document and extracts the user’s session information. It must now validate the session as a regular agent would so it follows the procedures as detailed in The Session Token, The Policy and The Requested Page before allowing or denying access to the resource.



Note	The Session Token, The Policy and The Requested Page are not reiterated here in the interest of brevity.

In this case, the session token was determined to be valid, and the user is allowed access. The policy agent responds to the user with the requested document, and sets the session token in a cookie for the new DNS domain. The cookie can now be used by all agents in the new domain. Code Example B-29 is the returned HTML page with the new DNS domain cookie set. (The HTML itself has been deleted in the interest of brevity.)

Code Example B-29 User Allowed Access To HTML Page With New Cookie


TTP/1.1 200 Ok
Set-cookie: iPlanetDirectoryPro=AQIC5wM2LY4Sfcwwte3peDKZILScZ40uK%2FsU0I0WQQP6xXA%3D;Do main=.java.com;Path=/

<HTML>
...
</HTML>

Terminating a Session

Having authenticated, performed SSO and CDSSO, the user now wishes to end their session. Sessions can be terminated by administrators, due to idle or maximum timeouts, or via an explicit user logout. In this case, the user logs out by clicking on a link to the Logout Service. Code Example B-30 is the request to access the Logout Service.

Code Example B-30 GET Request For Logout Service


GET /amserver/UI/Logout HTTP/1.1
Host: identityserver.sun.com:58081
Cookie: iPlanetDirectoryPro=AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg27LiyS8LnHAj4%3D

The Logout Service receives the Logout request, marks the user’s session as destroyed, sets a new invalid value for the session token, and returns a successful logout page to the user. Code Example B-31 details the HTML page sent to the user after a successful logout. (The HTML itself has been deleted in the interest of brevity.)

Code Example B-31 Successful Logout HTML Page Returned To User


HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Set-cookie: iPlanetDirectoryPro=AQICv6c3Z1VfvgCgpLlaEqkqM70TLV24OTB1XkPa%2BLtA8bXvC7c5X ABU95Ta8UJi6dQZhXEUSgTRBWHXQ6kcxe8qgw%3D%3D;Domain=.sun.com;Path=/

<title>Sun ONE Identity Server (Logout)</title>
...

Since the user’s session status has changed, it is the responsibility of the Session Service to notify applications which have expressed interest in the session. In this case, each of the policy agents was configured for Session Notification, and each is sent a document instructing the agent that the session is invalid. This causes it to be flushed from cache.

Code Example B-32 POST For Session Notification


POST /amagent/UpdateAgentCacheServlet?shortcircuit=false HTTP/1.1
Host: application.sun.com:8089

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<NotificationSet vers="1.0" svcid="session" notid="8">
<Notification><![CDATA[<SessionNotification vers="1.0" notid="8">
<Session sid="AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg27LiyS8LnHAj4=" stype="user" cid="uid=user1,ou=people,dc=sun,dc=org" cdomain="dc=sun,dc=org" maxtime="300" maxidle="120" maxcaching="3" timeidle="3" timeleft="17983" state="destroyed">
<Property name="authInstant" value="2003-10-02T01:38:23Z"></Property>
<Property name="clientType" value="genericHTML"></Property>
<Property name="CharSet" value="UTF-8"></Property>
<Property name="Locale" value="en_US"></Property>
<Property name="UserToken" value="user1"></Property>
<Property name="loginURL" value="http://identityserver.sun.com:58081/amserver/UI/Login"></Property>
<Property name="SessionHandle" value="shandle:AQIC5wM2LY4SfcxlvOiI7LJwWcusZAdkM3CHmIoeehu6urc="></Property >
<Property name="Host" value="192.168.1.100"></Property>
<Property name="AuthType" value="LDAP"></Property>
<Property name="Principals" value="uid=user1,ou=People,dc=sun,dc=org\|AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg 27LiyS8LnHAj4="></Property>
<Property name="cookieSupport" value="true"></Property>
<Property name="Organization" value="dc=sun,dc=org"></Property>
<Property name="USERS_DN" value="uid=user1,ou=people,dc=sun,dc=org"></Property>
<Property name="AuthLevel" value="0"></Property>
<Property name="UserId" value="user1"></Property>
<Property name="HostName" value="192.168.1.100"></Property>
<Property name="Principal" value="uid=user1,ou=people,dc=sun,dc=org"></Property>
</Session>
<Type>5</Type>
<Time>1065058714469</Time>
</SessionNotification>]]></Notification>
</NotificationSet>


POST /amagent/UpdateAgentCacheServlet?shortcircuit=false HTTP/1.1
Host: webservice.sun.com:8090

....
<Session sid="AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg27LiyS8LnHAj4=" stype="user" cid="uid=user1,ou=people,dc=sun,dc=org" cdomain="dc=sun,dc=org" maxtime="300" maxidle="120" maxcaching="3" timeidle="3" timeleft="17983" state="destroyed">
...


POST /amagent/UpdateAgentCacheServlet?shortcircuit=false HTTP/1.1
Host: webservice.java.com:8088

...
<Session sid="AQIC5wM2LY4SfcywFlTefDRmqlthG54qrg27LiyS8LnHAj4=" stype="user" cid="uid=user1,ou=people,dc=sun,dc=org" cdomain="dc=sun,dc=org" maxtime="300" maxidle="120" maxcaching="3" timeidle="3" timeleft="17983" state="destroyed">
...

Following the receipt of the session notification, the policy agents flush the session from cache, and the session’s life cycle is complete.

Previous Contents Index Next
Sun Java System Identity Server 2004Q2 Deployment Planning Guide