This will be the first in a series of three articles that details Windows CardSpace and SharePoint interaction. At the end of this article, you will be able to download two SharePoint WebParts for CardSpace (aptly named in a package as SCWP [SharePoint CardSpace WebParts]), a CardSpace Login WebPart and a CardSpace Create User Wizard WebPart; along with some small, minor configuration changes that once made, you will be able to be immediately use CardSpace in your SharePoint environment. Before you get started, if you are checking CardSpace out, you are going to need the Microsoft .NET Framework 3.0 Redistributable Package, available here.
SharePoint and CardSpace – Part 1 Down The Rabbit Hole
I have been developing with Windows CardSpace for about, oh, two weeks now (mostly just playing around with it and SharePoint). I really do find it pretty solid as a piece of an identity metasystem, it is quite fluid to program against and the object model / API offered is rather intuitive (particularly if you are familiar with identity provider /consumer concepts). Metasystems are such neat concepts because there title literally speaks out the purpose and definition, it is system composed of many parts, which are tailored around the concept of identity. In that, no one protocol or organization will own the metasystem, although Microsoft is certainly leading the way in putting together some of the initial pieces of a metasystem and really attempting to drive excitement for the technology (as CardSpace is an identity selector as you will see shortly). Being one that supports open-source JAD type development, this is a pretty awesome concept that I whole heartily support and plan on jumping on the band-wagon for, since the overall concepts between both are somewhat similar in conceptual architecture. I have been interested in the concept of an identity metasystem for quite some time, mostly getting my feet wet with the concept when Kim Cameron posted a really neat article called The Laws of Identity which is available on MSDN. It looks like an obscene amount of work went into generating the research and content for it. I had to read it twice to get the idea down, but man, he really thought it through and did some great work.
I honestly do believe that once CardSpace catches on a little more, it will become a standard (stated loosely) piece (always remember it’s a piece!) for a lot of people in terms of providing some of the required functionality of an identity metasystem for cross-authentication on collaborative systems like SharePoint, assuming that it does snowball across a vertical. I need to stress this part though, an identity metasystem is only as useful as its cogs, each piece is important, and if people don’t use it and exploit it for its purpose, then it will likely fail. CardSpace is not the end all of the whole concept, it takes a lot of people to contribute to make the identity metasystem concept work! I admit, I am slightly concerned with some of the requirements of CardSpace (OS requirements, SOAP and WS protocol mandates, and HTML OBJECT with DLL support [since it will specify the claims being demanded]) since that might, without the use of emulators, hurt some clients but SharePoint users tend to all use a compliant OS and IE, so I get to be biased and not care. :)
For people that aren’t yet really getting the chance to use such assets like CardSpace out of the Microsoft .NET Framework 3.0 (when developing against CardSpace you will require references to assemblies that only are available in the .NET 3.0 installation such as System.ServiceModel.dll and System.IdentityModel.dll since the latter binary will provide things like the ClaimTypes class), the concept of which it provides is relatively straightforward.
When you are working with SharePoint now, you have chosen an authentication scheme, whether you are using Kerberos KDC that is issuing TGT’s to clients, Forms-Based Authentication using a custom membership provider, etc. The possibilities for this arena are rather vast. Generally, those users have access to a lot of other resources, maybe some internal, some external, whatever.
Each person that is authenticating against your SharePoint instance has a digital identity, which when trying to define what a digital identity is, is rather abstract. The realm of what your digital identity may be can be spread across a fairly large plain. First think about your internal network, and logging into SharePoint. If you are using a directory services controlled account stored in an LDAP store like Active Directory since you are using integrated authentication with SharePoint, your network login is one type of a digital identity. Next, you may have an account at ebay.com since you are an auction freak and enjoy the low quality of goods you generally receive from that site. There you use a separate username and password that you registered for. That’s another digital identity.
For each of these identities, you are going to notice that there are variety of properties that are associated with it. In the realm of SharePoint, think about your user profile properties synching up with AD on some schedule. In this scenario, you may have the Department property being something that is vitally used. But, when you log onto ebay.com, of course they are not going to have that department property associated with your identity, all they care about is your credit card number and whether you would like to save it for quick purchases :).
So, what CardSpace tries to do is take some of this disparate crap and provide some tools that kinda glue it together into a concept called an identity selector which feeds into an identity metasystem. An identity metasystem is a little engine that will provide the methods and functionality that will allow people with all of these assorted digital identities that are based on all sorts of technologies and underpinnings to use CardSpace with their current identity systems, or easily switch to a new one, without having to worry about the whole inter-operability non-sense that would normally come with this decision. In the realm of Kim Cameron’s reason, I think that you can graft a pretty good definition, however abstract, in that an identity metasystem would supply a unifying fabric of digital identity, utilizing existing and future identity systems, providing interoperability between them, and enabling the creation of a consistent and straightforward user interface to them all. CardSpace provides the mechanisms by which a user can hold many types of identity cards [InfoCards] (it would be something like having a bunch of drivers licenses or whatever) stored in a secure location (in the identity selector), which eliminates the needs for users to remember any passwords (eliminating the security concept known as password fatigue). These cards can be leveraged by the metasystem since it introduces a secondary layer between the user and the core identity system, the metasystem understands and provides the inter-operability that allows a user to perform the identity transaction regardless of the base identity technology. Whew, that was a mouthful!
But where the hell do these InfoCards come from? Great question! There are two types of cards, cards that issued from a trusted source, and cards that can be personally generated by the user. Ones that are granted to you from another entity are provided by institutions known as identity providers (STS) [Security Token Service]. These identity providers can be a lot of organizations; you can use your imagination on ones that might be considered legit. On the other hand, users can be their own identity providers, were they create their own cards to be used. So, if you were to register for sharepointsecurity.com (even though there is no registration page :) ), if I had CardSpace enabled (which I don’t) you could instead create a identity card to use instead of trying to remember what you entered for your registration information. Going back to the example above, if I was getting an InfoCard for SharePoint which had integrated authentication enabled, the identity provider would generally be my network administrator. If I was registering for something like ebay, I would probably be using a personal InfoCard that I use to hold that information.
This is all fine and good, but we are always worried about protecting traffic in transit. Its important! So let’s talk a little bit about the flow of CardSpace, and how it would ultimately work with our SharePoint environments from start to finish, with InfoCard enabled. Firstly, what technologies build up CardSpace? Well, because it is an open standard that allows this level of plugging, it uses open XML WS* protocols such as:
(there might be others, I’m not sure)
This means that CardSpace can talk to platforms that similarly implement the same technology.
At 10,000 feet the CardSpace process is pretty simple (a more advanced scenario will be introduced shortly).
1) The SharePoint user has CardSpace on their machine. The SharePoint administrator acting as the identity provider will issue the InfoCard to the user.
2) The SharePoint site that you are running has the CardSpace WebParts on the login.aspx page. In order to login to your SharePoint site, the WebParts require that the username and password. In order to invoke the CardSpace client, as stated before, and OBJECT tag will call a DLL on your SharePoint user machine.
3) Being enabled with InfoCard, you have determined that you are requiring the username and password from the requesting SharePoint user. Once the CardSpace client is invoked on the user machine, they are allowed to select from their available InfoCards from the CardSpace identity selector.
4) The SharePoint user will select their SharePoint CardSpace identity card. Once the InfoCard is selected, the identity provider is queried whom provides a encrypted and signed XML token that passes the required SharePoint login information to the CardSpace WebParts. This portion of the processing is done on the STS (by the identity provider), in this case the STS is internal, however the STS as stated before can be a third party.
5) The user is presented with the requested SharePoint website
Interesting eh? Moving along, lets start to look at it from a more technical standpoint. There are lot of events that happen during the CardSpace process, so I have put together a basic diagram that shows you a little bit of what is going to happen.
There are two important things that before working with CardSpace in SharePoint that you must understand about the CardSpace architecture, and that is the concept of Tokens and Claims. Although they are two separate things, however they are related in that claims are generally housed within tokens, meaning, a token is built upon a series of claims (there is other information that is placed within a token I believe as well). Before you understand tokens, you have to understand Claims. So claims are just pieces of information about the user. This can really be anything, but if you have a Costco Gold Start Member Club (I love their frozen pizza) which could be similar to an identity card, there are two things on the back, your name and your Club number. These are example of claims. They are things is simply just a piece of information that is an assertation of information that wants to be considered valid. So now a token. A token is just a bunch of claims. However, with all security information, there generally is a routine that will verify that the claims that are being sent are from the party that is sending them (I tend to call this evidence or proof, I don’t know what it is actually called). It is important when working with the tokens to take advantage of SAML and object model assets like SamlSecurityToken and SamlSecurityTokenAuthenticator out of the System.IdentityModelSelectors namespace because SAML tokens are extendable and ambiguous in the amount of claims that your security token holds (and if you don’t care, its written as such in the WebParts that are available for download).
Alright, that’s enough about CardSpace for now. In the next post we will look at how the card space flow works and how it fits into the SharePoint authentication scheme. In the last post, we will look at a way that we can use some custom SharePoint WebParts in order to build CardSpcae authentication into our SharePoint site, and then I can get some sleep :)
Vibro.NET (http://blogs.msdn.com/vbertocci/default.aspx) (this guy is brilliant)
.netFX3 main site (http://cardspace.netfx3.com/)