Claims-based authentication has been getting a lot of press lately. Cloud-based computing has created new challenges for authentication and authorization that we simply don’t have when we are able to maintain all of our applications and users inside the firewall. Some of these challenges are solved by claims-based authentication systems. As we will see, though, claims-based authorization can also be used to simplify application authorizations on the corporate network as well as provide Web SSO.
There are three basic pieces to the security puzzle. Authenticate—once authenticated, gather attributes from an indemnity store—authorize. The first step is authenticating an entity. I say entity rather than user because in some cases we are authenticating another machine or another system. The most commonly used forms of authentication are simply a matched username-password pair. We can introduce multiple factor authentications using smart cards, biometrics, or public key codes to strengthen the security of the authentication process. There are many different ways to provide authentication—and for our purposes it doesn’t matter what the mechanism is. An entity provides the correct set of credentials to the authentication provider and the authentication provider validates that the credentials match the credentials of that entity in the identity store.
On Your Own
Some applications provide their own authorization. When a user launches such an application they are presented with a dialog box that prompts them for their credentials. Those credentials are validated against an authorized user list maintained by that application and then granted access to the application. Organizations are plagued by legacy applications that force users to sign on using application-specific credentials. The plethora of usernames and passwords users were required to use led to the use of directory services to provide a means of authentication and a central identity store.
A user authenticates against a central identity store and is provided with some form of authenticator that can be passed to applications that will accept that authenticator. This creates a form of single sign-on for applications that understand the protocol of the authenticator. There are many methods that are able to provide these services—various LDAP’s (lightweight directory access protocols), Kerberos, etc. provide mechanisms whereby a client certificate is created. That client certificate is essentially a claim that the user holding that certificate is the entity authenticated against the identity store. So any application that is aware of the particular protocol in use will accept the claim that identifies the user. This was a step forward. Maintaining a centralized data store is not only more efficient but it allows us to provide a common repository of properties or attributes about the entity. Those properties can be queried by an application to provide additional information about the entity. For example, an application may reach out to the identity store and fetch the e-mail address of the entity or determine a role assigned to that user.
Outside the Box
The key point here is that authentication is now being accomplished outside of the application. The client presents a claim via a token or other electronic mechanism asserting the identity of the client. The application can then provide access based upon that identity. The application still needs to maintain a store of authorization information, but it is not required to provide authentication of the client. Central LDAP identity stores are able to provide information about the entity that allows efficiencies for the authorization process. The identity store can group entities based upon similar roles or job functions. That allows the application to check if the user is a member of a certain group rather than verify that the user is included in an extensive list of authorized users in the application’s authorization store. Not exactly rocket science. It is much more efficient to maintain a central store of identities, properties, and security groups and then allow the applications to control authorization using a security or role-based group.
We all know that. Why then do we continue to see so many applications that have endless lists of named users in application security groups, including users no longer with the company or whose role no longer requires access to that application? There is obviously no easy answer to that question or we wouldn’t see this problem everywhere. I suspect it is usually reluctance on the part of IT to “permit” business users access to the directory services system. Often it is simply lethargy. It’s difficult to design and build an identity management system. In my experience the effort is well worth it as the rewards in efficiencies and maintainability far outweigh the initial investment.
Now we begin to compound the problem; not only do we have centralized directory services (that aren’t properly designed or maintained) we also have more than one directory service. Mergers and acquisitions are always challenging for IT and generally the biggest challenge is the introduction of different directory services. Even when the directory services are of the same type it is not always possible or feasible to create a trust between them. In other organizations there are multiple systems simply because so many applications rely on a legacy directory services provider for authentication that it must be maintained even when a new provider is introduced. Typically what I see are organizations using Active Directory (AD) but also maintaining a legacy form of LDAP services simply because it is not practical to rework or refit existing applications to make them AD aware.
So inside the firewall we often see a number of disparate authentication systems. What happens when we start to expose applications outside the firewall? Say we need to provide an extranet where our vendors, suppliers, customers, and partners can share information and applications.
We really don’t want to add external users to our corporate identity store. It certainly is possible, but from a security perspective it’s not acceptable. We are able to maintain control over our internal users’ access to corporate resources. We don’t have that control over external users. The acceptable solution is a separate authentication system. We can use another authentication provider such as forms based, but then we have the problem of making our applications aware of that authentication—not a trivial task. We can also create a separate instance of an identity store we are already using. The problem here is that to use the new system we need to establish a trust between the external and internal systems. I’ve always gone by the maxim “trust everyone, but cut the deck.” And that goes double for my network.
What about the cloud? Cloud implies Web-based applications. That means that if you are an AD shop and your cloud apps are built on the Windows stack then NTLM authentication will more than likely provide Web SSO from the corporate network to the cloud. If you are hitting the cloud from outside the firewall you may need to log in once to establish a session, depending on the machine and browser you are using. The underlying assumption here is that your cloud applications have an identity store that is both trusted and replicated from your corporate directory services.
So what do we do about external users? Assume that our cloud application is meant to function as an extranet. We have the same problems we face above with external users. We don’t want them in our corporate directory services so we have the overhead of supporting a separate identity management system in the cloud.
Claims-based identity management and access control aims to solve all of these issues. At its most basic claims-based systems use a trusted central authority that issues a claim that is then accepted by the application. The claims issuer is able to federate identities from different identity stores, provide authentication against any of those identity stores, and then return a claim.
What is a claim? It is information specific to the entity. That information may include a name, an e-mail address, a security group, a permission. The claim is presented to the application, which can then act upon the information that is presented. The claim is able to present required information to the application. The application does not need to fetch information about the user from the identity store. The only caveat here is that the application must examine the claim to make certain it was issued by a trusted issuing authority.
Get On Board
The analogy used to describe a claim is an airline boarding pass. The airline issues a boarding pass based upon your identity and the flight you have paid for. It doesn’t matter how your identity was authenticated. Once issued that boarding pass is a claim that you have the right to board a certain flight and sit in a certain seat. Likewise, a claim issued by an issuing authority states the holder has certain rights to access an application. I like this analogy but it does break down. I can hand a boarding pass to another person once I have passed through security. A software claim is not allowed to be handed off.
Following the analogy further, we know that a boarding pass can be obtained in a multitude of ways—all based on identifying the flier to whom the pass is issued. Likewise, a claims issuing authority is able to authenticate clients (users or entities) using different authentication schemes. Consider the application in the cloud we were discussing earlier. I access the application using Internet Explorer from my AD-based corporate network. My initial request to the application redirects me to the issuing authority. The redirect passes the requested URL and perhaps other information about the application. The issuer could present me with a login page—but since I am already providing my NTLM authentication in my HTTP request it authenticates my identity against my corporate ID, bypasses the login, and grabs any relevant attributes or properties.
The issuer returns a claims token to the client which is then redirected to the application with the claim in tow. Since the claims issuer has knowledge of the application which the client is going to use it is able to return only the information requested by that application.
Let’s look at another request from an entity contained in a forms-based (database) authentication provider. No session or identity information is being passed, so the user will be presented with a login screen. The claims issuing authority then authenticates the user in the appropriate identity store (in this case the forms-based store) and returns the claim to the client. Two users—two identity stores but a similar claim is presented to the application.
The same scenario works inside the firewall. A claims-based issuing system can consume multiple directory service stores and provide a uniform method of presenting credentials to applications. Claims-based authorization systems that federate different identity management systems provide a way to enable SSO and Web SSO for the enterprise. It is based on an open standard. Microsoft, Oracle, and IBM all provide claims-based identity management infrastructures. Moving to a claims-based authentication/access control system is a major undertaking. Once again the question is simple: Is the effort required justified by the end state? I think it is.
Please address comments, complaints, and suggestions to the author at firstname.lastname@example.org.