Over the past few weeks I’ve been working through some use cases and designs for a solution that involves Federated identities. It has got me thinking about the concept of authorization and how we often request more information than we need in order to authorize a transaction or session.
The essential use case is simple. Let’s use the example of a municipal library system web site. In this web site there are advanced sections that the library only wants to offer to residents of the city. An example might be a search function that allows real-time queries against library titles and directs users to the location where these books can be found.
The library’s essential problem here is one of authorization. It needs to know that the user is a citizen of the city, because it only wants the advanced sections of its system to be available to its own citizens. What is interesting is that the library doesn’t really care about the individual citizen’s identity — it is merely concerned with establishing that the online user is authorized to be granted this access.
In a traditional Identity & Access Management (IAM) system, it would make sense to create a user store, populate it (or have users self-populate it) with unique identities, then grant authorizations for each citizen to access the full web site. In this scenario the IAM would need to validate the user’s identity and collect information on them. It might also collect some ‘shared secrets’ so the user could reset their password or to later prove their identity if they called into a help desk. By the end of the registration process, the IAM may have collected six or eight or 12 pieces of information about the user.
But what if the library system had a relationship with another organization that operated its own IAM system? For example, what if the library trusted the Canadian federal government’s ePass system? In this case, the ePass system has significant user information at its disposal, ranging from birth dates to income and tax information. The ePass system also has the user’s address…
The library system could enter into a Federated Identification sharing agreement with the federal government. This agreement would allow the two organizations to share limited information. For example, the federated IAM that resulted from this arrangement could state that the ePass system could only pass the user’s first name and city of residence to the library system.
These two pieces of information (attributes or claims) are more than enough for the library system to do its job. They do not uniquely identify the user. The name would simply be used as a greeting on a screen, and the city of residence would be used for the actual authorization. If the city matched, the system would allow access. If not, it would return the user to the main web site.
The advantages to the library system are:
- no need to purchase or design/build an IAM to meet its authorization needs;
- no need to create, store and revoke user IDs; and
- no need to collect, store, maintain and protect from hackers sensitive user information.
The advantages to the federal government are:
- ability to promote its services as a single sign-on solution beyond its own web sites and business applications;
- to show support municipalities that might be struggling to deliver e-government services; and
- to demonstrate increased return-on-investment in an existing system.
The user also benefits:
- increased convenience;
- increased choice, particularly if the library system was federated with multiple parties and the user could select which system performed the authentication; and, most importantly
- increased privacy protection — one less system would need to hold their personal information.
While this is a fictitious example, it is good illustration of how our governments can work together to increase efficiency, expand services and protect user privacy.
Mike
