Identity Management


An increasingly important issue in today's online world is identity management. How do we protect and manage our credentials across a plethora of network applications that have different authentication methods and requirements? If you have ever been locked out of one application because you continuously tried a password that you later realized was your password for a different application, you understand why there is a need for identity management.

Identity management is a problem that confronts security professionals because users tend to circumvent security measures when they become annoyed with the necessity of managing an increasing number of identities across applications. Ease of use has always been a corollary to a good security architecture. The fewer identities the user has to manage, or the easier it is for the user to manage those identities, the more the user will voluntarily adhere to specified security requirements of the applications owning those identities.

Several approaches to identity management exist. Modern Web browsers have rudimentary identity management built in or available as add-ons, with Identity Management as a value-add. Features such as Google's AutoFill on a user's toolbar allows that user to store profile information and manage passwords across multiple applications. By allowing the user to remember and manage one centralized password, this approach reduces the tendency for users to reuse passwords across applications and thereby reduces the risk of one compromised password being used to impersonate the user across many applications.

A common buzz term in the media today is "identity theft." It refers to the theft of a user's credentials in order to impersonate the user, or steal the identity of that user. Popular sites such as eBay, Amazon, and PayPal are common targets for identity thieves. An attacker will send out an e-mail supposedly from a PayPal administrator requesting that the user follow an embedded URL to log in to PayPal and perform some sort of account maintenance. The URL in reality, however, directs the unknowing user to the attacker's PayPal look-alike site where the attacker is then able to capture the user's id and password. The attacker can then use that id and password to log in to PayPal and transfer money from the user to his own account through some laundering scheme. A variant of that attack is one that uses a Web site that sells items, to redirect users to a phony payment site in order to gain the user's id and password to the legitimate payment site.

Single Sign-on (SSO)

The proliferation of Web applications and Web services has created the need for single sign-on (SSO). SSO refers to the ability of a user to log in once to multiple applications that would ordinarily require their own separate logins. Many Web-based applications are constructed as aggregations of finer-grained services. These services can be accessed individually or in a larger context.

Consider a portal, for instance. It allows users to define a set of disparate services that can be accessed via a centralized interface, or portal. Each of these services may require users to authenticate. The portal adds value by enabling SSO across all of its aggregated services, thus eliminating the need for the user to constantly log in.

SSO is considered a requirement in most Web applications today. Whether the application is a traditional browser-based Web application or a true Web service, SSO is absolutely necessary for user-friendliness. One thing is certain: Users hate to log in any more than they have to. And the more frequently they have to log in, the easier to guess they will make their passwords, thus reducing overall security.

SSO through a Portal

SSO dictates that when the user is authenticated for a particular resource, any subsequent access to that resource must be granted without requiring the user to log in again. The most common approach to enabling SSO in a portal is to implement a security token that is presented upon each request throughout the portal. The portal can then use the security token to verify the user's identity across the applications contained in it.

This approach can be used by employing an intercepting agent such as the one defined in the Intercepting Web Agent pattern in Chapter 8 (see Table 8-5). The agent intercepts requests and checks for the token's presence. If the token exists, it is validated, and then the request is allowed through. If the token is invalid or expired, the interceptor will forward the request to the authentication service, which will prompt the user to log in.

Additional information, such as session data, can be stored in the token as well. The portal can use this session information instead of persisting it itself. Implementation of such a token will most often be provided in the form of a secure cookie. If the user disables cookies, the token can be provided as an encrypted value in a hidden field.

The industry has yet to standardize one mechanism for authenticating and authorizing Web service requests. To date, a lot of work has been done by OASIS; the result is the Security Assertion Markup Language (SAML). SAML enables SSO across multiple application servers and allows unrelated applications to make assertions based on trusted third parties. Future development will center on SAML as an alternative to the SSO mechanisms currently used by portals today. For now, third-party products are using a mixture of standard and proprietary approaches to providing SSO.

Cross-Domain SSO

