SharePoint Claims Based Authentication – Claims Creation

An identity is a form of information that is about a specific person or a specific topic. To help with the terminology in this material, we use the term users for identities. Any time that a digital identity is transferred through a network let’s just consider them to be in orthodox bytes. Sets of bytes that have information within them are called tokens, or more formally security tokens. There are often many claims within each token. This is how the information is carried and then later on identified.

It is important to understand that claims can be a representation of anything about a given user. Name of the user, the group that person belongs to, and their age are examples of  claims in the token.

What claims refer to depend on what information is required. Generally this information is used to verify the source that is trying to access it. Without the right information it will remain protected, preventing an unauthorized user from viewing or changing data. The issuer of a token signs each of them when it is created. The digital signature is taken with the token. When it comes to claims based information the STS or Security Token Service will be issuing them.

The application which can be a browser or a client will ask the STS for a token that contains claims for the user using the WS-Trust protocol. There has to be a way to authenticate these requests. Generally this is done by offering a Kerberos ticket, a password that the user enters, or some other element that is in place. The STS looks up the information from a database. After the STS has found what it should it will be able to issue a token and return that information to the entity that requested it.

The STS is owned by the issue of the identity. This is what helps to ensure that security isn’t breached and also ensures that the identity of the provider is real. Of course the application gets to decide if it wants to accept the identity that is given and the claims of the user or not.

It is important to understand that identity providers are offered in an array of formats. You may be using a token that was issued by the STS of your business. For others it may be issued through the Live ID services online that are offered from Microsoft. You can even be your own provider of an identity and we will cover that in more detail later on. Regardless of who the provider is, the ability to get the token and to use it for claims is very significant. Today we are still in the pre-claims aspect of technology. That means any given application gets one form of simple identity information from a user. This can be a log or other identifier. On the other end of things though there is other information attached to that identifier. SharePoint must be able to go to that location and retrieve it from a local directory service, specific database, or whatever provider is configured for the instance. It is critical to understand that with claims-based identity SharePoint will be able to identify what it needs as well as where to get it. Claims are able to relay a great deal of different information.

For example it may have a users name as well as the membership information associated with it. That can be an address, a person’s age, or any other type of descriptive information. A claim will furthermore take a look at the roles of different users before it will make a decision about what can be accessed by them.

The claim can allow more advanced types of information to be required by the user. The claim can also restrict the access that different users have for SharePoint or a given application. For example, some can access all files while others can only use some of them. Some can make purchases while others can’t etc. In order for this to work though the identity must have the token. With claims based identity this will be easier for the developers of the applications to put into motion, allowing developers to stop having to in a sense authentic users. Instead the application has to determine that the token a user has was indeed created by the STS application that is in place. This can be through the use of a password, digital signatures, or anything else that is written into the application.

Next Section >> How are Claims Used?