Report on Federated SSO.

© Copyright IBM Corp. 2002, 2004, 2006, 2007. All rights reserved. 149

Chapter 4. Single sign-on technologies

The term single sign-on (SSO) has been bandied about for so long that it has lost much of its initial power. SSO held such power because of its promise to relieve companies of the heavy information technology costs required to maintain security in their information technology enterprise. Despite the best efforts of software vendors, including IBM with its Global Sign-on and Distributed Computing Environment technologies, the goal of each user logging into their computer once and securely accessing all corporate services remained elusive.

When technology failed to live up to consumer expectations, the software vendors decided to lower the expectations by changing the terminology. Single sign-on was dubbed reduced sign-on or simplified sign-on. While this may have reduced consumer expectations, the fact remained that companies were still investing heavily in supporting the user community, which had to keep track of many login names and passwords.

IBM takes a divide and conquer approach to this intractable problem and addressed different classes of SSO with different technologies. The three classes of SSO are:

� Web single sign-on � Desktop single sign-on � Federated single sign-on.

Addressing each of these separately is technically feasible and allows for the realization of true single sign-on.

4

150 Enterprise Security Architecture Using IBM Tivoli Security Solutions

By surveying the different types of SSO and the benefits of each, you will be in a good position to clearly articulate your company's SSO requirements and to identify a solution that can deliver a full range of SSO capabilities.

4.1 SSO delivers multiple business benefits To be an on demand business, a company frequently requires SSO capabilities. By providing users with the ability to log in once across the applications and operating systems that they need to access, a business drives both quantifiable and qualitative benefits, including:

� Reduced administration costs

When users must log in multiple times, they are more likely to forget passwords, which in turn leads to greater Help Desk costs. SSO can significantly reduce these calls and their resulting costs.

� Greater user productivity and experience

SSO allows users to access business systems faster, which enables them to get more done. And users who can sign in once feel better about their transaction experience than users who must log in multiple times with many different IDs and passwords.

� Faster application deployment

When companies deploy a superior SSO and security system that allows application developers to call out to external security services, security no longer has to be coded into each application. As a result, a company can get new applications to market quickly, and can later update application business logic and enhance security much more efficiently.

The benefits of SSO grow as it is applied against an expanded pool of IT environments. As computing models have evolved from distributed client/server systems to Web-based applications—and now even to federated SSO configurations often involving emerging standards such as Security Assertion Markup Language (SAML), Liberty Alliance, and Web Services Federation Language (WS-Federation)—businesses are able to realize increasingly significant value from SSO solutions particular to each model.

4.2 Three classes of single sign-on Let us consider SSO in the context of the evolution of computing models as shown in Figure 4-1 on page 151.

Chapter 4. Single sign-on technologies 151

Figure 4-1 Evolution of computing models

As the computing models evolve from the insular client-server model to the open Web services model, the importance of security increases dramatically. The following table (see Table 4-1) demonstrates how this evolution is impacting user authentication.

Table 4-1 Single sign-on models and their authentication characteristics

The client-server model achieves a certain level of security through the fact that it operates within the corporate network and communicates over a propriety

Model Network exposure

Communication protocol

Authentication

Client-Server Private Proprietary Authenticates user against an application-specific repository. User population contained within the enterprise.

Web Private/Public Standards-based Authenticates user against an application-specific or enterprise repository. User population expands to the Internet.

Federated/ Web Services

Public Standards-based Authenticates user against enterprise repository. Also authenticates users and other network entities (for example, Web services) originating from foreign companies. User population expands to the Internet and other enterprises.

WebClient-Server Federated/ Web Services

We are here, and we are moving this way

152 Enterprise Security Architecture Using IBM Tivoli Security Solutions

protocol. However, being a network-based architecture, the client-server model requires client authentication. In this model, each application tends to have its own user repository. This requires users to keep track of separate accounts for separate applications.

The Web model is just a special case of the client-server model that uses a standard client and communications protocol (HTTP/S). Companies find this model more cost effective, since only one client needs to be deployed to the corporate desktops. Many traditional Web applications were developed (like the client-server model) using their own user repository. In addition to having the same sign-on problem as the client-server model, the Web model compounds the problem by exposing corporate applications directly to the customers through the Internet. This means that companies face a large increase in the number of users needed to be supported. Also, these users are not the traditional corporate users, but rather customers who the company must vet before assigning accounts.

