Two factor authentication, where a user presents two different kinds of evidence to prove that they are who they say they are, is nothing new. Secure key exchange has been a staple of authentication for e-commerce sites, virtual private networks, and secure data transfer since the inception of the Internet.
In the past decade, security has become a prime concern for the federal government. In 2004, then President George W. Bush enacted Homeland Security Presidential Directive 12 (HSPD-12), which “...mandates a federal standard for secure and reliable forms of identification”1 when securing federal sites. This mandate also requires identity and privacy to be strictly managed under the proposed system.
The National Institute of Standards and Technology responded to Directive HSPD-122 with the Personal Identity Verification (PIV) program, which leverages smart cards to centralize authentication to a single, manageable token that can hold a variety of pertinent information. The smart card provides a relatively open platform for the storage and maintenance of private/public key pairs as well as biometric information such as iris and fingerprint data.
If you’re a development shop with government clientele, you will probably be asked to support the Personal Identity Verification (PIV) standard for the web applications you’re providing to your clients. We devised two methods for authenticating clients in a PIV compliant way on a web application developed on the Drupal Content Management System framework. The first offers a combination of configuring the web server to accept client authentication, while extending the Drupal code base to correlate client certificate authentication to application authentication. The second, geared for clients wishing to conform to the standard, but with less resources to do so, extends a method for hooking into pre-existing Light-weight Directory Access Protocol (LDAP) implementations and managing key exchanges through this network. We implemented the first option because of our client’s specific needs and expectations; However, for more robust security standards we recommend using the second method.
Most government sites utilize a proprietary software called ActivClient to authenticate their users. The ActivClient software works within the operating system to read a smart card input, and prompts the user to provide their Personal Identification Number (PIN) so key exchange can occur and they are able to gain access to the system.
Web applications are forced into the “sandbox” of the browser; i.e. the contained processes that are controlled within the browser’s operation, which is usually limited to transfer protocols. Unless the client authorizes software to be installed and run on their machine, a web application cannot directly touch the operating system. This means that the smart card reader is not directly accessible by web applications, so direct pin authentication by the browser is not possible.
Fortunately, client certificates can be stored within a user’s web browser. In other words, the user can elect to include their authentication certificates in the browser’s sandbox. This certificate is sent along with HTTPS requests to web applications that support them. The certificate can then be used to verify the user’s identity by the server enacting a key exchange; if the client is a trusted entity (determined by the client and server’s keys being signed by the same Certificate Authority), it is allowed to complete the HTTPS request.
We wanted to be able to support a single sign on experience for our users in their CMS, while still providing the security that is required to identify the user under the HSPD-12 directive. Our first solution, which we implemented, was a specific server configuration for Apache and the Drupal Content Management System (CMS).
We set up Apache’s named based virtual hosts so that it served the administrative areas of the Drupal CMS install on one IP address, and the public facing areas of the site on another IP address. All of the traffic that requested the admin IP address was immediately forced to an SSL request and Apache was set up to verify the client certificate provided by the browser.
Figure 1 - Sample Apache Configuration
<VirtualHost ip_address_one:80>
ServerName your_server_name
SSLEngine off
RewriteEngine on
RewriteRule /admin / [R, NE]
RewriteRule /admin/(.*) / [R, NE]
DocumentRoot /my/application/
</Virtual Host>
<VirtualHost ip_address_two:443>
ServerName admin.your_server_name
SSLEngine on
SSLOptions +StdEnvVars
SSLCertificateFile /path/to/your/file
SSLCertificateKeyFile /path/to/your/key/file
SSLCaCertificateFile /path/to/your/ca/file
SSLVerifyClient require
SSLVerifyDepth 2
SSLOptions +StrictRequire
DocumentRoot /my/application/
</Virtual Host>
On the public side, we handled page requests with normal HTTP but forced a redirection to any requests that included an admin URL from this IP address.
We then used a Drupal module that we developed to sign on the user once their certificate had be verified by the server. Once the client certificate handshake was completed, we then utilized the SSL global parameters to perform two checks: 1) was the client certificate accepted by the server? and 2) Does the user’s provided email data in the certificate match the email data in the Drupal database? If both of these checks succeeded, the user was given a session and logged in to the Drupal system.
This only becomes an acceptable solution with a certificate management application like ActivClient. Since this software requires the user to provide their PIN to associate their certificates with their browser, dual factor authentication is preserved. Without a client requiring the PIN to unlock the client certificates and associate them within the browser, the authentication mechanism relies solely on the client certificate.
The solution above relies heavily on the existence of a certificate management client that is installed and maintained within the organization. With federal clients, this is usually the case. ActivRecord is the chosen solution for most clients that are using Common Access Cards for identity verification.
But what if the client does not have access to the same certificate management software, or what if they wish to be PIV compliant, but they do not have the Common Access Card implementation? Or, perhaps the client is just concerned with providing an easy to use dual factor authentication system, without the overhead of implementing a certificate management solution on every workstation within their organization. This solution hooks in to a protocol that most organizations already have in place- the Lightweight Directory Access Protocol (LDAP).
Most organizations have some sort of central directory that serves as a master record for employees; usually this is an LDAP instance. These implementations can host a variety of information; not limited to office phone numbers and email addresses. Therefore, an LDAP instance would be to manage or publish public keys within the organized directory structure itself. This has been proposed by Sun Microsystems as a possible way to leverage the OpenSSO platform for smart card integrated single-sign on experience for one’s user base.3
This implementation does have some overhead associated with it. Key management can be a challenge and requires constant oversight and manual intervention. It assumes that there is an existent LDAP implementation, and it also requires an additional application that manages single sign on, which adds yet another application in the architectural mix.
Aside from these requirements, having a single sign on application that can consume and utilize existing resources, all while preserving the dual factor authentication component, can harden PIV implementations. Until ActivClient or something similar is either open sourced, or made more easily accessible outside of the CAC framework, this sort of solution may be the only available choice for certain organizations.
There is a need for an extensible platform that will offer PIV compliance to sites and organizations that wish to implement the standard. We recognize this gulf and are actively developing a solution for the open source community that will directly address this need. Our goal is to make an extensible Application Programming Interface and server application that is flexible enough to be integrated in a currently functioning LDAP instantiation, or that can be deployed outside of such a framework. Also, PIV compliance methods are not well
documented; this is another need we are trying to fill with the development of this open platform.
PIV authentication standards are not going away. If you provide application development services to government clients, make sure you find out the details within the client organization that can effect your implementation decisions- its your responsibility to lead your clients to compliance.
Footnotes
Written by:
Micah S. Adams (Senior Web Developer),
Carl Kendall (Director of Network Services)
