Looks like convergence projects are in the limelight… lately I noticed a lot of interests on enabling the use of common credentials for securely accessing physical and logical resources. Although we find most convergence projects are targeted at the enterprise level but there are serious minds working on using smartcard based PKI credentials for supporting citizen-scale projects (I regret that I cannot discuss the specifics) ! Ofcourse the use of on-card PKI credentials and its on-demand verification with the PKI service provider is in practice for a while now at security sensitive organizations. The DoD CAC, PIV and most smartcard based National ID/eIDs contain PKI certificate credentials and few of them includes Biometric samples of the card holder as well. Using those on-card identity credentials for accessing physical and logical resources becomes critical and also makes sense to fulfil the ultimate purpose of issuing smartcard based credentials… it cannot be overstated.
Couple of weeks ago, I had a chance to present and demonstrate PIV card credentials based logical access control using Sun IDM, OpenSSO Enterprise, WinXP running on Sun Ray environment. The demo was hosted one of the Big5 SI. If you curious to see my preso detailing the pieces of the puzzle…here you go:
Java Card technology has been a passion of mine for so long and I always tried my best to keep updated on Smart card technologies…… not just because of my role at Sun, I did get several opportunities to work closely with citizen-scale Java Card deployments with multiple National ID, eID/ICAO, US DoD/CAC, PIV/FIPS-201 cards and related Identity management projects. It is always been quite adventurous everytime to experience a card issuance architecture and deployment scenario – right from applicant enrollment, demographic data provisioning, Biometrics/PKI credentialing, adjudication/background checks, post-issuance maintenance including card authentication/verification/usage and final retirement/termination. In the early 2000′s, I even had an opportunity to write couple of Java Card applets for a big 5 financial organization using Java Card 2.x and it is still exists on production (No kidding! one of them may be in your wallet). With all those experiences, I did have my own stumbling issues with programming Smartcards, where I pulled my hair-out on understanding those evil ”Application Protocol Data Units” (APDU) based commands and responses. In my opinion, APDUs are quite complex to understand when you jump in unless you read the docs in-and-out beforehand and then test-driving APDUs are even more hard unless you have the luxury of having a debugging environment – seriously, you may not want to experience those pains. Havingsaid, now we can breathe a sigh of relief – I am bit late to experience the newer features of Java Card 3.0 - It has introduced “network-centric” and “Java/J2EE developer” friendly features that radically changed the way we originally designed, developed, deployed, and integrated Smartcard applications. Interestingly, there are very compelling aspects about Java Card 3.0 technology - As I digged with my little experience… here is my observations.
If you are curious to test drive Java Card 3.0 reference implementation especially using its “Connected Edition” to deploy Java Servlet based application to Smart card - Before you begin, make sure you obtain the list of pre-requistes :
and then proceed with the following steps for deploying a “Hello World” Web application – creating Java card applications can’t get easier than this :
Netbeans does all the magic for you – if something not working, no worries ! Like implementing anyother Web application in IDE, it is now easy for you to painlessly debug and redeploy the application – I am sure, you’ll find deploying applications on Java Card is nolonger a mystery.
With Billions+ Java Cards already in use and so much demand for the Smartcard technology, Java Card 3.0 promises beyond citizen IDs and can potentially act as your “Personal Web application server” on your wallet.
Thanks to Anki Nelaturu and Saqib Ahmad who introduced me to Java Card 3 with their JavaOne ’09 sessions. After playing with my first excercise on Java Card 3.0 RI, now I am chasing my friendly Smartcard vendors to loan me couple of Java Card 3.0 cards
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:
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.
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.
OpenSSO 8 supports issuing signed OCSP requests by making use of OCSP signing certificates stored in the Web container’s NSS keystore or HSM.
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.
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.
Last night, I had the opportunity to present at an OWASP event @Hartford, CT. James McGovern, a long-time buddy of mine organized this event at one of the Hartford skyscrappers – What a great view ! I had contributed code artifacts to OWASP projects before, but it was the first time I had a chance to attend an OWASP event. Amazing to see..it was an enthusiastic crowd with a lot of focus on the emerging trends in IT security. I took a small piece of the IT puzzle.. to present a topic on “Multi-factor Authentication” and then a demo showing OpenSSO w. PKI/Biometric authentication. It was a well-organized event and I saw a lot of interests around OpenSSO.
As promised, here is my slides for your reading pleasure. Enjoy.
Sun Rays has been widely popular in Government applications for a while now. With the introduction of HSPD-12/PIV cards, I had multiple requests from my SI friends asking me to verify whether PIV cards work on SunRays for hotdesking and enabling PKI based authentication. As on today, Sun Ray Session Server 4.0 does’nt officially support PIV cards …particularly I meant PIV cards from Obethur and GemAlto. Here is the SunRay-PIV-OberthurCards-CheatSheet and also download the Oberthur Card Profile for SunRays – I prepared this cheatsheet based on my first successful attempt using Oberthur PIV on SunRays to verify that IT WORKS for hotdesking/session mobility and desktop authentication using OpenSC PAM.
For those curious to know about OpenSC support for PAM authentication on Sun Rays – make a note OpenSC.org does support Solaris 10 and Sun Rays that includes a PAM module. Also, here is some useful information about PIV card support in OpenSC.
BTW, Sun Rays already provides support for DoD CAC cards.
Update: The download URL changed to Sun ThinkThin blog.