The Authentication of an Identity

I’d like to follow my last post with a discussion of Authentication, a process having a good deal of mystique surrounding it. On one hand, we’d like to have a very easy-to-use and very-strong authentication process. On the other hand, once we’ve “authenticated” we’d like that single authentication to satisfy all future authentication requests, this is called Single Sign-on. To keep the discussion on track, I’ll restate some definitions from the Identity Glossary:

Authentication: the process of establishing the validity of DPI according to policy that expresses the requirements of authenticity.

Authenticated Identity: the result of successful Authentication.

DPI (Decision Point Input): Attribute and/or data that is provided to the Policy Decision Point.

Authenticity is another slippery slope. To establish “absolute assurance of authenticity” we may need to expend “infinite resources.” This is unacceptable, therefore, we compensate by defining our risk – what are the consequences and likelihood of allowing a false authentication through--what is the cost of being wrong. Having evaluated the risk, we settle for stating a policy that, if satisfied, provides an acceptable assurance of authenticity. This is called the Authentication Policy.

Authentication Policy: a stated policy that provides assurance of authenticity within the parameters of the policy.
With an Authentication Policy in place we all agree that satisfying the parameters of the policy will provide us with a statement of authenticity that we are willing to live with. Unfortunately, it is often the case that Authentication Policies are put into force without evaluating them in this light (e.g., using simple UserID and Password to protect highly valuable information).

So, policy is at the heart of the matter. In the case of authentication, there is an Authentication Policy that must be satisfied before we can become “authenticated.” Most of the world hard codes this authentication policy as “If the application can perform an LDAP BIND using the UserID and Password supplied by the user, then change the request state from unauthenticated to authenticated.” The application is configured to use a specific LDAP directory, the application sends the UserID and Password as arguments to the BIND, and if “OK” comes back then the application allows the requests, on that connection, to traverse code paths that do what the user expects.

Thus, if the authentication was performed by a portal, then all of the applications controlled by the portal will suddenly become available; unless, of course, any of the applications are “legacy applications” and are, themselves, configured to authenticate the user by binding to a configured LDAP store. The integration of legacy applications into an integrated framework requiring only one authentication process becomes an exercise in figuring out how to satisfy each of the individual authentication mechanisms in each application.

Some solutions to the problem involve synchronizing all of the directory or database stores (Identity Stores) used by the multitude of applications. Sometimes many applications can use the same Identity Store. Other times, the UserID and Password for each user must be replicated between many Identity Stores. Unfortunately, this only allows the user to use the same UserID and Password on each system. In order to complete the single sign-on effort, the integration framework must save the UserID and Password from the user’s original authentication and “play it back” each time requested.

However, we just introduced several big issues.

First, the user’s UserID and Password are being distributed without the user’s knowledge and inspection.

Second, the UserID and Password are hanging around to be replayed and are more vulnerable to disclosure. (Please note that there are some very good deployments of these types of solutions that, because of the deployment constraints, are very secure and work very well).

Third, if we are replicating the UserID and Password of each user throughout a framework, and some of the directories (or databases) that are a part of the replication are not fully trusted by the user or owner of the user’s account (e.g., the enterprise), then we just put valuable information in the hands of someone we don’t trust. For example, let’s say that one of the systems to be hooked into the single sign-on framework is a book service that allows any of the employees of an enterprise to read any of the on-line books that are provided by the service. This book service is a separate business, so replicating the UserID and Password for each employee to the book service allows them to have valuable information that could allow someone to impersonate a legitimate employee.

Well, to make a very, very, long story short – there are many schemes for solving each twisting turn of the problem. Some are less intrusive than others and some more secure than others, but trade offs are the order of the day. What we wish for is that the end result of the Authentication processes would be something tangible, what the glossary terms an Authenticated Identity in a form that can be shared; an Identity that can be instantiated and exist outside of process boundaries; something that is not a program state change but, rather, a persistent object that can transcend process and environment boundaries.

Authenticated Identity: the result of successful Authentication.

More later . . .