As discussed earlier, traditional Web application SSO is accomplished using cookies. One drawback to this approach is that applications can only set and read cookies from their own domains. Obviously, this prevents straightforward SSO between services in a.com and services in b.com.

Cross-domain SSO (CDSSO) enables SSO across domains and allows users to authenticate in one domain and then use applications in other domains without having to reauthenticate. This is a critical issue today for Web applications that require SSO for their browser-based clients. When Web services become dominant, and SAML is king, this will no longer be an issue. Until then, it is important to understand the problem and the technology that's available to solve it.

CDSSO provides both cost and management savings across the enterprise. These savings are realized when the enterprise uses cross-domain access SSO that doesn't require implementation of homogenous platforms or authentication products. Existing systems can be aggregated without reengineering them to use proprietary mechanisms or even, in the radical case, to share a domain.

How It Works

The various implementations of CDSSO use one basic high-level approach that contains the following major components:

  • Cross-Domain Controller

  • Cross-Domain Single Sign-On Component

The controller is responsible for redirecting a request to the authentication service or the CDSSO component. The CDSSO component is responsible for setting the cookie information for its particular domain. A CDSSO component must be present in every domain that participates in the SSO federation.

Federated SSO

The goal of the enterprise today is to provide seamless employee access to the multitude of internal and externally hosted Web applications that exist in the corporate world. But not all of these applications are managed or maintained by a central authority. That fact, though, should not require employees to know whether an application is internal or external. They should be able to access a service without being required to log in again or having to maintain an additional account. Without a way to federate SSO across services and domains, users will be forced to manage an increasing number of identities and perform more and more logins as they jump from service to service.

The solution to this problem is federation. An SSO Federation provides a means for unifying SSO across a number of services without requiring each service provider to participate directly in the authentication process. Previously, we discussed SSO and CDSSO. We assumed the participating parties were each responsible for authenticating users for each other. The burden upon each service provider increases at a nonlinear rate as the number of services grows and the number of users increases. To alleviate the burden on each service provider to authenticate and authorize participating users, a centralized Identity Provider is used to off-load the work.

The Identity Provider acts as a central authority for authentication and authorization. It authenticates users and then provides users with tokens that can be verified by participating service providers. This method frees service providers from performing authentication and authorization of users. Some users are known by service providers, and others are known only to partner service providers. These users are those who have access to a particular service provider through some temporary partnering agreement. In Figure 2-17, we see how service providers can share identity information through a common identity provider and thus form a federation.

Figure 2-17. Federation of Service Providers with one Identity Provider


Organizations have struggled with the need to aggregate their users into a single repository in order to reduce costs related to the management and complexity of multiple user stores. Applications have also moved to a centralized user repository in order to implement centralized authentication and authorization. Organizations that are consolidating services via a portal have done the same.

Identity Provider federations provide a centralized aggregation of users and the capability of acting as a centralized authentication service. Service providers can delegate authentication and authorization to the Identity Provider. Doing this reduces the burden on a service to provide user management and reduces system complexity.

Cross-Domain Federations

Cross-domain federations are the most complex and most powerful architectures. They allow each Identity Provider to act both as a producer and consumer of identity assertions. Cross-domain federations allow a virtually unlimited topological range of identity propagationnot just across the enterprise, but globally. Someday you may see one central digital warehouse that propagates and verifies your identity information to any serviceanywherethat you want to access. That is the goal of Identity Management.

Figure 2-18 shows how Identity Providers can communicate with each other to create cross-domain federations.

Figure 2-18. Federation of cross-domain Identity Providers


For more information about understanding and implementing identity management, refer to Chapter 7, "Identity Architecture and Its Technologies," and Chapter 12, "Securing the Identity: Design Strategies and Best Practices." We will discuss in those chapters the technologies, patterns, and best practices for enabling Identity Management in enterprise applications.




Core Security Patterns. Best Practices and Strategies for J2EE, Web Services, and Identity Management
Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management
ISBN: 0131463071
EAN: 2147483647
Year: 2005
Pages: 204

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net