More Fun Than a Barrel of Encrypted Certificates

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:

1. The IIS server requests a certificate from the browser
2. The browser requests a certificate, which is obtained from the CAC card
3. The browser prompts the user for a PIN
4. The browser sends the certificate and PIN to the server
5. The server decrypts the certificate, using the PIN, to get the user’s Subject Value
6. The Subject Value, containing the EDIPI, is used as a username by Sitecore’s httpRequest Pipeline
7. The httpRequest Pipeline authenticates the user within Sitecore

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

Share and Enjoy

•