Claim Base Authorization – Next Generation Identity management
Identity is one of the most popular challenges applications face today. Almost every application has to know who it is talking to and needs to do something about it. Unfortunately we know that identity is poorly handled as Identity theft is one of the world's greatest problems today.
What is identity after all? After decades of working with Identity we finally understand that identity is nothing more that some information that describes an entity. It turns out that entities have multiple identities each relevant on a different context of execution. For instance a person (entity) has one or more professional identities, a personal identity, a social identity etc.
An application that needs to work with an entity's identity needs to know which identity to look for.
The life cycle of identity management in the point of view of the application would look something like this:
- 1. Registration: The entity stores its identity information in some identity management store that will be used by the application later in the life cycle. This store is usually managed by IT professionals.
- 2. Authentication: The entity sends some form of credentials to enable the application to determine who she is.
- 3. The application searches the identity stores for all the identity information it needs.
- 4. The application uses the identity information for authorization, personalization and its business activities.
- 5. The application creates an authenticator and caches the identity information. The authenticator is given to the client for immediate interaction with the application so she will not need to go through authentication every time she interacts with the application. The application might use the authenticator as a key to find the identity information in the cache.
- 6. The user logs out and the authenticator is deleted.
All the above introduces a substantial challenge for the application.
- The identity information is usually sensitive. Credentials are always sensitive. Keeping sensitive information in a persistent store in a secure manner is not easy. A security professional and IT professionals should be consulted before writing the code. To overcome these issues professional infrastructure for identity management like MS Active Directory and IBM Tivoli is often used. Interacting with these will raise more issues as we will see later on. Unfortunately today almost every application requires users to register and supply some identity information. It is trivial to understand that the more your identity information is spread out the less secure it is. Users are not happy to register as they know that somewhere there is an application that does not secure their identity. Users might choose not to make business with an application that requires registration.
- When every application has its own identity management, users turns out to own a growing number of passwords. Unfortunately a human user cannot handle so many passwords so passwords repeat themselves and become weak. The security threat is trivial. Passwords are the weakest form of authentication but usually this is all we have got. Governments had failed to distribute a strong form of authentication i.e. smart passports to their citizens and thus there is no strong authentication for the masses. Some employers and large organization managed to do so and they enjoy a much safer authentication.
- After authentication the application needs to look for the identity information it needs. This information might be stored in several stores managed by the IT pros that usually do not know and care about the application. The application needs to know where and how to look.
In the age of distributed applications, globalization and companies mergers and acquisitions, it is quite common that not just the information is stored in several data stores, it is stored using several different technologies. The application must master those technologies if it wants to find the data.
What happens when the store moves as a result of a company acquisition or simply upgrade?
It turns out that interacting with professional identity management systems is not that easy.
- When finally the application has the information it needs, it is time to figure out the authorization rules and to apply them. These rules might be complex and change quite often so the application has to uses some sort of dynamic decision processor to execute authorization. The rules must be protected and the processor must be efficient as everything goes through authorization. The challenge is not easy.
- The user and the application would be very unhappy if every interaction with the application would require the long process of authentication, so an authenticator is created for the client. The authenticator is like a ticket that proves to the application the entity has already passed authentication. This authenticator must be heavily secured. It is common to find applications that perform a great deal of authentication but their authenticator is weak and can be forged easily. The results are disastrous.
So Identity management is not easy and yet everyone needs to do it. Wouldn't it be great if identity management could be outsourced?
The idea of outsourcing had amazing consequences on the world economy, maybe it could help here as well.
What if the application would identify "someone" it trusts and let him do all the identity management work. The application would get from this "someone" only what it really needs – the identity information. This is exactly what claims based authorization is all about.
In a claim based application a user present her identity to the application as a set of claims. These claims will include all the information about the user like her name, her email, and maybe a list of services she is allowed to use. The idea is that an external identity system is configured to give the application all the information it needs. The information will be packaged as a token built form a collection of claims each representing a certain piece of information. The token will be cryptographically protected to assure that the identity data comes from a trusted source.
Under this model the application will not need to authenticate the user, to store its data, to look for the data and to integrate with other identity stores.
This model might ring a bell because this is exactly what happens whenever we enter a foreign country using a passport. The approval to enter the designating country begins with the fact that this country trusts our home country. Then when we try to enter the country we present a token i.e. passport with some information about us i.e. name, age, etc to the policeman at the gate. He does not authenticate us and he does not need to look for identity information in any identity management store. Everything is written right there. He has all the information he needs. He will check that the token is legitimate and if so based on the initial trust and the information we presented, he will let us in and maybe log the entrance.
The model is simple and has many advantages for the application but one more advantage must be mentioned here and this is the idea of federation. Using a claim based authorization federation is much easier to implement as will be shown later in the article.
Before we dig into the details of the model lets us review its terminology:
Identity : As we stated in the beginning of this article Identity is a set of information that describes an entity.
Claim: A claim is a piece of identity information like a name, email, age, permitted task, etc.
The reason the word "claim" is used and not the traditional "attribute" is the fact that it is not the application that goes to look for the data, but it is the user who presents the claims to the application. The application must first examine the claims with a certain measure of doubt. Only after the application is absolutely sure the claims were originated by a trusted source it can use them. This is exactly what happens when the policeman checks the picture in your passport.
So each claim has as issuer and it will be trusted as much as the issuer is trusted.
Security Token: A security token is a serialized set of claims digitally sighed by the issuing authority.
Issuing authority: An issuing authority is someone who knows how to issue security tokens.
The issuing authority must have enough knowledge about the entity to issue the proper claims for the target application to use. The issuing authority might integrate with some other identity management systems to be able to create the claims.
The issuing authority is the body to which the identity management is being outsourced and as such it must be trusted. When authentication is factored out of the application by relying on claims the application is actually passing the responsibility to the issuing authority to authenticate and manage entities on its behalf.
Security Token Service – STS: The infrastructure that builds signs and issue security tokens according to interoperable standards and protocols. The STS wraps the issuing authority as a service that supplies tokens. The service has quite a bit of technology to implement to create secure and interoperable security tokens.
Relying party – RP: A Relying party is anyone who relies on the issuing authority and uses its claims to give service to some entity. The Relying party is the target application was described in throughout this article.
The basic scenario:
Here is an example of a claim based system in action:
The relying party exposes policy that includes a list of claims that the relying party needs, for example a user name, email address, and role memberships. The policy also tells the client the address of the STS where it should retrieve these claims. After retrieving this policy (1), the client makes a request (2) to the STS, requesting the claims that the relying party asked for. The STS authenticates the user and return a security token containing all the claims the relying party needs. The client then makes its request to the relying party (3), sending the security token along with the request for the service. The relying party will validate the token and use the claims for servicing the client and create the response.
It is vital that the STS will be interoperable as many different kinds of users and relying parties will use its services. Several WS-* standards are used in the above scenario. Policy is retrieved using HTTP GET and the policy itself is structured according to the WS-Policy specification. The STS exposes endpoints that implement the WS-Trust specification, which describes how to request and receive security tokens. Most STSs today issue SAML tokens (Security Assertion Markup Language). SAML is an industry-recognized XML vocabulary that can be used to represent claims in an interoperable way.
Adherence to standards allows to communicate with an STS on an entirely different platform and to achieve single sign-on across many applications, regardless of platforms. If you want to create an STS you can just purchase one instead of building it yourself also it would be interesting to use public STS like the government's STS that would supply an electronic ID exactly as it does supply passports today.
When building a claim based application it easy to implement federation as the application is decoupled from the identity management and stores. All the application needs is a token from trusted source. It does not care how the client got the token.
Federation is useful when an application needs to give service to customers outside of its natural domain. For instance an internal service given to the company's employees is extended and needs to be given to customers outside of the company. The company does not want to manage those external entities in its identity management systems.
The service policy is very simple: Present a token created by the company's STS and you will be served. For the internal employees it is no problem to get such a token as they are managed inside the company and the company's STS "knows them". External customers are not managed inside the company but they are managed somewhere else. If the company's STS trusts an external STS where the external customers are being managed it will agree to exchange a token given to the external customers by their home STS with another token to be used by the application. Now all the foreign customers need to do is to present that token to the service and they will be accepted.
Federation enables to broader the business boundaries traditionally enforced by the identity management infrastructure.
Claims based implementation.
I hope that by this time you are all convinced that claim based authorization infrastructure is what you need. The question is where do I find it?
Microsoft is about to introduce a family of technologies under the name "Geneva". http://msdn.microsoft.com/en-us/security/aa570351.aspx
- 1. Genava Server – A ready to use STS.
- 2. Geneva Framework – A complete object model for building claim based applications and STS.
- 3. CardSpace Genava – An Identity selector to enhance to user usability
- Helps users manage multiple identities for the Web
- Helps users select an appropriate identity for a given relying party
- Protects user privacy
- Gives consumers a non-phishable credentials
IBM has a well known Identity management infrastructure called Tivoli. It is not a surprise that tivoly supports claim based applications: http://www.ibm.com/developerworks/tivoli/library/t-ucitfim2/
Oracle Identity Federation is the oracles implementation of the claims based model
The beauty is that all those technologies interoperate one with each other using WS-* standards.
I would like to end this article with an optimistic view to the future and hope that after years where the identity issue was forgotten with claim based authorization identity will be handled better. Users will feel more secure as applications will handle their identity better and the damage from identity theft will decline.