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

9.3.1 Extending the SSO scope to cover different organizations

One of the driving factors behind extending SSO to cover different organizations are companies’ e-business requirements to easily authenticate users defined in other organizations and transaction requests initiated by business partners. The demand for SSO scope extension is very high in the world of Internet portals. SSO clearly benefits the Internet experience of any portal user from an ease-of-use point of view.

A real SSO solution would accept the external entities’ “foreign” credentials to authenticate to the organization’s authentication authority and would not require a user to reenter his or her credentials. These goals are driving distributed authentication or “federation”-based authentication infrastructures.

In a federated authentication infrastructure, foreign credentials have been validated by a foreign TTP and are also accepted by an organization’s proper authentication authority. The reason why they are accepted is because there is an agreement, trust, or federation between the foreign authentication authority and a company’s proper authentication authority. This setup does not require a copy of the foreign organization’s credential database. Also, in this case, the users only have to take care of a single set of credentials.

As long as the SSO solution behind federated authentication infrastructures supports a mechanism to set up federation or trust relationships between different authentication infrastructures, it can use any of the architectures discussed earlier in this chapter. They can use secure caching, credential synchronization, a token-based architecture, or a PKI-based architecture.

PKIs use the concept of CA hierarchies, cross-certification, bridge CAs, or any other CA-to-CA interoperability solution to set up federations. Kerberos-based infrastructures support federations through cross-realm trust relationships. The following are some examples of commercial authentication infrastructure products and how they support “trust” or “federation”:

• Novell NDS eDirectory (version 8.5 and later) uses the concept of NDS tree federations.

• Microsoft Windows NT and 2000 domains use interdomain trust relationships. In Windows 2000 these trust relationships are built on Kerberos cross-realm authentication.

An interesting new language that will help with the creation of federations in the future is the Security Assertion Markup Language (SAML).^{[2 ]}SAML is a new standard that uses XML to encode authentication and authorization information. Because its basis is XML, SAML is platform- independent. SAML is also authentication method–neutral: For example, it could be used to set up federations between PKI- and Kerberos-based authentication infrastructures. The development of SAML is driven by OASIS (the Organization for the Advancement of Structured Information Standards), a nonprofit, international consortium that creates interoperable industry specifications based on public standards such as XML and SGML.

At the time of writing, the standardization efforts in the federation space were progressing in a very competitive way. Whereas Microsoft, IBM, and Verisign are pushing the Web services security standardization initiative (WS-Security),^[3] most other major software vendors stick to the Liberty Alliance^[4] and SAML as the building blocks for a Web-based SSO infrastructure and federated Web services. Whether Microsoft will ever join the Liberty Alliance remains an open question. In July 2002 Microsoft announced they would support a limited version of the SAML 1.0 specification in their future security product line. At the time of writing Microsoft was building two new softwares that will be rooted on the WS-Security federation protocols: MS Passport version 3.0 (a Web federation solution) and a product codenamed Trustbridge (an inter-organization federation solution).

Table 9.8 compares Kerberos-, PKI-, and SAML-based authentication infrastructure federations.

9.3.2 Extending SSO to cover different applications

Another important authentication infrastructure feature that can help extend the SSO scope to cover different applications is the supported authentication application programming interfaces (APIs). Although this is not always an architect’s primary concern, I found it useful to provide a list of popular authentication APIs. An architect should at least know about them.

Table 9.9 lists a set of well-known authentication APIs. APIs such as GSSAPI, JAAS, and CDSA provide vendor-neutral APIs—they also provide more than just authentication APIs. SSPI, PAM, NMAS, and XUDA are not vendor-neutral and only provide authentication services.

^{[2 ]}See http://www.oasis-open.org/committees/security/.

^[3]See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/html/securitywhitepaper.asp.

^[4]See http://www.projectliberty.org.