Understanding IAM Technology: Web SSO Part II - Data Model (Authentication)

This article is in continuation of the previous article. I started writing this long back but kind of left it mid way as the entire web SSO domain had matured at that time. Due to multiple reasons we have seen new generation of people entering the Web SSO domain. Keeping them in mind, it made sense to revisit this old post and update it with my thoughts and ideas. I do apologize for any inconsistency you may find between my last article and this one (given they were posted 9 years apart).


The core Web SSO functionality are as follows

1. Identification - Do we know the identity of user who is trying to access the system?
2. Authentication - Can the user (person/application/service) prove that he/she/it owns the identity?
3. Authorization - Can the identified and authenticated user perform the specified action (e.g. read) on the resource (e.g. URL /myapp/premium) within the context (e.g. from the given ip address at the specific time of day)
4. Identity transfer/Federation/Assertion - Ensure that authenticated user can access authorized functionality of any application that is part of SSO/federation security domain without authentication.
5. Attribute enrichment - Ensure that application that is part of security domain can access additional information about the user (e.g. role, permission, display name) that it is authorized to.
6. Session management - all the applications that are part of federation must be bound together through a single session that user establishes at the time of first login in the domain and ends by initiating a global logout.
7. User and Password management (primarily self-registration and self-service) - allow users to register themselves and then manage their identity information and credential information. Even though these are considered to be part of a provisioning solution, most of the stand alone web sso product/services have to support these basic features.

Please note that I am not making any distinction between the old concept of federation and Web SSO since the two concepts are just a technological manifestation of the same underlying process.

The focus of the rest of the article is on authentication, identity transfer/federation and attribute enrichment within the context of authentication/login process.

Any design of the Web SSO solution has to represent the following concept either explicitly or implicitly during the design.

Security Domain

This is the scope in which all the other components exist. Most of the logical concepts of the data model like applications will exist within a particular security domain. Some of the components that represent an architectural component (e.g. a security gateway) may need to exist outside the scope of one security domain.

Application

The application forms the highest level of resource that is typically used to develop authentication and authorization policies. The application has following characteristics

1. Application is identifiable by a unique identifier within the sso system
2. The application is typically associated with an architectural component like web server or application server that hosts the application.
3. Applications also form an important scoping mechanism for delegated administration to allow application specific administrators and developers to be part of on-boarding and management process.

User

User are people, applications and services who need to access an application. They have following characteristics

1. Users must be uniquely identifiable within a security domain by an identity. In most of the cases, there may be a single attribute like user id or email that uniquely identifies the user but in a federation or multi-domain structure, additional context may be needed to uniquely identify the user (e.g. in case of multi-domain AD setup, user may need to specific their domain).
2. Users may have one or more attributes (e.g. name) which may be single (e.g. name) or multi-valued (e.g. groups) associated with them. This information may be of interest to application (e.g. display name, groups).

Directory

Directory stores the user's identities and attributes. Typically a user is uniquely identifiable within the directory which may or may not match user's identity within the security domain. For example, in a security domain a user's email may be used to uniquely identify users across one or more directory while AD, which may be one of the directory used by security domain, uses GUID or Distinguished Name to uniquely identify a user's identity. 

Directory may or may not have credentials that can be used for authentication. We will explore this idea further below.

Directory can also be used to help with identification in the context of authentication (e.g. biometrics).

Authentication Method

Authentication method describes the type of authentication credential used for authentication. This is classified based on the authentication factors. Typical authentication methods supported  as classified based on authentication factor are as follows

What you know

1. Password based including API keys and other similar shared secrets

What you have

1. OTP based (e.g. google authenticator, hardware and software tokens)
2. Smart Cards
3. Certificate
4. Kerberos and other standard and proprietary token based (e.g. JWT)

What you are

1. Biometric (may be used in addition with other authentication factors)
2. Adaptive authentication which leverage the user's behaviour and other environmental factors to assert the user details

The Authentication method may or may not be associated with a directory with user information. For example a certificate based authentication process may not have an associated directory since there is no information that needs to be stored for each user trying to authenticate while in case of passwords you would need a directory to store the shared secret.

Authentication Channel/Protocol

Authentication channel refers to the underlying protocol/process used to transfer the authentication credential from user to authentication server (mostly Web SSO). Some of the examples of these authentication channels are

