SharePoint and SmartCards (CAC Cards)

Have you worked with SharePoint and SmartCards?

I have, as in most military / federal environments you will find that users generally access your SharePoint instance through the use of a CAC (Common Access Card) card. It is the same as any other SmartCard just a little more jazzed up in general with some other information appended on it, nothing tremendously real fancy. Here is an example of a CAC card taken from the army .mil website:

The methodology and purpose between a CAC card and a SmartCard are pretty much the same. They are used so that a user can authenticate to all sort of client certificate aware objects. Within federal spheres though, CAC cards are generally mandatory.

But with SharePoint, SmartCards kind of are annoying. There are some caveats to setting up your environment within SharePoint in regards to maintaining CAC compliance, some which can be handled using inherent IIS settings, others, well, require custom development.

For a lot of people, the implementation of Smartcard security architecture into their SharePoint environment can be a relatively painless one. If you know that all of your users have Active Directory accounts, then you are ready to go, as doing some configuration in IIS will get you most of the way there. The way that this can be done is through a concept called client certificate mapping. Client certificate mapping will basically query for the client certificate off of the Smartcard, and map that to a pre-existing Windows account. In essence, this is not much different than the configuration that you end up with when using Integrated Windows Authentication since you will will still have valid Windows identity to put comparison operators against. If this is your case, the problems that you will run into are inherently bound to IIS. You biggest change is in the IIS metabase, since you will have to manipulate the metabase property that orchestrates SSL client connection negotiations. Meaning, you will tell SharePoint to always negotiate the certificate, which will help resolve client certificate re-negotiation deadlocks. This is done by setting the SSLAlwaysNegoClientCert Metabase Property to true.

While this works, it is not my ideal situation for large environments. I have many users that although have CAC / SmartCard cards that will not exist in the Active Directory tree that I can program against. This presents a large problem for me because my mapping will fail as the comparison operator will consistently pull a false value upon the matching return. I also can’t really imagine the implementing any type of management that would be beneficial in this type of scenario, because I would have to know the users password, which for a typically military unit, can be mammoth. Along those same lines, I would have to actually setup my 1-to-1 mapping scenario. I don’t want to undertake this task in any way share or form. If I went that route, I would be stuck with a management scenario, that would for the sake of a better word, become unmanageable.
Fortunately, through the use of ASP.NET it is possible to inject things in the ASP.NET request stream. This is a good thing. With several authentication methods that are offered in the realm of SharePoint, they are implemented as HTTP modules. For example, if you are using FBA with your SharePoint instance it is going to be using HTTP modules as well.

How an HTTP module works is pretty simple. Firstly, a SharePoint web request will be submitted to IIS. That web request will be mapped to ASP.NET, which will parse the page through the ASP.NET 2.0 engine which in essence is a web request hand-off. This is where the HTTP module comes into effect. Once the web request is handed off to ASP.NET there will be a query into the HTTP modules that exist in the configuration files on the server to determine if any should intercept and possibly manipulate the request. Although only certain modules may take effect, all the HTTP modules that are available are loaded.

If you want to see this in action, you can display the HTTP modules that are currently being instantiated from your SharePoint site through some small code using the Context.ApplicationInstance.Modules collection within a WebPart OnLoad event.

In the next post in this series, I will talk about how we can solve this issue through the construction of a custom HTTP module, and how we can manage our client certificates through database storage as opposed to relying on Windows Accounts. Following, we will see how we can exploit this concept further to implement a custom role provider that will plug into the HTTP module in order to provide a mechanism to redirect users whom don’t subscribe to a role to a default anonymous site, as well as implement strongly named  roles for the SharePoint environment.