Understanding IAM Technology: Web Single Sign On (Web SSO) Part I

Update September 6, 2015: Part II in the series is now available.

Update August 19,2006: I am rewriting this entry based on the methodology I am using for some of other domains. Hopefully, the new methodology would make it more useful to some of you. I talk to a lot of people from developer background who still do not have a good background in the IAM technology. Eventhough there is a lot of information on the web, I have felt a lack of good technological discussion on the various component that actually form the IAM domain. Some of the good sources for the information on IAM are

Most of these document discuss the basic concepts but do not extend it to existing technologies and how it applies to them. This series is an attempt to look at the technology behind the Identity and access management. In the field of Identity and Access Management, the evolution of the attempt to address the IAM problems can be described so far as

Consolidating Identity Data through Enterprise Directories which reduces number of copy or digital representation of User Identity that exist within an enterprise.
Consolidating Authentication/Authorization End-points Through Web Single Sign On solutions and Reduced Sign On solutions which reduce the number of authentication and access enforcement points.
Consolidating Identity and Access control Administration Through Provisioning products along with Meta-directory, password synchronization and self-service tools which reduce the number of administration tasks that need to be done with regards to managing identity and access control information.

In order to understand these various technologies, I will try to cover the following topics for each of the them

Driver for the technology
Hinderance or shortcomings of the technology
Glossary
Use case that the technology addresses
Data Model
Architecture
Some examples from opensource world

This edition, covers the Web single sign on (Web SSO) technology. Please check out this introductory article to get some idea about the identity management.

Driver

The basic set of drivers for the web single sign on technology has been

User Experience fewer logins means less time spent remembering password, resetting password and typing passwords i.e. higher productivity.
Extract Security from Application Most of us would agree that it is tough to get security right esp. for the people whose strength is the business side of the application. Technologies like Web SSO ease the burden of security from the shoulder of business developer and allows them to concentrate on developing business solutions and add security later. Even though this approach takes care of only one aspect of the security, it is a one less thing to bother about.
Compliance and Audit A lot of laws around audit and compliance have made it important for enterprise to answer the question "who accessed what when?" and these audit facilities have not been built in to a lot of legacy applications. Besides that it is costly to replicate them across all the new applications. The Single Sign On solutions allow you to centralize audit and hence monitor compliance. In addition to that single sign on systems come centralized management system which allow a better management of the policies that are enforced at point of entry.
It's the economy, Stupid!! - fewer passwords means fewer calls to helpdesk to reset password.

Hindrance

There are a few issues that should be considered

One key to Kingdom With simplification comes the risk accumulation in terms of the basic issue that there is only one authentication between a rogue user and all the services available. This can be mitigated by using strong authentication and repeat/stepup authentication(repeat authentication is a requirement to the user to re-login prior to high value transaction or access to sensitive information, while, stepup authentication refers to the idea of using different authentication factor like token compare to password used for initial login prior to high value transaction or access to sensitive information).
Application Integration With single login comes the nightmare of onboarding existing and new applications. This can vary from being very simple like installing available single sign on adapters to very complicated third-party product changes not supported by third party. This is one of the most expensive part of single sign on implementation and sometimes dwarfs the cost of single sign on product itself. Besides that not all legacy applications can not be integrated with the Web Single Sign On technologies.
...

Glossary

Most of the products have developed their own glossary of terms but most of the them share common terms which have pretty close definitions. But in order to develop a discussion which is more meaningful, we may need to standardize on the definitions. There are a a lot of definitions that have been developed and I will try to use them as much as possible.

