This blog discusses how to enable web sites to support access via the Department of Defense Common Access Card (CAC).
What is a CAC?
The Common Access Card is a secure identification card issued to Department of Defense (DOD) personnel and civilian contractors. It is a “Smart Card” in that it has an embedded chip which, along with a secret personal identification number (PIN) code, securely identifies the card holder.
Web sites secured by CAC require the user to swipe the card through a card reader that is attached to their personal computer. The user must also enter the PIN code before they can gain access to the web site. There are many readers available, from many vendors. Some readers are build into laptops, others attache via the USB port.
How do web sites enable CAC authentication?
Fortunately, your web site does not need to know the specifics about the CAC reader nor provide any drivers. All this is taken care of by the end-user when they install their card reader. Your web site only needs to enable X509 certificate-based authentication. X509 certificates are files that prove that the user is who they claim to be. The Common Access Card contains one (or more) of these certificates and presents it to your web site when the user tries to log in.
Let’s talk a little bit about how X509 certificates work so we can understand what is needed to enable web sites. This will be an oversimplification but we just want to know enough to configure our web site. X509 user security needs two files. Each user of your site needs an X509 certificate file. This file is issued to every user that needs one by a certificate authority. In this case that authority is the United States Department of Defense and the file comes to the user embedded on the CAC. The DOD usually requires users to pass a security clearance before issuing the certificate. Your company or organization cannot produce a CAC card or certificate but you can apply to the DOD for a test CAC here.
The second file is the Certificate Authority (CA) file. For CAC, this file comes from the DOD as a plain old file. Actually it’s a set of files and you can get them here. Please note that the DOD adds new Certificate Authority files from time to time so you will need to check this site and refresh periodically. These CA files are installed on your web site and let your web site know that it can trust users with a Common Access Card. It also tells your web site how to get the user’s browser to prompt for the card. Configuring your web site to prompt for a CAC card is specific to the type of web site you are using. Some examples include:
This assumes that your web server is handing the Secure Sockets Layer (SSL) communications. If instead, you are using a load balancer for SSL, consult the load balancer documentation on how to configure the DOD CAs.
How to identify the user?
It is not enough to trust users with Common Access Cards. Millions of people have them and you probably won’t let them all into your site. You need to identify who the user is and decide what to do with them. It may be that you already have a list of authorized users, or you have will allow new users with CACs to auto-register. In both cases, you need to identify the users. This is accomplished with a special 10 digit identifier provided by the the Department of Defense called the Electronic Data Interchange Personal Identifier (EDIPI). The EDIPI is a unique number assigned to each user that stays with them for life, even if they change their name or job title. When a user swipes their CAC, this information is transmitted to your web application in the form of a common name (CN). This common name will appear to your application as a http header variable, cookie, parameter or session variable depending on you implementation. It takes the form: CN=LAST_NAME.FIRST_NAME.MIDDLE_NAME.0123456789. Where the last part is the EDIPI. It may be tempting to user the name portion, but remember that can change (e.g. person gets married).
Once your application extracts the EDIPI, it needs to map it to your local directories user id. This can be done by storing the EDIPI as a regular part of the user record during user creation/registration or you can add a special mapping database.
Your application should then log the user in. You may want to prompt for a password as part of the login. Some DOD clients do not want a password prompt since the user already swiped the card and entered their secret PIN number. In this case you may need to couple your CAC authentication system with single sign-on to provide access into your application.
What about lost/stolen Cards?
The DOD will insist that you not permit users to use lost/stolen/deactivated cards to access your web site. For this purpose, the DOD issues a list of card’s serial numbers that have been revoked. It is available here. This Certificate Revocation List (CRL) must be checked and any certificate found on it should not be accepted. Be aware that this list is very long so your application may want to cache it. Some web servers and load balancer can automatically check this list for you but may not perform adequately due to the length of the list. Another option to frequently checking and refreshing the CRL is to use a new protocol called Online Certificate Status Protocol (OCSP). OCSP allows your site to check an individual certificate to see if it has been revoked without loading and searching the entire list. The address of the OCSP service (responder) is inside those certificate authority files that you previously downloaded. One of the drawbacks of OCSP is that you need the service and connectivity to be up to perform the check. Your web site or load balance may be able to automatically perform OCSP.
Special Considerations for Multiple Web sites
If your web site really consists of multiple sites with multiple server (e.g. accounting.mysite.com and payments.mysite.com). Then each site must be protected from unauthorized access. If you apply the CAC protection to each site, the users will be prompted for to swipe their card and enter their pin code each time they visit a different site. This is secure not user friendly at all. One mechanism to prevent this behavior is to implement CAC security on only one site, let’s call it the portal. Then implement standard single sign-on (e.g. SAML) between the portal and all your other web sites. The user uses the CAC to access the portal and then single-sign on to move seamlessly from the portal to all the other web sites. If the user should try to access one of your other sites first, bypassing the portal, the site will recognize the user is not already signed in and send them back to the portal. This will then cause the portal to prompt for the CAC.
These are some common consideration when providing CAC access to web sites. More development resources can be found on the DOD website.