The emergence of the Web as the platform of choice for corporate applications and the exposure of the corporate applications to the end-users created the opportunity for services to be linked between corporations over the Internet. For example, a corporate Web portal may link off to the health benefits provider and the financial services partner. These links lead to an external Web site that requires authentication. Thus, the user is once again faced with additional account data to manage. The federated model requires identity information to be carried securely over the Internet so that users may consume services at various companies.

Each of the three computing models have single sign-on requirements and IBM applies different technologies to meet each of the SSO requirements. These techologies are implemented in the following products:

� Tivoli Access Manager for Enterprise Single Sign-on

Addresses the desktop SSO problem by deploying an agent on the desktop, which intercepts authentication requests by applications and automatically fills in the login data with credentials stored on the local machine.

� Tivoli Access Manager for e-business

Addresses the Web SSO problem by placing a reverse Web proxy in front of the enterprise Web applications. Tivoli Access Manager user accounts are stored in an enterprise directory and users need only authenticate to the Tivoli Access Manager server in order to access all of the existing Web applications configured behind the reverse proxy.

Chapter 4. Single sign-on technologies 153

� Tivoli Federated Identity Manager and Tivoli Federated Identity Manager Business Gateway

Address the federated SSO problem by implementing all of the industry standard federated SSO protocols. These are SAML (all versions), Liberty ID FF (all versions), and WS-Federation. It supports arbitrary identity transformations based on XSLT so that credentials can be converted to a format compatible with the local environment.

Figure 4-2 shows a logical diagram depicting how these products fit together in a solution that addresses all three types of the SSO.

Figure 4-2 IBM Tivoli SSO technologies

The rest of this chapter discusses these SSO technologies in more detail.

4.3 Desktop single sign-on Although few, if any, of the more modern computing solutions being developed today use the client/server model, many existing legacy client/server applications can still benefit from Desktop SSO. While many companies successfully addressed the SSO problem for Web applications, end users still must log into their Windows desktop, log into their mail client, log into corporate chat applications, log into human resources systems, and the list goes on. A complete SSO solution must address desktop SSO.

Tivoli Access Manager for Enterprise Single Sign-On is designed to be an easy-to-deploy solution to automate user authentication to desktop applications. It provides single sign-on by introducing a secure middle layer that authenticates

154 Enterprise Security Architecture Using IBM Tivoli Security Solutions

the user once and then automatically detects and handles subsequent requests for user credentials. Specifically, it uses patented client-side intelligence to respond to requests for user credentials (username/ID, password, and so on) from any Windows, Web, or Mainframe/Host application. Tivoli Access Manager for Enterprise Single Sign-On supports authentication from any authenticator (for example, Passwords, Biometrics, Tokens/Smart Cards) and authentication service (for example, Windows, Entrust PKI, RSA Keon PKI, LDAP directory).

The benefits of desktop SSO are depicted in Figure 4-3.

Figure 4-3 Benefits of desktop SSO

The next section discusses how Web SSO plays a crucial role in an enterprise SSO solution.

4.4 Web single sign-on The predominant computing model today is the Web model, involving HTTP/HTTPS transactions with applications on Web servers, application servers, or both. Many legacy client-server applications are being converted over to the Web model and virtually all new applications are Web-based. With the rapid introduction of new Web applications, each requiring user authentication, companies must adopt a login management strategy or risk overwhelming their user population and consequently reducing security.

Sign on to Desktop

Sign on to Desktop

Windows Domain

Controller

Desktop Login here

Web applications running on

MS IIS

Provides SSO here

But not here

• UNIX • Mainframe • Novell • Linux

TAMeb

Windows Domain

Controller

Desktop Login here

Provides SSO

here

Web applications running on all

targets

Sign on to Desktop

Sign on to Desktop1

2

3 4

1

2

3

Web applications running on:

Chapter 4. Single sign-on technologies 155

Tivoli Access Manager for e-business takes a reverse Web proxy approach to solving this problem. The reverse proxy is called WebSEAL and it intercepts Web traffic destined for the corporate Web applications as shown in Figure 4-4.

