Definition: A user session is a Single Sign-On (SSO) session as defined by Sun’s OpenSSO project and as described by the corresponding OpenSSO Session Service Framework.
(See https://java.net/downloads/opensso/docs/architecture/session_arch.pdf). Note that OpenSSO is a framework that’s independent of 3rd Party implementations.
The Session Service provides the functionality to maintain information about an authenticated user’s session across all services participating in a Single Sign-On (SSO) environment. The Session Service satisfies a number of critical functions, which enable users to authenticate once, yet access multiple resources such that successive attempts by a user to access protected resources will not require the user to provide authentication credentials for each attempt.
It provides the fundamental administrative and monitoring capabilities for managing account holder sessions. In particular, it generates session identifiers and implements session life cycle events (e.g. session creation, session destruction, etc.), sending state change notifications so that all participants in the same SSO environment are notified.
Each additional device that the user signs in to will be issued with a unique session token and a new session will be created on the server. The session is destroyed when the user has signed out, the session expires or an administrator destroys it.
An SSO session is defined as the interval between the moment the user of an account first signs in to create a session and the moment they log out of the session.
- Create and destroy sessions
- Validate session access tokens
- Retrieve session properties, such as user identity.
- Store and retrieve user or application-defined session properties
- Notify listeners of changes to session state and properties.
- Administration functionality to enumerate and destroy sessions
- Manage session life cycle
- User Identity service
- Logging service
- Profile storage service
- Account service
Verbs & Events
There are lots of off-the-shelf session management, authentication and user identity frameworks available. The intention is to adopt an existing framework but abstract the API to permit alternatives to be selected at a later date and for functionality to be mocked to simplify development and testing. The following OpenSSO API documentation illustrates the set of verbs required.
We may choose to implement our own REST end-points that transform and forward the requests onto a chosen 3rd party service providers.