1. HTTP POST and cookies/HTTP responses - used primarily with password based authentication. Most of the HTTP Post based implementation are based on single round trip (i.e. you submit your password and you get success/failure response) but there are other scenarios (e.g. OTP based) which require multiple round trip. Please note that we are not talking about step-up authentication (see below) here where two authentication methods are combined together on the same channel/protocol. The Form based authentication used by web applications will fall in this category as will custom URL based API authentication models. Please note that due to it's nature (i.e. this method can not be combined with application transaction/operation), this approach has a firm dependency on session management.
2. HTTP Authorization header - used to transfer passwords (Basic Authentication, Digest, etc) and tokens (like Kerberos, NTLM, JWT, OAuth, etc). Integrated Windows Authentication (SPNEGO) which rules the Microsoft world belongs to this category. Due to it's nature, this approach can be combined with application transaction to remove the explicit authentication step (see above) and associated session management.
3. HTTPS - besides supporting all the HTTP based authentication channel/protocol, the HTTPS also can support certificate based authentication methods (SSL). Please note that even though not explicitly identified here, it is recommended that all the HTTP channel/protocols described above should use HTTPS to leverage the transport layer security inherent in the protocol.
4. IPSec and other Networking protocols (like RADIUS, IP Sec, etc) that support password, certificate and other authentication methods through specific authentication protocols (like EAP, MS-CHAP, PAP, etc). This article will not focus on these set of protocols.
5. SAML used to transfer various types of supported tokens (e.g. user/password, kerberos, etc) from one security domain to another. The transferred token can then be used for asserting an identity within the security domain. Due to complexity of the protocols involved, this is typically associated with a session management.
6. OAuth  including Social logins like Facebook, google, etc that are used to transfer user identity after authentication. Due to complexity of the protocols involved, this is typically associated with a session management.

Many of the authentication channels are associated with specific authentication method (e.g. Certificates are mostly used with SSL). In addition to that same or different authentication channels may be used by different application channels (e.g. Web Application versus Web services/APIs) 

Authentication Policy

Authentication Policy defines the process that Web SSO must use to drive the authentication for a given user. This process typically involves the following phases

1. Identification - an optional step that may collect various information like IP address, user id and other environment details (like browser and os information in case of adaptive authentication) to identify the user and it's context. This information may then be used to decide on the applicable authentication policy for the user. 
2. Authentication - based on various factors like user's IP address, user id, etc, the system identifies the authentication method and authentication protocol. For example based on the user's IP address, Web SSO may trigger Kerberos over IWA for intranet and form based (HTTP Post) login process for internet. Similarly based on the identified information and associated risk analysis (e.g. user's is access web app from a new location), the policy may require multi-factor authentication for the user. Each authentication process may have additional policies (e.g. password expiry policy) which may trigger different result for the authentication besides success and failure.
   Please note that authentication process may involve one or more steps. The steps are a combination of authentication methods, associated authentication channel and configured directory (if applicable). Most of these authentication "steps" must be sequential or appropriately prioritized to ensure that the final response is always the same. Some of the methods used are
1. Sequence based - each step is tried in a predefined sequence until a success is encountered.
2. Weight based - the step may have associated control flags of required, sufficient, optional, etc which determine the weight of the result from the step in final determination. 
3. Policy based - a complex policy language may be used to determine whether the step is applicable in a particular scenario (see example about IP address used for IWA or form).
4.  A combination of above may be available to ensure that final response is predictable.
3. Identity Mapping - Even though most of the time the identity authenticated would be known to the security domain, we still need to call out this step to ensure that model is extensible. Some of the example where the identity mapping comes in to play are
1. Federation - In some cases where the user identity mapping may be many to one OR one to many (i.e. all the users of a given vendor should use vendor id to access system OR depending on the specific role user wants to activate user may get different identity in the service provider), identity mapping has to be done by web sso product
2. Federation - Users may want to attach their existing user id on a website with their facebook or google user id as part of new login feature rollout. In such scenario you need to maintain an explicit mapping between the two.
3. Authentication - In specific use-cases like Kerberos or certificate, the user identity are provided as an AD user id (e.g. domain\user) or certificate DN. This would typically be mapped to a security domain user id before further processing can be done.
4. Attribute enrichment - involves collection of various attribute and values (single or multivalued) from various directory based on the identity (with or without additional directory specific mapping). These attributes may be collected as part of initial profile establishment or just in time for identity transfer to specific application.
5. Audit - may not be a separate step but part of each and every phase of authentication process.
6. Session establishment - may involve storage of various information (like login time for hard or idle timeouts) either as tokens or in local or distributed storage with unique identifiers (called session id). These session id may then be associated with application session id when the application is accessed first time. This information may be used by applications, authorization engine, session lifecycle management engines (that may enforce session timeouts, user to session mapping policies) for enforcing various associated policies. Any Web SSO system that supports a concept of session typically also has a concept of logout which is expected to disassociate the application sessions from authenticated session and destroy any information stored in authenticated session.

After the initial authentication process is completed, other aspect like authorization and application specific identity migration may get triggered.

Summary

Any Web SSO that wants to implement the authentication capabilities must design for the various items identified above to ensure that they are not constraint as they enhance the system over time. It is important to distinguish the idea of directory (data store), authentication method and authentication channel within the Web SSO to ensure that you are not restricted by potential new requirements (e.g. handling new tokens, authentication channel that require multiple round trips) as you try to enhance the product/service beyond basic password and social login use-cases.