I get asked this question pretty frequently, considering I am trying to push the SharePoint community to use CardSpace in their SharePoint environments. Well, at least I am trying to get people to consider CardSpace because it will pay an intrinsic role with Windows users (which I care about because I’m a SharePoint architect) when we get to the point of identity metasystem realization.
Well, the first reason you should care about the concept that CardSpace is identity theft is an insanely large and every increasing problem. Just browse the following news article:
Identities are gold! They are worth money!
People ARE making money off identities; we should be looking at all the options we can offer to our SharePoint users so that their sign on experience is fluid, protected, and secure in transit. Our biggest concern is our users, we MUST protect our SharePoint users! What is a collaboration system without users? What is an EIM (Enterprise Information Management) solution that people don’t trust? It is vacant, void of activity, and generally worthless.
Although the .NET framework offered us great mechanisms for doing all sorts of great things in the realm of cutting down on development time for certain business requirements and making things prettier, CardSpace is playing a piece in a solution that will solve things that prevent malicious intent. This is entirely more important than any other functionality! We are looking at targeting things that stop crimes, decrease the amount of lost business revenue due to malicious intent and actions, and taking care of what we care about the most, our SharePoint users! We are attempting to introduce solutions that solve problems that make headline news, that really cost people things that they have worked for in their lives, and protect our organization.
Secondly, you should care because an identity metasystem is not just a neat feature that might happen. It is going to happen IMHO. It is the natural evolution of security; it is how things eventually should be. Although participation by a large amount of parties is required, that involvement will snowball and it will become the parties who do not participate whom belong in the minority. Am I being optimistic? Maybe. I guess it is in the eyes of the beholder.
Furthermore, one thing that people are always interested in doing is promoting the use of SSO (Single-Sign On) to orphaned business applications using SharePoint as an entry point. This is for good purpose. Most people implement SharePoint as their intranet framework because of its inherent document management functionality and collaboration technology. It makes sense to also use it as the POC for all the other foreign application introduction that are available within a corporate environment.
The SharePoint SSO (SpsSsoProvider) provider that is provided OOB is not a real single sign-on provider, in the sense that SharePoint SSO although will be able to store credentials in an encrypted database and pass them to backend business applications (after setting up the relevant service accounts, setting up the relevant Enterprise Application Definitions, etc.), is meant for consumption within objects like WebParts (this is why this authentication type is provided when configuring things like the DataView WebPart within the interface). With CardSpace, we are looking to do something more, although the SharePoint SSO system will stay play an intrinsic role in the overall verification architecture, we are trying to provide an identity solution that will aid the entire corporate system, and will also touch on the realm of allowing our users to securely sign on to websites that provide services like banking, shipments, purchasing, etc. that they might encounter in their typical day job. You know, things that would prove normally profitable for a malicious user to otherwise compromise.
Although there are ways to use SharePoint SSO to sign onto other applications with some custom code (as detailed in this post on the main ARB site), it is not something that is exactly plug and play, there is some development time and architectural considerations to take into this argument before making that decision. The solution that I presented in the referenced above article is more of a hack than an actual enterprise solutions.
< / rant>
Sure, there are going to be bumps along the road. Someone is going to find an exploit in CardSpace, but what product doesn’t have their bugs? I hope Microsoft encourages this, as it will do nothing but enhance the product. In any respect, don’t disregard CardSpace for your SharePoint environment. Embrace it, stay on the cutting edge with advanced objects like these that the .NET framework provides natively to you. Exploit them to the highest potential, as we must consistently ensure that our SharePoint users are as secure as possible!