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.
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.