Audit - The process by which selected events are stored in persistent and resilent repository for monitoring and future review.
Authentication - The process by which the User identifies itself to the Web Single Sign On System.
Authentication Channel - The process of authentication involves exchange of data between user and Web SSO System. The medium over which the exchange of data happens is called Authentication Channel. In most of the Web SSO systems this typically happens through browser over the network. But incase of two channel authentication method additional channel like email, mail, cellphones may be involved.
Authentication Factor - Typically an authentication method can be classified into one of three types i.e. what user knows, what user has or what user is. Each of these types are referred to as an Authentication Factor.
Authentication Method - The authentication can be performed using a wide variety of methods (based on something that user knows, has or/and is) like passwords, certificates, tokens, biometrics. These are refered to as Authentication Method.
Authorization - The process by which Resource Manager or Web SSO system, identifies whether the user can access the requested resource. Please check this location for more information about this topic.
Browser is the application used by users to access the web application. This includes, but is not limited to, PC browser like Internet Explorer, Mozilla Firefox.
Cookie is a mechanism used by Resource Managers and Web SSO systems to store some data on browser used to access them.
Identity Aware Application is an application that performs additional processing like personalization, data control and transaction management based on identity of the user performing the transaction.
Resource Manager is the a device that has the capability to accept the request for resource from browser, map it to appropriate entity (data, file, business function), retrieve the entity (if user is authorized) and return it to the browser to be presented to the user. This is typically represented by Web Servers and Application Servers.
Session timeout - The preset time interval after which the user session is invalidated. Typically two types of session timeouts are used i.e. hard-timeout and idle timeout. Hard timeout is the duration after which user session is invalidated irrespective of the state of the user interaction with Web Applications. Idle time is defined as the duration during which there is no browser Web Application interaction. Idle timeout is defined as the idle time after which a user session is invalidated.
User is an entity that needs to access multiple web applications to retrieve data, perform transaction or manage system itself. User may represent an actual person, a group of persons that share common identity, another application that needs to access data or perform transaction on behalf of one or more users. Typically a user that has the capability to manage the Web SSO system itself is referred to as an "Administrator".
User Session is the continuous time interval during which the Resource Manager provides access to its service to the user. The session starts with user accessing the Web Resource through the Resource Manager and typically starts with successful authentication and ends with a direct action from the user (closing the browser, performing logout) or indirect action by Session Manager (session timeout, Administrator logout).
Web Application Any identity aware application that can be accessed over the network (either intranet or internet) using browser.
Web Resource/Resource is the information, transaction that user needs access to and which is part of a Web Application. This is typically represented by URL.
Web Single sign on (Web SSO) The facility which allows a user to access (if authorized), for a limited time (user session), multiple web applications, which exist in same security domain, after authenticating once.

Use Case

There are multiple use-cases associated with Web Single sign on systems. These use-cases can be divided in to two category i.e. Runtime and Administration Use-case (the format has been borrowed from the OpenSSO use-case document).

