9.3 Extending SSO

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.

Table 9.8: Comparing Federation Mechanisms

	Kerberos-Based Federation	PKI-Based Federation	SAML-Based Federation
Authentication technology	Kerberos	PKI	Any
Platform support	Many	Many	Many
Support for entity authentication	Yes	Yes	Yes
Support for data authentication	No	Yes	Under development
Authorization federation support	Yes, but not standardized	Yes, but very few products support it	Yes
Granularity of trust relationship and security policy support	Very Monolithic, no policy support	Support for granular trust and security policies in some products	Under development
Status	Standardized	Standardized, though standardization is not complete	Under development

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.

Table 9.9: Authentication APIs

Authentication API Name	Comments
Generic Security Service API (GSSAPI)	Security services API providing authentication, confidentiality, and integrity services. Defined in RFC 2078.
Security Support Provider Interface (SSPI)	Microsoft’s Authentication API—has been inspired by the GSSAPI.
Pluggable Authentication Modules (PAMs)	Sun’s pluggable authentication architecture.
Java Authentication and Authorization Service (JAAS)	The Java Authentication and Authorization API. Includes a Java implementation of Sun’s PAM. Obviously, the JAAS development is driven by SUN.
Common Data Security Architecture (CDSA)	Security Services API for authentication, confidentiality, and integrity services driven by the Open Group.
Novell Modular Authentication Service (NMAS)	Novell’s pluggable authentication architecture.
XCert Universal Database API (XUDA)	XCert’s API to provide strong certificate-based authentication to applications (XCert is now a part of RSA).

^{[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.