Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

9.2.1 Simple SSO architectures

SSO is relatively easy to implement in authentication infrastructures that are using a single authentication authority. Such an environment is illustrated in Figure 9.1. In this environment users have a single set of credentials. Remember that the concept of “users” must be interpreted in a large sense: It covers all security principals that are accessing the resources under the control of the authentication authority. Figure 9.1 shows a user and a resource server security principal trusting the same authentication authority. Linked to the authentication server is a credential database, which is the primary source for account and credential management.

Figure 9.1: SSO with a single authentication authority and a single authentication server.

Over the past years operating system vendors such as Novell and Microsoft have proven that SSO can easily be implemented in homogeneous LAN and intranet environments where all machines are running the same operating system and trusting the same authentication authority. Extranet Access Management System (EAMS) software vendors such as Netegrity, RSA (Securant), Baltimore, Entrust, and many others have proven the same thing for homogenous Web portal environments. Finally, remote-access authentication infrastructures using RADIUS, TACACS, or

TACACS+ showed that setting up SSO is relatively straightforward in environments using a centralized authority that communicates with a set of authentication proxies using a single well-defined authentication protocol. A nonexhaustive list of software products supporting simple SSO is given in Table 9.1.

Things get much more complex if the SSO scope is extended to cover different platforms and different organizations, which are using different authentication credentials and protocols and are governed by many different authorities. Usually this also means that the infrastructure has to deal with multiple credentials per user.

Having a single authentication authority does not necessarily mean that only one authentication server and a single credential database are available. For scalability and performance reasons, a single authentication authority may consist of multiple authentication servers and a set of replicated credentials databases. Figure 9.2 illustrates SSO in an environment with a single authentication authority and multiple authentication servers. Note that the credential database is replicated to all authentication servers. To avoid ambiguous user authentication, the replication of security credentials requires a single-master replication model. For the same reason, account and credential management can only be done on the data stored in the master credential database.

Figure 9.2: SSO in an environment with a single authentication authority and multiple authentication servers.

9.2.2 Complex SSO architectures

A big challenge in today’s authentication infrastructures is to extend the SSO scope to cover many “different” authentication authorities. “Different” in this context means implemented on different platforms and governed by different organizations. In most scenarios these infrastructures also have to deal with multiple credentials per user and many different authentication protocols.

To ease the explanation of the different SSO architectures used in complex SSO setups, let us first look at how authentication works in an environment with multiple authentication authorities but without SSO support (as illustrated in Figure 9.3).

Figure 9.3: Authentication in an environment with multiple authentication authorities.

In the setup illustrated in Figure 9.3, the domain that the user uses most often is called the user’s primary authentication domain. Domains that users use less often are called secondary authentication domains. Because in the example no SSO is available between the primary and the secondary authentication domains, when a user wishes to access resources in the secondary domains, he or she has to authenticate to the TTPs of those domains using credentials as defined in that particular secondary authentication domain. Every secondary authentication domain also has its proper credential database. There is no need to explain that this setup creates an enormous credential-safeguarding burden for the end users. Note that in this setup the user uses different authentication tokens, one per authentication authority.

SSO architectures dealing with a single set of credentials

The simplest complex SSO architectures are the ones using a single set of credentials, recognized by many different authentication authorities. There are two important flavors of complex SSO architectures dealing with a single set of credentials: token-based and public key infrastructure–based SSO systems.

Both SSO architectures provide SSO in a rather homogeneous environment. Homogeneous in this context means using a single account naming format and authentication protocol that are supported by every entity, application, and service participating in the SSO environment.

Token-based SSO systems

A classic example of an authentication protocol used for token-based SSO is the Kerberos authentication protocol. Kerberos is an open standard defined by the IETF that has been implemented on many different platforms.

In a token-based SSO architecture users get a temporary software token when they have been successfully authenticated to the TTP (as illustrated in Figure 9.4). This token can be cached on the user’s machine and can be reused to prove the user’s identity to other secondary authentication domain TTPs. To validate the user token, the TTPs use cryptographic methods that are based on secret keys that are set up between the secondary authentication domain TTPs and the primary authentication domain TTP. This cryptographic key material represents a trust relationship between primary and secondary authentication domains.

Figure 9.4: Authentication in a token-based SSO environment.

Contrary to the tokens we will discuss in other SSO architectures, the tokens used in token-based SSO systems are valid for more than a single authentication authority. Agreed that in some token-based setups users do have more than a single token, but in that case the authentication protocols support the automatic and transparent exchange of the token of one authentication authority for a token issued by another authentication authority.

In the Kerberos case, users authenticate to a central authentication service, called the Kerberos key distribution center (KDC) (the authentication TTP). If their authentication credentials are valid, they receive a ticket (the software token), which enables the user to request other tickets from the KDC in order to access other resources in the primary and secondary authentication domains. The tickets prove to the resource servers that the user has been authenticated before by a trusted authentication service—the Kerberos KDC.