Figure 4-4 Tivoli Access Manager for e-business Web SSO solution

Before users can access the desired Web application, they must first authenticate to the WebSEAL reverse proxy. After they are authenticated, WebSEAL checks its policy database to verify whether the user is allowed to access the requested resource. If granted, the user is presented with the originally requested back-end resource without any further authentication.

When a Web application is secured through WebSEAL, it should be configured to allow Web traffic only from the WebSEAL server. With this network security in place, legacy applications may disable authentication and remove the original user accounts from the Web servers. This means that users no longer have to remember the login for that Web application and administrators do not have to manage those accounts anymore.

When all corporate Web applications are brought behind the WebSEAL server, users will only have to remember one login for all corporate Web applications.

To facilitate browser/Web server interactions, Tivoli Access Manager for e-business supports the following:

� Web trust configurations—using IBM WebSphere Application Server SSO capabilities and others

� Basic authentication SSO

156 Enterprise Security Architecture Using IBM Tivoli Security Solutions

� Forms-based SSO

� Lightweight third-party authentication (LTPA) SSO

� Passing user information in the HTTP header

Because customers have used Tivoli Access Manager for e-business and its precursors to solve Web SSO issues since the early 1990s, there have been many additions to its Web SSO capabilities, addressing a wide variety of business needs. Consequently, Tivoli Access Manager for e-business can be used to address desktop SSO, back-end and portal SSO, three-tier SSO, SSO to host application emulators, and federated SSO. Only a robust Web SSO solution addresses all of these areas.

4.4.1 Desktop SSO For companies not using Tivoli Access Manager for Enterprise Single Sign-On, Tivoli Access Manager for e-business can be used to integrate desktop sign-on with Web sign-on. A user logging onto Windows is automatically logged onto Tivoli Access Manager for e-business and consequently has access to all secured Web applications without further need to sign on. This is sometimes called Kerberizing Tivoli Access Manager for e-business because the technology is based on the Kerberos protocol that Microsoft uses in its Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) and Microsoft Windows NT® LAN Manager (NTLM) implementations.

4.4.2 Back-end and portal SSO It is not uncommon for companies to implement a so-called SSO solution for a portal only to find that they still get many password prompts. This is because inferior SSO solutions handle the link between the Web browser and the portal but not those between the portal and its portlets, which connect to other applications that need ID and password combinations. But with Tivoli Access Manager for e-business, user information can be passed to an application server or portal server, and that information can be used to build a credential appropriate to the back-end application environment.

To extend SSO to back-end applications and portals, Tivoli Access Manager for e-business includes the following:

� Java Authentication and Authorization Services (JAAS) standardized support for programmatic security.

� J2EE standardized support for declarative security.

Chapter 4. Single sign-on technologies 157

� A technology preview that enables programmatic and declarative security for .NET applications.

� Special support integrated with the WebSphere Portal credential vault to extend SSO support to the portal's back-end applications.

4.4.3 Three-tier SSO Mainframe applications protected by IBM RACF are widely appreciated for their high degree of security. Many businesses have Web-enabled these applications to extend their value, but not every SSO solution can manage authentication with mainframe applications. Tivoli Access Manager for e-business works in concert with WebSphere software, RACF, and J2EE Connector Architecture (JCA) capabilities to map user information for use in each environment that is involved in a user's request for data as shown in Figure 4-5.

Figure 4-5 Three-tier SSO

Because such transactions involve browsers, middle-tier servers and enterprise servers, they are typically called three-tier transactions.

4.4.4 SSO to host application emulators Another set of applications that have had their value extended by Web enablement are emulation applications running on zSeries, iSeries, and DEC/UNIX. The integration of Tivoli Access Manager for e-business with IBM WebSphere Host Access Transformation Services and IBM WebSphere Host On-Demand enables clients to provide SSO to these emulation applications.

z/OS

CICS app

WebSphere Application Server on distributed platform

JCA

RACF

Application

JAAS Subject

AuthenticateAuthenticateUser

CTG

Access Manager for e-business

LDAP

AuthenticateAuthenticate

• User signs on once • Credential transformed (TAMeb WAS RACF)

CTG = CICS Transaction Gateway

Access Manager for e-business

158 Enterprise Security Architecture Using IBM Tivoli Security Solutions

