The Session Service in OpenSSO is one of the core components that serves as a backbone for the rest of the components to work together for delivering the supported features. It tracks a user's interaction with web applications through the use of session data structures, session tokens, cookies, and other objects. This section attempts to explain some of these concepts and other components of a user's session and properties. Some of the key functions of the Session Service are:
- Create unique session identifiers and maintain session states
- Manage the session life cycle (create, delete, timeout)
- Manage session persistence and high availability
- Secure the session properties
- Enforce session constraints
The term SSO has multiple meanings and is often misinterpreted. Here is a generic definition, "After a one time authentication, identities can access any application for which they are authorized without having to re-authenticate". This means once the user is authenticated there is no need to re-authenticate again and again to browse protected applications. Specifically with relevance to OpenSSO, the Single Sign On could be interpreted as: after authenticating to OpenSSO, users can access the applications without having to re-authenticate, provided the OpenSSO policy allows the access to the resource being accessed by the authenticated user.
There are two kinds of Single Sign-On tokens that are created by the Session Service after a successful authentication. A user SSO token and an application SSO token. The former is the predominantly visible and used by the end users of the protected applications, the latter is often created by the OpenSSO clients such as the policy agents. The user SSO tokens are the real sessions maintained in the Session Service that can be persisted and terminated by the administrator. The following table summarizes the salient features of these tokens.
|
SSO token |
App SSO token |
|---|---|
|
Attached to |
No cookie involved |
|
Session constraints and timeouts enforced by the OpenSSO server |
Typically it is a non-expiring token until the agents container is restarted (it can be forced to expire by setting the |
|
Can be terminated by an administrator using the OpenSSO console or |
Cannot be destroyed explicitly by the OpenSSO administrator |
|
Session high availability feature can be enabled to persist sessions |
No session persistence capability |
All the OpenSSO services are defined using a well-defined XML service schema in compliance with sms.dtd. Session Service schema is defined in the<config-dir>/config/xml/amSession.xml file. It is added to the configuration store during the configuration phase of the server. Any customization in the Session Service should happen on this file. As you can see, it is a dynamic service and can support service attributes at the user and role levels provided the underlying user identity store is Access Manager Repository, which is often referred to as legacy mode.
It is quite possible that you may want to update the session service properties to customize the session's lifetime. This can be accomplished by an administrator either using the OpenSSO console or command line interface such as ssoadm. The following is a quick way of updating the key session time limits using the ssoadm command line tool:
./ssoadm set-realm-svc-attrs -u amadmin -f /tmp/.opensso_pass -e / -s iPlanetAMSessionService -a "iplanet-am-session-max-session-time=340"
This command configures the user's sessions maximum time to 340 minutes at the root realm.
The Session Service is responsible for implementing the mechanisms to manage the session state changes which can be triggered by either the user's explicit actions such as invoking a log in or log out or the system events such as cleanup for expired sessions. These session state changes usually depend on the time-dependent behaviors, which may include creation, activation, timing out, and destruction of user sessions.
A session or an SSO token is uniquely identified by the session identifier. The session ID is basically an opaque handle used to locate the session object. The format has the following structure:
<opaque core session prefix>@<session extension fields>#<http session id>
<opaque core session prefix> is simply an encrypted ID string.<session extension fields> is base64-encoded sequence of pairs. The existing extension field tags currently include the primary server instance ID, the Site ID, and the session storage.<http session id> is appended for reference only and is not used by the Session Service. Here is a snapshot of a sample SSO token obtained from the OpenSSO server.
AQIC5wM2LY4Sfcx5F4RvwHxOQZ3U/NOCliujsjg6Q1bIy1c=@AAJTSQACMDE=#
In this case AAJTSQACMDE= is the session extension field and the AQIC5wM2LY4Sfcx5F4RvwHxOQZ3U/NOCliujsjg6Q1bIy1c= part is the session opaque, there is no<http session id> available in this session ID.
Session Service provides remote interfaces that can be used by the client to create, update, and destroy sessions.
During the lifetime of the session, it undergoes various state changes before being removed from the session table. The transitions of these session states are controlled by the Session Service based on the user actions or the time-dependent behaviors which are enforced by the Session Service. When a request to create a new user session is triggered, the Session Service generates a new session ID and a new instance of session object. The session object is initially created in the INVALID state with default values of attributes and an empty property list. Newly created sessions do not carry any identity. Once the session is authenticated, session state is updated with all the identity attributes and properties. In case the authentication failed, then the generated session ID is discarded in a session request. In the session upgrade scenario the old session is retained. However, this implementation could lead to a security vulnerability where, in a shared desktop, an attacker pre-generates an INVALID session and then tricks a valid user to authenticate. As a result, both the attacker and the valid user have a valid session. OpenSSO 8.0 Enterprise Update 2 and OpenSSO Express Build 9 addressed this vulnerability by issuing a new session after successful authentication.
The transitions in session state triggered by distinct user or system events are depicted in the following figure:
When a session is created by the Session Service subsequent to a successful authentication of an identity, it by default adds certain core properties that describe the nature of the authentication type, session creation time, and other pertinent information that is critical to track the sessions and to retire them when appropriate. A session's validity is determined by the property set in the server side that is modifiable only by privileged users such as the administrator.
There are properties in the session that are not modifiable by any remote client but the server-side modules. The other custom properties that can be set as part of the session are modifiable remotely by any application which possesses the session ID. These custom properties can be used by the remote clients to retrieve some user identity information as part of their session token such as the role of the user. Based on this information the client application could render different user interfaces, based on their role type.
Nevertheless, there is another option that customers can use to restrict the remote clients from modifying certain custom session properties. However, this is not an out of the box configuration, one needs to set the com.iplanet.am.session.protectedPropertiesList in the server-side's advanced properties section. For example, if you are setting a session custom property my.security.role=orgAdmin in the users' SSO token that you do not want the remote clients to update, then just set com.iplanet.am.session.protectedPropertiesList=my.security.role in the OpenSSO server side. This can be easily achieved by simply invoking the ssoadm command line tool:
./ssoadm update-server-cfg --servername http://opensso.packt-services.net:8080/opensso -u amadmin -f /tmp/.passwd_of_amadmin -a com.iplanet.am.session.protectedPropertiesList=my.security.role
Here are the some of the system protected properties; these properties cannot be modified by anyone but the OpenSSO server itself. So administrators need not worry about these values being modified by some remote clients:
AuthLevelAuthTypePrincipalUserIdUserTokenOrganizationcookieSupportauthInstantPrincipalsloginURLFullLoginURLRoleServiceSessionTimedOutAM_CTX_ID
These values can be retrieved from the users' session by various means, for example, the OpenSSO policy agents can be configured to set the users' session attribute values as part of the HTTP header, or a remote client application could use the remote session API to retrieve the values.
In an SSO environment all the protected resources are authorized to be accessible only for the users with a valid SSO token. Well, what happens if the SSO token issued by the OpenSSO server has subsequently been revoked by the administrator? Will the user continue to get access to the protected resource? How does the remote application know that the token has been revoked? This is where session polling and notification come into play. The Session Service framework provides the notification service which allows for session event notifications to be sent to session clients participating in the same SSO environment. The server is capable of sending session event change notifications (push model) to clients who have registered for notifications. Alternatively the clients can periodically poll the server to ask (pull model) for changes in the sessions. These session events may include the session state changes, for example, session creation, session timeout, and session termination events. Either way, the remote application can find out that the user session state has been changed and make appropriate decisions with respect to the resource access.
Interestingly, there is a more fine-grained way of receiving change notification for a specific session property that is set as part of the session token. It could be a performance issue if property change notification is set for every property, so use this feature with caution. The administrator can configure a certain property for which the clients wish to receive change notification. It is a two-fold process: first the administrator has to enable the global session property, change notification flag, followed by adding the respective properties in the list of properties for which change notifications will be sent. Here are those two commands using the ssoadm command line tool.
./ssoadm set-attr-defs -s iPlanetAMSessionService -t Global -u amadmin -f /tmp/.passwd_of_amadmin -a iplanet-am-session-property-change-notification=ON
./ssoadm set-attr-defs -s iPlanetAMSessionService -t Global -u amadmin -f /tmp/.passwd_of_amadmin -a iplanet-am-session-notification-property-list=my.security.role
The server needs to be restarted for these changes to take effect. Once it is in effect, any change in the property my.security.role will be notified right away to the remote application that has registered for session notification.
Though it is out of the scope of this book, let us quickly catch up on the session high availability achieved by means of session persistence. For the deployments that require highly available OpenSSO Session Service, one should consider session failover capability provided by the server. It is relatively easy to implement with the least number of supported components, as it does not require any relation database server. It relies on the Berkeley DB component together with Java Message Queue cluster to persist the sessions. For more detailed information, refer to the documentation provided by docs.oracle.com.
The enforcement of session quota constraints in the Session Service allows an administrator to limit a user to a specific number of active concurrent sessions based on either the constraint settings at the global level or the configuration associated with the user.
With session quota constraints enabled, when there is an attempt to create a new user session, the server enforces the session quota constraints, so that if the session quota for that particular login user has been exhausted, certain actions will be taken based on the desired behavior as configured by the administrator. These actions include denying the login request (DENY_ACCESS), accommodating the new session creation request by destroying the oldest existing session (DESTROY_OLD_SESSION) or by applying customized implementation. Session quota constraints can be enforced in a single OpenSSO server deployment or in a multiple servers clustering environment with session failover enabled. Administrative users are optionally exempted from the session quota constraints as this is determined by the top level administrator role membership.