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