4.5 Federated single sign-on Many businesses are moving toward federated configurations to cost-effectively introduce partner-hosted capabilities into their customers' Web experiences. These environments typically involve a business that has partner relationships, where the partner is not necessarily using the same software as the business itself. Consequently, it is essential that federated software supports the latest interoperability standards used in SOA-based environments: SAML, Liberty Alliance, and WS-Federation.

Federated single sign-on protocols like SAML define methods for securely transferring a user’s identity between security domains over the Internet. This typically involves a pair of companies who have formed a business relationship in which one company is consuming a service from the other. This transferring of the identity means that a service provider need not manage passwords and the user can access external services without having to authenticate again. This is what is known as federated single sign-on.

The powerful IBM solution for addressing federated SSO is Tivoli Federated Identity Manager, which includes Tivoli Access Manager for e-business. Together, these technologies provide robust management of identities involved in business-to-business SSO transactions. A key aspect of Tivoli Federated Identity Manager is its support of three key federated SSO interoperability standards: SAML, Liberty Alliance, and WS-Federation. This is important because in business-to-business exchanges you cannot always be sure which protocol your partner can support.

For companies, who want to test the waters of federated SSO, but do not want to invest in a full-blown enterprise solution, the Tivoli Federated Identity Manager Business Gateway (see Figure 4-2 on page 153) implements the SAML SSO protocol and provides a push button installation. It can be used by small and large companies alike to get quickly up and running with a business partner.

Customers looking to leverage federated configurations to expand their business with relatively minor investments can now do so with great security, thanks to the combination of Tivoli Federated Identity Manager and Tivoli Access Manager for e-business.

Chapter 4. Single sign-on technologies 159

4.6 Enjoy security management benefits beyond SSO Tivoli Access Manager for e-business not only delivers substantial SSO value, it also provides a number of additional security management benefits, including:

� Authorization for Web applications, enabling uniform application of policies that specify who can and who cannot access sets of resources.

� Reverse proxy, protecting intranet, Web and application servers from Internet access (and, optionally, from intranet access).

� Front-end authentication for applications:

– Out-of-the-box support for multiple authentication mechanisms (including user identities and passwords, certificates and tokens), without requiring modification of back-end applications to support these technologies.

– Switch user capability (where an administrator can take over a user's session), and authentication step-up and forced reauthentication (for accessing highly sensitive target data and applications), essential authentication options for some businesses.

� Audit capabilities, when combined with the clear, unified access-control policy, can be a key enabler of audit readiness and compliance with such regulations as Sarbanes-Oxley. Tivoli Access Manager for e-business is designed to help companies maintain and certify the validity of their records and disclosures of pertinent information.

In addition to its federated SSO capabilities, Tivoli Federated Identity Manager extends the Web services security function of WebSphere and WebSphere Web Services Gateway by:

� Expanding support for security token types, which allows out-of-the-box use of SAML and Liberty tokens.

� Mapping user identities received from another domain to identities understood locally, and then mapping and adding attributes as necessary.

� Authorizing local identities for access to requested Web services, ensuring only legitimate use of the Web services.

4.7 Conclusion In this chapter, we saw that by dividing the SSO problem into three separate classes (desktop, Web, and federated), IBM has been able to provide SSO technologies that successfully address each area.

Tivoli Access Manager for e-business delivers SSO in the area where its need is most prevalent today—the Internet. Additionally, the software works with Tivoli

160 Enterprise Security Architecture Using IBM Tivoli Security Solutions

Federated Identity Manager to address federated and Web services SSO. Finally, Tivoli Access Manager for Enterprise Single Sign-On addresses existing legacy client/server configurations to close the loop on the single sign-on problem.

© Copyright IBM Corp. 2002, 2004, 2006, 2007. All rights reserved. 161

Part 2 Managing access control

In Part 2, we discuss the Tivoli solutions that address the access control domain of the overall security architecture. Access control information, which generally evolves around authentication and authorization mechanisms, is handled mainly by IBM Tivoli Access Manager and its resource managers. Access Manager handles a multitude of integration aspects with all sorts of IT infrastructures and application environments, which are detailed throughout this part of the book.

Part 2

162 Enterprise Security Architecture Using IBM Tivoli Security Solutions