Recently, Q was tasked with enabling authentication into a government agency’s Sitecore CMS using a U.S. Government issued Common Access Card (CAC). I know it sounds scary; but don’t worry, we’re professionals.
The first question that you may ask is: “what is a CAC card?” It, as with many great things in this world, is a simple entity with a complex purpose; specifically, to identify an individual using two-factor authentication. Similar to your ATM card, you’re able to be identified because you have the two requisite items: you have the card in your possession and you know the PIN associated with the card.
From a technical level, the CAC card contains an encrypted certificate which is able be decrypted, exclusively, using the owner’s PIN. The certificate contains what is called an Electronic Data Interchange Personal Identifier (EDIPI). It is, essentially, an electronic fingerprint—no two are alike.
Web-enabling this process is a simple exercise. Microsoft’s web server, IIS, has a setting which requires a client browser to transmit a certificate along with the request to aid in identifying the user. With this setting enabled, your browser will gather the certificate from your CAC card and prompt you for a PIN. Thus, with a CAC card and all of the required information, we can cook up instant web-enabled electronic fingerprints.
Now that we’ve identified you and have your electronic fingerprint, how do we go about authenticating you within the Sitecore CMS? It all starts within Sitecore’s httpRequest Pipeline. The default httpRequest behavior may be overridden by extending the HttpRequestProcessor class, adding in any code required to process a CAC card. Sitecore must then be configured to use the extended code rather than that of the default HttpRequestProcess. For example, if my extension class were called “CACLogin”, I could use the following configuration patch:
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:x="http://www.sitecore.net/xmlconfig/"> <sitecore> <pipelines> <httpRequestBegin> <processor patch:before= "*[@type='Sitecore.Pipelines.HttpRequest.UserResolver , Sitecore.Kernel']" type="GovAgency.Web.Extensions.Processors.CACLogin , GovAgency.Web" /> </httpRequestBegin> </pipelines> </sitecore> </configuration>
Once configured, the customized code may then extract the Subject Value–which contains the EDIPI–from the client certificate that your browser had sent. The Subject Value is a string, often looking similar to an LDAP DN in reverse; being that it’s a simple string, the Subject Value fits nicely as a username within Sitecore’s user management system. This allows a Sitecore administrator to give access to any user by obtaining their Subject Value. Given a user with a Subject Value of “C=US,O=Government,OU=Contractor,CN=JOHN.DOE.M.1234567890″, a Sitecore administrator would need only add a new user named after that person’s entire Subject Value.
So, to recap at a high-level:
And there you have it, Sitecore CMS authentication using a Common Access Card: “more fun than a barrel of encrypted certificates™”.
Photo Credit: SecureID News
This entry was posted on Tuesday, October 25th, 2011 at 9:59 am and is filed under Design and Development. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.
Comments are closed.