As the number of enterprise applications increases in large organizations, coordinating authentication and authorization operations for these applications becomes a complex task. In addition to dealing with the security aspects of each application, a centralized and robust policy management infrastructure is essential. This ensures that the organization's information and services are accessed in a consistent manner.
Usability considerations in a diverse environment consisting of multiple security domains requires integration of user sign-on functions with that of identity management. This need is addressed by a service or a set of services that coordinate user authentication and credential forwarding between security domains. This is commonly known as single sign-on (SSO), termed after the end user's perception of this functionality. SSO provides operational and cost benefits through the following:
Increased simplicity of user sign-on function
Improved user experience
Reduced management overhead as administrators may easily add, remove, or limit a user's access to enterprise resources in a consistent manner as dictated by access policies
The single sign-on process can be envisioned as a method of authenticating to multiple resources or services, each in its own security domain, by only being challenged once to submit authentication credentials. A high-level overview of the single sign-on process is shown in Figure 3-4. Important elements of SSO include the following:
Primary domain The domain that initially challenges the user for his/her credentials. This domain is responsible for mapping sign-on credentials (example, userid and password) to accounts in other security domains.
Secondary domains All other security domains that authenticate the user based on credentials provided by the primary domain.
Figure 3-4: Single sign-on architecture
Trust is a crucial factor in any secure operation and is no different in SSO. In SSO, the secondary domains trust the primary domain to do the following:
Accurately assert the authentication credentials submitted by the end user
Prevent user credentials from unauthorized use
The primary and secondary domains do not necessarily represent entities within the bounds of an enterprise system or an organization. These domains may be systems belonging to external organizations and those that share user identity information though well-established trust and operational agreements.
Credential Mapping in SSO
Usually, user-supplied credentials submitted to a primary domain are first forwarded to a centralized identity management infrastructure where these credentials are used to obtain the user's identity profile. Through this profile a user is mapped to another set of independent credentials, in the context of the secondary domain, which are then used for user sign-on to the secondary domain. Credential mapping, though complex from a design standpoint, yields many advantages with regard to security, manageability, and user experience.
For example, a user may wish to access divisional sales reports through a corporate portal. The user is challenged only once when entering the corporate portal. Signing on to the reporting service is automatically handled via the single sign-on process using the credential mapping process as explained earlier.
One way to optimally map users between domains is through roles. Since the secondary domain trusts the primary domain and its authenticated users, the secondary domain can control access to its resources and services through roles. Role mapping is advantageous in that as users are added and removed from the system, the application remains unaffected. Role mapping may also be combined with other credentials to customize access control mechanisms as each application's authorization needs (which may be implemented using JAAS, please refer to section "Java Authentication and Authorization Service" for details) are unique.
Elements of Single Sign-On
Single sign-on, as described earlier, is a means by which a primary domain conveys to a secondary domain that the user is in fact authenticated. However, as simple as this operation may sound, there are various elements related to designing, deploying, and managing this operation in a mission-critical environment. The following sections discuss various elements of the single sign-on process.
As part of the single sign-on operation, user identity is exchanged securely between primary and secondary domains using profiles. Profiles map messages exchanged between primary and secondary domains to a specific protocol such as HTTP, SOAP, and so on. These profiles are required to clearly define the sequence of interactions, format, message content, and trust attributes established between participating domains. Profiles may be designed using a proprietary approach or based on standardized profiles (for example, Project Liberty—see http://www.projectliberty.org).
Identity in a system is established by validating a set of credentials that corroborate a set of one or more identity assertions. For example, in a role-based system, with a password-based authentication model, a username and password would be considered as credentials that prove a user's assertion that he/she belongs to a specific role. Credentials are used in various ways in a single sign-on operation and are often the basis for establishing trust with the credential bearer. Examples of credentials include the following:
Often, system-generated URLs have some user identification information for authenticated users. Such URLs maintain time-bound information and are required to have the property of a nonce. A nonce is a random, non-repeating value incorporated as part of the data exchanged by a protocol to protect against replay attacks. A replay attack occurs when a message that has a definite validity period is replayed (that is, sent again) after its validity has expired. Using a nonce ensures that a time-bound entity such as a URL that is valid at a given point in time cannot be replayed or reused after it expires. Since the contents of a replayed (expired) message may look authentic (formatting, credentials, signatures, and so on), unsuspecting server processes may end up reprocessing the message constituting a serious security breach. Thus time-based assurance of the freshness of the message must be employed to protect against such an occurrence.
Sensitive information such as private cryptographic keys, pin numbers, passwords, and so on, that are required to be protected from unauthorized access. Such information may also be protected from tampering or fabrication.
Shared information such as public key certificates, pseudonyms, and so on.
It may be possible that credentials and the mechanisms used for authentication or authorization are not of sufficient quality to complete an attempted operation. For example, after initial sign-on, a user attempts to conduct a high-valued operation (such as an account withdrawal) that requires a more secure form of authentication. In such a scenario, a user may be required to provide a stronger assertion of identity, such as a digital signature or personal pin number. This action is known as re-authentication, and the overall process as multi-layered authentication. Employing multi-layered authentication can be a policy decision, a contractual agreement, or at the discretion of the service. Such polices and agreements may include details about the following:
User identification methods when enrolling (registering) credentials
Credential renewal policies
Credential storage, protection, and distribution (for example, encryption, access controls, and so on)
Authentication assertions should provide an indication of the quality of credentials and the mechanism in which they are exchanged between security domains. For example, authentication assertion established between security domains may be deemed of type strong if the following are true:
Digital certificates and SSL are used to authenticate the user.
Biometric identity verification in addition to digitally signed documentation are used during user registration/enrollment.
Thus, if a security domain provides authentication assertions of type strong to a secondary domain as part of single sign-on, the secondary domain may trust the assertions to a certain degree. However, this degree of trust is unlikely to be placed on assertions that originate from other security domains that do not use assertions of type strong. Thus, it is crucial that single sign-on participants clearly define their authentication type and multi-layered authentication process.
Another extension to the standard authentication mechanism is mutual authentication. Mutual authentication implies that both the user and the service authenticate themselves with each other in a reciprocal manner. For example, when establishing an SSL connection, the client and server may mutually authenticate themselves using client-side and server-side certificates, respectively. Though this feature may provide greater assurance, it does introduce a certain degree of vulnerability in that a user/client may not be adequately prepared to discern or evaluate bogus server certificates.
Liveness simply refers to whether a user attempting to perform an operation at time t1 is the same user who was authenticated into the system at time t0. For example, after logging in, the user may conduct several operations and then attempt to conduct an operation that the service deems high-value. The service may thus decide to initiate re-authentication to ensure that the user attempting to conduct the high-valued operation is in fact the same authenticated user. Though this approach does not protect against rogue users, it does augment the service's audit trail.