The Kerberos authentication protocol has inspired the developers of the authentication services for the Open Software Foundation’s (OSF) Distributed Computing Environment (DCE). Microsoft has implemented Kerberos as the default authentication protocol of Windows 2000. CyberSafe sells plug-ins that can be used to enable an operating system platform to generate, understand, and validate Kerberos credentials (this process is also known as “Kerberizing”).

The Kerberos token-based SSO typically uses remote procedure calls (RPCs) to transport authentication tickets. In HTTP-based environments, token-based SSO can be provided using HTTP cookies. The latter mechanism is used by many Extranet Access Management Systems (EAMS) such as Netegrity’s SiteMinder or Oblix’s Netpoint when dealing with multiple authentication authorities. Microsoft currently uses a similar cookie-based token system to extend the SSO functionality of its Passport Web authentication solution across different Web sites.

Token-based SSO software comes out of the box with many of today’s most popular operating system platforms (Windows 2000, Netware, and so forth). Table 9.2 gives some examples of software products providing token- based SSO support.

Public key infrastructure–based SSO

In a public key infrastructure–based (PKI-based) SSO architecture (illustrated in Figure 9.5) users first register themselves at a trusted authentication authority [in this case called a certification authority (CA)] or at one of the authentication authority’s registration agents [called registration authorities (RAs)]. During this registration process, different things occur: Users identify themselves using a set of credentials; a piece of client-side software generates an asymmetric key pair; and the public key of this key pair is offered to the CA (or RA) for certification. Upon receipt of the user’s credentials and the public key, the CA (or RA) will verify the user’s credentials. If the credentials are valid, it will generate a public key certificate and send it back to the user. The user’s public key certificate and the user’s private key are cached on the user’s machine (or on a smart card or cryptographic token). They both are used to generate a kind of software token similar to the ones used in token-based SSO systems. These tokens are used to prove the user’s identity to other secondary authentication authorities in subsequent authentication requests.

Figure 9.5: Authentication in a PKI-based SSO environment.

A major difference between a token-based and a PKI-based SSO architecture is that in the PKI case the cryptographic methods that are used to validate the user token are asymmetric cryptography-based (using public and private keys). The outcome of this validation process also largely depends on the trust relationship that is set up between the secondary authentication authorities and the primary authentication authority. In the case of a PKI-based SSO architecture, the trust relationship between primary and secondary authentication authorities is represented by a secondary authentication authority’s certificate (issued by the primary authentication authority). Similar to the tokens discussed in token-based SSO architectures, the tokens used in PKI-based SSO systems are valid for more than a single authentication authority.

Contrary to token-based SSO systems, PKI-based SSO systems are a relatively new technology. Early implementers of the technology experienced lots of interoperability problems. The latter were mainly related to immature PKI standards. Over the last two years the security software industry and standardization organizations such as the IETF have made important efforts to make the PKI-based SSO systems enterprise-ready. Another early adopter problem was that few applications were PKI-enabled. Although the latter problem has not been fully resolved, most application software vendors have modified their application to let them understand PKI-based credentials. Table 9.3 gives some popular examples of PKI software solutions.

* In september 2003 BeTRUSTed planned to acquire the Baltimore Unicert PKI software.

SSO architectures dealing with many different credentials

There are three different flavors of SSO architectures that can deal with many different credentials: architectures that use credential synchronization, architectures using a secure client-side cache, and architectures using a secure server-side cache.

Contrary to token-based SSO, these three SSO architectures can provide SSO in a more heterogeneous environment. Besides different credential types, they can also support different account formats and multiple authentication protocols.

Credential synchronization

Figure 9.6 shows an SSO architecture that is using a credential synchronization system. A classic example is a system that synchronizes user passwords between the credential databases of different authentication authorities. Although this architecture supports multiple credentials for every user, they are kept identical using the credential synchronization mechanism. Credential synchronization systems typically use a single master credential database, which can be used by administrators to update the user credentials.

Figure 9.6: Password synchronization-based SSO.

Because in this setup the user is still prompted to enter his or her credentials by every single authentication authority, these systems are not considered true SSO systems. Many security experts consider it a very dangerous practice to synchronize credentials between the databases of different authentication authorities. Their objections are based on the “key to the kingdom” argument mentioned earlier. Table 9.4 gives some examples of credential synchronization software products.

The technology behind credential synchronization software is not as simple as Figure 9.6 may make you think. A key problem is the credential storage format in the credential databases of the different authentication providers. Very few authentication providers use the same storage format. Also, credentials are typically stored in a hashed format, which means that it is impossible to derive the original password from the hash. Because most providers use a different hash format, you cannot just synchronize the credentials between databases. That is why credential synchronization can only occur when the credentials are updated (e.g., when a user updates his or her password).

