Conclusions On Claims Based Authentication

Ok, I’m pooped. Technology certainly allows us to move in exciting directions. However, implementing new ideas can be time consuming and expensive. The idea of claims based identity is one that many people are willing to try. Getting accurate information out there to the public though does take time.

There are some that believe this project is one that Microsoft alone is taking on. That isn’t the case at all, and as I mentioned many different entities are on board along with them. The digital world continues to give us new opportunities and those involved believe that this will help all of us to get the most out of it.

The vision for it is there though as is the motivation to see it come to light. There is a strong foundation in place to continue building upon. The use of AD FS v2, CardSpace, and Windows Identity Foundation are all important pieces of this puzzle.


SharePoint Claims Based Authentication – Self Issued Identity Providers

So far all of the examples offered have to do with an identity provider and the STS. As I mentioned though you can have your own self issued identity instead. The user can do this alone and request tokens from an STS that has been installed on a given computer.

The use of a self issued identity provider though will change the set up of several things in place here. The most important one is how much trust the application can have for the claims of a provider. You will have the option with this method of installing an information card that is associated with the identity for the provider too.

With this option the CardSpace will request a SAML token from the identity provider. That token will be sent to the application that is being used. The claims for this token will be set and the user won’t have the ability to add, remove, or change them in any way. They will have basic information included on them.

You may be wondering what good then these tokens will do? They will serve the same benefit as a username and password set up that is common now. Each time you sign up at a new site you will have to create an account with a username and password.

That information gets stored specifically for that site. When you return later on to it, you will have to enter that information again. By doing so though it recognizes you and you don’t have to create a new account each time. Keep in mind this set up only allows it to recognize what you put in there as the same user it doesn’t validate that what you put in is accurate.

The tokens in place do offer plenty of benefits beyond the applications that are in used today. The SAML tokens with a self issued identity will have some complex things that are encrypted into them. This makes it hard for anyone but the original owner of them to use them. The tokens won’t be valid for anyone else so the risk of hacker’s phishing and getting information will be reduced.

A public key can be used to verify a self issued identity provider. This is why they are often referred to as personal cards. If it is issued by an external identity then it is referred to as a managed card. Right now there aren’t any plans to include the self issued provider option with the first beta testing phase for CardSpace.

A change from the earlier CardSpace is that is can now be offered as a separate entity from the .NET Framework. This means it is smaller in size and much faster. There are also optimizations for the applications so that users can find those they use on a regular basis with ease.

In fact, with CardSpace the user can select to have the information stored in it. Then they don’t have to enter it the next time they return to it. Microsoft may decide to allow administers of a business to change policies too for how the identities will be used to access different websites.

Next Section >> Conclusion On Claims Authentication


SharePoint Claims Based Authentication – Windows Identity Foundation

With the Windows Identity Foundation the STS provides tokens that have plenty of information on them. The identity selector allows you to choose the tokens that will be used. This is going to make it easier to accept the tokens and to use them. Developers are going to have an easier time creating applications that are user friendly.

Windows Identity Foundation offers support that is built into the tokens signature verifying process before the claims are removed from it. Each claim is looked at individually which offers developers a constant method across the board for working with information from tokens.

When you are looking at the class properties there are plenty of different things to consider. First there is the claim type which of course will tell you what type of claim it is. Some of them have a username, others have a role, and it can also be many other things. The claim type is determined by strings that are referred to as URI’s.

The value will be what the actual content of the claim has in it. This will often be the users name but it doesn’t have to be. The issuer is going to tell who the identity provider of the claim is as well as who is verifying it to be true.

The Windows Identity Foundation is also designed to offer support for a customized STS. While you won’t necessarily need one, there are times when having one in place is a good idea. You will want to explore all that the Windows Identity Foundation can offer when it comes to the Windows applications. Then you can determine if this process is one you need to be involved with or not.

Next Section >> Self Issued Identity Providers