Installation (Administration)
1. Summary - An administrator would setup and configure the Web Single Sign On environment
2. Prerequisite - None
3. Actors - Administrator
4. Main Success Scenario - A scalable, failure-resilient, architecture must be developed. All the components get installed properly and installation checklist is passed.
5. Alternative - There are a lot of product specific dependencies that may lead to failure of the installation. Please consult the product specific installation guide.
Application Onboard (Administration)
1. Summary - An administrator and Application developer would setup the Web SSO and change application to provide a Single Sign On experience to user.
2. Prerequisite - Web SSO and Application have been installed.
3. Actors - Administrator and Web Application Developer
4. Main Success Scenario - Administrator is able to setup the various Authentication and authorization requirements for the Application like
  1. What are the various authentication methods that application needs and what is their hierarchy?
  2. What are the authentication factors and channels, if any, dictated by the application's authentication and authorization model?
  3. How does the application want to control access to the URLs, Web Components? For example which URLs may be accessible to everybody, which URL require authentication, specific URLs that need 2 factor authentication and so on.
  4. What additional user specific information (like user's roles, attributes) need to be made available to application (since the application is not managing the identity but trusting and reling on Web SSO for the identity information)
  Besides that the application developer needs to change application so that
  1. Application is no longer performing authentication or URL level authorization which can be performed by Web SSO system
  2. Application does not store and retrieve the identity information which can be provided by Web SSO system through its interface (e.g. HTTP Header, API, Cookies, etc.)
  3. Application session management is synchronized with Web SSO in terms of session establishment, timeouts, logout.
  4. All the functionality of the application work after Web SSO sytem has been added to infrastructure. Eventhough in most of the product scenarios this is not an issue, due to the architecture of some of the other products this used to be a big issue.
5. Alternative - Due to non-availibity of web application source code or non-availability of the configuration parameter, the application onboarding could be a very tough or unsuccessful exercise.
User Login (Runtime)
1. Summary - A user accesses the Web Application protected by Web SSO
2. Prerequisite - Web Application has been onboarded
3. Actor - User
4. Main Success Scenario - Please see below for the detailed description
5. Alternative - Please see below. Password Reset, Self-service, Self-registeration.
The steps that typically occur during the sign on are as follows
1. User uses browser to request access to resource(URL) to resource manager (Web/App Server + Web SSO product).
2. Depending on Web SSO architecture, Resource Manager may receive the request and passes it to Web SSO for authentication and/or authorization or Web SSO may intercept the incoming request to authorize it.
3. The authorization process would involve the one or more of the following steps in the given order
  1. Session Identification - The Web SSO system checks for the presence of a session identifier (typically a cookie) in the request. This session identifier is used to identify the session data by Web SSO on its side. In case it is not available a new identifier is created and a corresponding session object is added to Web SSO's session "table". In order to provide automatic session failover, some products may package the complete session data into a cookie (encrypted ofcourse). This can then be used by Web SSO or Resource Manager to establish a new session without requesting user to login again.
  2. Anonymous Access - If there is no user identity associated with the session, the Web SSO or Resource Manager will check whether the resource can be accessed anonymously. If successful, it will provide access to the request resource otherwise it forces user to authenticate.
  3. Authentication - If no user is associated with the session, based on the configured authentication method and channel, the user would be asked to authenticate by the system. If Web SSO determines that authentication was successful, user data (like user attributes, roles) is collected, processed (for example user mapping), stored in the session securely. After the authentication is complete, a pre-configured step like requesting user to approve an access policy or user-profile update may be performed. After this has been completed successfully, either Web SSO or Resource Manager would perform authorization. If authentication is not successful one or more of the following steps may happen
    1. If there is pre-configured maximum consecutive invalid login attempt (for example 3) trigger set, that may be activated after user fails to login and result in
      1. The account being locked out for a pre-defined time interval (referred to as account lockout interval) after which that particular user id can be used to login.
      2. The account being locked out permanently and may require user to contact administrator (or help desk that provides the administrative service) to "unlock" the account
      3. The password reset page may be displayed to allow user to reset the password and unlock the account.
      4. The system may switch to a different login process. (for example if SPNEGO authentication is being performed and that fails, the user may be presented a form based login to authenticate)
    2. Otherwise the user may be provided another chance to perform the login.
  4. Authorization - If a user is associated with the session, the Web SSO or Resource Manager checks whether the user id is authorized to access the resource. If authorized then the Resource Manager provides access to the resource otherwise it may return an access denied error or, if possible, it may force user to perform setup authentication.
  5. Audit - The status of all the successful and failed events, along with information like user identity, IP address, URL, date and time associated with the event, is stored in a resilient repository for monitoring and future review purpose.
  6. Stepup Authentication - Some times due to authorization requirement, it is required that the resource may accessed by using more secure authentication method (for example two factor or two channel authentication or same authentication). In such scenario, Web SSO system forces the authenticated user to perform authentication. This is referred to as Step-up Authentication.
4. After the Web SSO has sucessfully validated the authentication and authorization, it may provide additional information to the resource manager by adding identity data, like identity roles, groups, attributes, to the request. The resource manager may authorize the request and then send the application home page (resource) after performing personalization, if required, based on user information received from the request or Web SSO. Please note that the resource manager accepts and trusts the user data provided by Web SSO.
5. The response generated may be authorized by Web SSO and may undergo transformation for various purposes.
6. The browser will receive the response and which it provides to the user.
User Global Logout (Runtime)
1. Summary - An authenticated user performs logout from the Web SSO system
2. Prerequisite - User has an active session with Web SSO.
3. Actor - User
4. Main Success Scenario - After the user has performed authentication, they would be able to access the web application directly. In that case the global logout functionality can be provided in following ways
  1. Application Link - The Application would provide the link to the special URL which will be captured by Web SSO or forwarded to Web SSO by Resource Manager to trigger a session termination
  2. Web SSO Addon - In case the Web SSO or the application provides the capabilities (for example portlets in Application Portal), the Web SSO can be exposed as an integrated component within the application through portlets, IFRAME, etc which will allow user to perform a logout.
  3. Browser close - Incase the user decides to close the browser, there might be a javascript that gets triggered by the close event and invokes the global logout link from the browser.
  On activating the global logout, the Web SSO terminates the user session, may inform the applications to terminate their sessions, and may redirect user to a pre-configured application/user/web sso specific page if browser is available. The Web SSO must audit the event for monitoring and future review.
5. Alternative - None.
Bookmark/Timeout (Runtime)
1. Summary - A user uses a bookmarked URL to access the web application or access a functionality of web application after either hard timeout or idle timeout.
2. Pre-requisite - User does not have an active session with Web SSO.
3. Actor - User
4. Main Success Scenario -
  1. The user uses either a bookmarked URL or an invalid session (not known to him) to connect to the Resource Manager.
  2. The Resource Manager or Web SSO intercercepts the request and determines that user has not authenticated or is using an expired session and redirects user to Web SSO for authentication.
  3. The Web SSO must audit the event for monitoring and future review.
  4. If the authentication is successful, user is redirected to resource manager with the URL that was being used earlier to access the request.
  5. The resource manager may choose to either display the requested URL or redirect user to the application home page
5. Alternative - Incase authentication is not successful, authentication error is displayed and user may use password reset, self-registeration use-case.
Self-service Password Reset (Runtime)
1. Summary - A user has forgotten the password/shared secret and wants to reset the password/shared secret.
2. Pre-requisite - User already has an account with Web SSO.
3. Actor - User
4. Main Success Scenario -
  1. User would go to password reset screen by either clicking on a link or may be redirected to it by the web sso system after login failure.
  2. The password reset system may provide one of the many available process to validate the user
    1. Question/Answer - This is one of the most popular password reset system where the user provides answer to pre-defined/selectable/user-defined questions at the time of registeration (or when they may authenticate for the first time). During the password reset process one or more of these configured questions are presented to user for answer and depending on the setup, the number of correct answers to question would determine that the user is a valid user
    2. Multi-channel - Incase the Web SSO has information about another channel to the user (for example a pre-registered cellphone, phone, email address), the possesion of that may be used to validate the user. This can be done by sending a token, special URL to the second channel and the user may be required to use the primary channel (i.e. browser) to provide that token to Web SSO to validate himself.
  3. After the validation has been performed, the new password needs to be set. A variety of processes are used to fulfill this step
    1. One-time or permanent Password via Other channel - The new password is provided to the user through another verified channel like email address, cell phone, etc which can be used by user to login once and then change the password.
    2. Direct password reset - The user would be allowed to set the new password directly after the validation has been performed.
  4. The Web SSO must audit the event for monitoring and future review.
5. Alternative - If the password reset is not successful or the requisite information about the user is not available for password reset, the user may have to contact Web SSO Administrator or helpdesk to reset the password.
Self-registeration (Runtime)
1. Summary - Users needs to register themselves with Web SSO system before accessing the application
2. Pre-requisite - Web SSO system is installed and configured. Application is configured.
3. Actor - User
4. Main Success Scenario -
  1. User tries to access the Application and is redirected to Web SSO authentication page where they are provided link to register or User clicks on a self-registeration URL made available to him by email, application home page, etc.
  2. User is presented with form to provide all the relevant information that is required by Web SSO and the application including authentication method related information like user identity, password, question/answers, as required. Please note that due to the growing privacy concerns and potential issues w.r.t. personal identifiable information, it is recommended that only minimal information needed for personalization and validation must be requested from the user.
  3. The information provided by the user is verified against data validation policy (for example password policy may state that password must be more than 8 character with numericals and symbols, SSN must be specified format, email address must be owned by the user). Some information needed to complete the self-registeration may be generated based on user data (for example in some case user id may be system generated).
  4. The required information is stored in the Web SSO's Identity Repository for future access.
  5. The Web SSO must audit the event for monitoring and future review.
  6. User is informed that registeration has been completed and he may be requested to login and then redirected or automatically redirected to the requested URL.
5. Alternative - Incase the user is unable to complete the registeration, he may try at a later time or call the Web SSO Administrator (or helpdesk). If user data validation can not be completed, user may have to contact Web SSO Administrator (or help desk ) to complete the process.
User Provisioning (Administration)
1. Summary - User that needs access to Web SSO system is provisioned by external system or application
2. Pre-requisite - Web SSO system is installed and configured. Third party provisioning system is setup to provision the user to Web SSO based on an event.
3. Actor - Provisioning System
4. Main Success Scenario -
  1. Due to an event in the Provisioning System (like new employee, customer, assignment of a role), the system may decide (based on the setup) that user needs permission to access a specific application protected by the Web SSO system
  2. Provisioning system may have direct access to the identity repository used by web sso system or it may have access to web sso system through the Web SSO Administration/Provisioning API.
  3. Provisioning system would check whether the user is already present in the Web SSO system (or its repository). Incase it is not present, the user information will be added to the Web SSO system using API or direct calls to the repository. Incase the user is present only the necessary changes needed to enable the new application is performed.
  4. Both Provisioning System and Web SSO must audit the event for monitoring and future review.
5. Alternative - Incase the provisioning fails, the provisioning system may need to fallback to a failure workflow which may require notification to Web SSO Administrator (or help desk) to manually add the user to Web SSO system.
Self-service for identity (Runtime)

Summary - User that needs update his information into or un-register themselves from the Web SSO system
Pre-requisite - User has an active session with Web SSO system and the system provides the capability of self-service
Actor - User
Main Success Scenario -

Dependening on the way in which the Web SSO exposes its services (as described in the global logout usecase), user would click appropriate Web SSO specific link to access the self-service interface.
User can choose to update its information in Web SSO or provide his preference to unregister from the Web SSO service.
Incase user chooses to update his information, Web SSO would store the updated information in its repository and then redirect user to the homepage or the application being used prior to the self-service.
Incase user chooses to "unregister" them selves, the Web SSO should tag the identity for future deletion or delete the information immediately. In addition to that Web SSO may indicate to the Web Application it protects that user has "un-registered" himself and all his information must be removed (or tagged for removal) from their repository. The event must be audited and no audit information about user is removed.

Alternative - Incase the update or un-registeration fails, the Web SSO Administrator (or help desk) may be contacted to update or un-register the user as needed.

Identity Synchronization (Administration)

Summary - In the event of user data being updated or user being de-provisioned in the provisioning system, Web SSO system needs to be updated
Pre-requisite - Web SSO already has the user account for the corresponding user.
Actor - Provisioning System
Main Success Scenario -

Due to an event in Provisioning system, the user data needs to be updated in the Web SSO system or user needs to be de-provisioned from the system
The provisioning system would use the Web SSO API or the Repository specific interface to update or delete, as needed, the user from the system.
The information may be removed or tagged to be removed from the system.

Alternative - Incase the provisioning fails, the provisioning system may fall back to failure workflow which may require notification to Web SSO Administrator (or helpdesk) for manual provisioning.

These are the use-cases that could think off. I would really appreciate input on these usecases or any additional use-cases that you guys can think of. I will write about the data model and architecture of the Web SSO system.

Search This Blog

Identity and Access Management