Secure client-side credential caching

Figure 9.7 illustrates an SSO architecture that is using a secure client-side credential caching mechanism. In this setup a set of “primary credentials” is used to unlock a user’s credential cache. Later on, when the user wants to access resources requiring different authentication credentials, the other credentials are automatically retrieved from the local credential cache and presented to the authentication authority. If the credentials are valid, the user will be logged on transparently to the other resource servers. Because in this setup authentication to the secondary authentication domains relies on the credentials for the primary domain to unlock access to the credentials of secondary domains, the secondary domains must trust the primary domain.

Figure 9.7: Authentication in an SSO environment using a client-side secure cache.

In the early days of secure client-side credential caching, it was combined with client-side scripting to automate the SSO process. This created a lot of administrative overhead. Nowadays credential caching is combined with more intelligent and adaptive client-side software that can automatically retrieve and provide the correct credentials to the destination server. Table 9.5 gives some examples of secure client-side cache-based SSO software products.

In the context of this SSO architecture, “secure storage” of the cached credentials is absolutely vital. This is certainly the case if the cached credentials are used to give access to business-critical applications or data. In the latter case it is not recommended to use this SSO architecture on portable client devices (such as laptops or PDAs) or on operating system platforms that have a bad security reputation.

SSO based on a secure client-side cache can be implemented without the use of an authentication “infrastructure.” In this case the primary credentials unlocking the cache would be local credentials—“local” meaning defined in the local machine’s security database and only valid for accessing local machine resources. In the context of an authentication infrastructure, the user’s primary credentials are generally not local credentials but domain credentials.

Secure server-side credential caching

Figure 9.8 illustrates a secure server-side credential caching SSO architecture. Contrary to the use of a secure client-side cache, secure server-side credential caching SSO architectures store credentials in a central repository on the server side. Contrary to a credential synchronization-based SSO architecture, the credentials used in a secure server-side credential caching SSO architecture are not necessarily the same for every authentication authority.

Figure 9.8: Authentication in a secure server-side credential caching SSO environment.

In a secure server-side credential caching SSO architecture, the master credential database contains (besides the user’s primary credentials) the mappings between a user’s primary and secondary credentials. That is why the primary authentication authority in this architecture is sometimes referred to as the “authentication gateway.” Another copy of the secondary credentials is kept in the secondary authentication domain databases.

In a secure server-side credential caching SSO setup, a user always first logs on to the primary authentication authority using his or her primary credentials and a predefined authentication protocol. If logon to the primary authentication authority is successful, the user-side SSO software usually provides the user with a list of available applications. When accessing an application that requires a logon to a secondary authentication authority, the user-side SSO software will first communicate with the primary authentication authority to retrieve the appropriate user credentials. These are then forwarded to the user in a secure way. Finally, the user-side SSO software will use the secondary domain credentials to transparently log the user on to the secondary domains.

Because in this architecture the secondary authentication authorities trust the primary authentication authority to store a copy of their credentials in the primary credential database, a trust relationship is required between every secondary and the primary authentication authority.

Server-side caching generally provides better security because the credentials are not stored on the client’s hard disk (also remember the security concerns brought up for client-side caching). The credentials may be temporarily downloaded to the client but will disappear when the client shuts down. Also, access to the server-side credential cache is only allowed after a successful logon to the central authentication authority.

An important challenge in these architectures is how to keep the copies of the credentials in the primary credential database and the ones in the secondary credential databases synchronized. Different products use different approaches to resolve this problem:

• Some products contain password synchronization services.

• Some products rely on the password synchronization services of specific software products (Passgo, Proginet, and so forth) or the password synchronization services that are built into systems management software (BMC Patrol, CA Unicenter, Tivoli).

• Some products do not use any password synchronization and rely on administrators or users (self-administration) to perform the credential updates.

Examples of secure server-side credential caching SSO systems are IBM’s Tivoli Secureway Global Sign-On, Computer Associates eTrust, and Vasco’s SnareWorks Secure SSO (as listed in Table 9.6). SecureWay Global Sign-On’s primary authentication method, for example, is a DCE token- based. After the initial authentication, the SecureWay Client-Side Global Sign-On software retrieves the correct credentials from the primary credential database and provides them transparently to the correct secondary authentication authority.

9.2.3 SSO architectures: Summary

So far we discussed simple SSO solutions and SSO architectures that can span multiple authentication authorities. Table 9.7 gives an overview of the advantages and disadvantages of the SSO architectures discussed so far. A big challenge for today’s SSO products is to extend their scope to cover authentication authorities that are governed by different institutions and companies and to integrate as an authentication provider with a wide range of applications. This topic is discussed in the following sections.