Chapter 12. Federating Identity

Brigham Young University recognized the need for an identity infrastructure for their web-based initiatives early, and in 1996, they started a project called "Route Y." Over the years, Route Y has come to stand for many things, but from the start, it was about identity. Faculty and students were given unique, University-wide identifiers, and the directory was made available to projects inside and outside of BYU's information technology group. Over the years, as new web-based applications have been added to the campus computer systems, they've all used this common identity directory.

I recently rejoined the Computer Science faculty at Brigham Young University after being away for several years. I immediately noticed that BYU's strategy for building web-based applications had paid off. I sign in once and can do everything from accessing class rolls to turning in grades. I also noticed, however, that the convenience stops at the edge of campus. When I visit BYU's insurance provider or 401K partners, I have to log in again using a separate ID and password.

For all its power, BYU's directory-based identity infrastructure stops at the boundaries of the organization. Even technologies like virtual or metadirectories don't help. Being separate organizations, with different missions, policies, legal requirements, and security domains, BYU and its health insurance provider insist on managing their own directories of employees and customers. Even so, providing a good web experience requires that these identity domains cooperate. That's what federated identity is all about.

We've seen how the proliferation of digital identities creates significant challenges. Users have trouble remembering multiple usernames and passwords. IT organizations are called on to build and operate directories and other identity repositories. One potential solution to this problem is to create a strong central identity infrastructure, but as my story about BYU's directory services points out, centrally managed repositories can't solve the problem of cross-organizational authentication and authorization.

Another approach is to leave the identity resources in their various distributed locations but create a federation that links them for solving identity problems. In Chapter 9, we discussed metadirectories and virtual directories. Federation differs from these two technologies in a crucial way: federation doesn't try to create a single view of the identity infrastructure. That's really just a way of pulling the identity into a central repository, even if it's virtual. Instead, federation defines processes and supporting technology so that disparate identity stores can cooperatively solve identity tasks. Federation means that local identities and their associated data stay in place, but they are linked together through higher-level mechanisms.