It’s been so long, I had been involved with multiple Smartcard/PKI projects particularly supporting integration of Sun technologies for use with National eID, US Federal (HSPD-12 / PIV cards) and DoD CAC projects. There is no secret sauce,  but unfortunately I did’nt find time to put together a trustworthy documentation addressing the technical aspects of using Smartcard based PKI credentials for Physical and logical access control solution.  Couple of my friends at SIs (too big to name here) involved with large-scale PIV/CAC deployment repeatedly asked me to draft a cheatsheet for them – finally I had some time to put together an unofficial document that illustrates the pre-requisites, architecture scenarios, configuration and deployment of Smartcard based PKI certificate authentication using Sun OpenSSO Enterprise (Formerly referred to as Sun Java System Access Manager). Here is the main feature of the story:

Smartcard/PKI authentication based SSO

OpenSSO supports the use of PKI certificates from Browser or Smartcard/Token based PKI credentials for authentication and enabling Web Single sign-on (SSO) by determining the revocation status of the certificate through the use of the Online Certificate Status Protocol (OCSP), Certificate Revocation Lists (CRLs) and matching the certificate to a pre-existing certificate entry in LDAP.

Tools of the Trade

1. Sun OpenSSO Enterprise 8 or above
2. Sun GlassFish Enterprise v2.1 or Sun Web Server 7.0 (or above)
   • Must be configured with an NSS Keystore or FIPS-140 conformant Keystore.
   • PKCS#11/HSM based Keystore (optional)
     • Sun Cryptographic Accelerator (SCA-6000) or another HSM.
3. Sun Java System Directory Server EE6 or Sun OpenDS (Bundled with OpenSSO )
   • Repository for user accounts and its corresponding PKI certificate entries (optional).
4. PKI Provider
   • Certificate and Validation Authority
     • Certificate Authority: Cybertrust / Entrust / Microsoft / Verisign
     • OCSP Responders: Tumbleweed / Corestreet OCSP Validator
   • Root CA Certificates and CRLs
     • FBCA SSP CA certificates and CRLs (For PIV/FIPS-201 cards)
     • DoD CA/ECA Root certificates and CRLs (For CAC cards)
     • Govt PKI Root CA certificates and CRLs (For eID cards)
     • OCSP Signing certificate (if required)
5. Smartcard Reader and drivers
6. Smartcard client middleware – Browser Plug-in (PKCS#11 or MS-CAPI)
   • ActivIdentity (ActivClient PKI 6.0 / CAC 6.0 or above)
   • GemAlto (GemSAFE)
   • OpenSC PKCS#11 (OpenSC.org) / MUSCLE
7. Web browser installed with user certificates (Non-Smartcard Scenario)
8. Smartcards provisioned with PKI certificates
   • PIV, CAC, National eID (PKCS#15/Java Cards)

Architectural Strategies

OCSP based Certificate Validation

In this strategy, OpenSSO determines the revocation status of the certificate by issuing a real-time status request and confirms the status by accepting the response from the OCSP responder. OpenSSO 8 supports OCSP based certificate validation by sending OCSP request validation to an OCSP responder URL (Validation authority or CA) specified in the PKI certificate credential (On the Smartcard) – usually available as an Authority Information Access (AIA) extension attribute (RFC3280). If the AIA attribute is not present, OpenSSO will send the OCSP request to designated OCSP responder URL specified in the OpenSSO Certificate Module configuration.

Logical Architecture - OCSP based Validation Strategy

OpenSSO 8 supports issuing signed OCSP requests by making use of OCSP signing certificates stored in the Web container’s NSS keystore or HSM.

Matching PKI certificates in LDAP/CRLs Repository

In this strategy, OpenSSO determines the validity of the PKI certificate by matching the user’s public-key certificate against the user’s LDAP account  stored in a local or remote LDAP repository. OpenSSO uses the X.509 attributes from the certificate (ex. SubjectDN attributes including uid, emailAddress, serialNumber etc) for searching and retrieving the stored user’s certificate from LDAP.  If the user’s certificate matches the retrieved certificate – the authentication is considered successful.  As a pre-requisite, the cardholder’s public-key certificate from the Smartcard must be obtained out and then stored as an userCertificate;binary attribute entry of the user account in LDAP.

Logical Architecture - Matching to LDAP/CRL entries

OpenSSO also supports matching certificates to CRLs in an LDAP repository.  This means OpenSSO uses the Issuer’s DN attribute for searching CRLs in LDAP repository. If the certificate is identified on the CRL; the user authentication is denied. As a pre-requisite, the CRLs must be imported into the LDAP directory. If the user’s certificate includes a CRLDistributionPointsExtension or IssuingDistributionPointExtension   attribute that identifies the location of CRL distribution points where the CRLs are available, OpenSSO certificate module automatically updates it.
In a real-world scenario,  OCSP based certificate validation is overwhelmingly preferred as a best practice over matching certificates using LDAP or CRLs as they require caching them locally, frequency of updates and concerns related to timestamps, authenticity and integrity.

Now, you got the highlights,  if you are ready to dig deeper and test-drive the Configuration and Deployment – Here is the unofficial/unedited cookbook...to make it work. Enjoy and let me know, if you had any suggestions.