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:
Lately, Biometric identification and authentication technologies gaining unprecedented importance in government organizations across the globe as evidenced in the US by introduction of HSPD-12, HSPD-24 and and other countries complying with ICAO requirements for biometric-enhanced machined readable traveller documents (MRTDs) / ePassports providing support for Facial/Fingerprint identification for travelers passing through airports, security-sensitive locations and ensuring protection against identity thefts.
I did’nt have a chance to read the complete report….all I read was the highlights of the report by Matia Grossi, Frost & Sullivan’s industry analyst…right here. If you are curious about using Biometric technologies for enabling Physical and Logical Access Control…read my earlier posts on Biometric SSO Authentication and Provisioning/De-provisioning Biometrics for Physical and Logical Access Control.
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.
It’s been a while, I had been hearing a lot of talk about unified biometric credentials and using then for convergence of physical and logical access control systems – Like me, you might’ve heard a lot of high-level marketing or analyst’s stuff … so here is some realities from my hands-on experience ! Frankly, there is no magic silver bullet that allows to support provisioning credentials to and from every Biometric middleware providers on the earth (poor standards..they are all proprietary) and it is another uphill task supporting their biometric data provisioning requirements to physical/logical access control systems (PACS and LACS). With Sun Identity Manager, we can support selected biometric middleware integration through resource adapters but the complexity grows greater when we require provisioning of biometric data to a growing list of biometric middleware (AuthN providers, AFIS systems), PACS, LACS and Smart card management systems (CMS). Lately, I had been working on a couple of interesting “Convergence” proof-of-concepts for ISVs aligned with PIV and National eID projects. Although it sounds great, converging the biometric credentials with heterogenous systems is not a trivial job, particularly when provisioning them for smart card issuance and further support post-issuance scenarios of enabling on-card/off-card biometric data for identification and authentication of individuals at heterogenous PACS and LACS systems. After thoroughly looking into the bottom of the issue, realizing and test-driving several usecases, with no option it become critical for us to enable biometric data as a managed attribute in Identity Manager – to support provisioning/de-provisioning of biometric data, changes and its associated reconciliation operations with PACS and LACS. This certainly helped us to exercise control on those discrete PACS/LACS resources that required provisioning of biometric credentials (for authentication/identification) and then ensuring no back-door account entry exists with the biometric middleware that circumvents IDM initiated biometric enrollment processes or rogue smart card issuance requests. This mandated us the Identity manager to support managing the complete provisioning/de-provisioning lifecycle of the user enrolled biometric information (i.e FIngerprints in CBEFF/INCITS-378 templates, Iris Image Interchange format/INCITS-379 templates, Facial images etc).
With Sun Identity Manager, we accomplished this through interfacing with biometric enrollment systems and enabled support provisioning/de-provisioning/reconciliation of biometric information by extending the identity attributes and establishing a managed database resource that stores CBEFF data as a CLOB.
We verified this solution with selected Biometric vendors and Smart card management systems (CMS) to support enabling “Convergence of biometric credentials use with Physical access control systems (PACS) and Logical access control systems (Using biometrics for Web SSO, Federation, Desktop authentication etc) . Sorry folks, I intentionally avoided identifying the vendor names to avoid any conflicts with my friendly ISV peers.
I had been involved with multiple Biometric ISV providers and its integration with Sun technologies particularly OpenSSO, IdM, Sun Rays and Solaris. I also had the opportunity to deploy Biometric solutions to few govt organizations that starts with “D” and “N”. Believe it or not…we have few of them in production.
Now, getting down to the specifics – Putting it all together, in simpler terms you will see the solution would look like this…..
Ofcourse the Desktop can be your PC or Sun Ray or anything that capable of running a browser and allows plugin a Biometric Fingerprint Scanner (USB device). If you look into the ingredients of this solution, you would need the following:
For those curious to know ….and concerned about security of using Biometrics as a network credential…here is my answer to those known security issues.
OpenSSO provides JAAS based authentication framework for plugging in JAAS LoginModules (from authentication providers) and also allows enabling multi-factor authentication through OpenSSO authentication chaining and session upgrade features. Refer to OpenSSO Administrator guide for the finer details.
Few weeks ago, I posted another entry on Match-to-Smartcard PKI and Biometric authentication which is a different solution that makes use of Biometric information (CBEFF) stored on a PIV card. I am still working on the documentation….will keep you posted very soon.
A picture is worth a thousand words. This picture is intended for a friend of mine (a doubting Thomas), who did’nt believe my latest work on enabling a multi-factor authentication based “Web SSO” that uses on-card credentials (PIN + PKI + Biometrics) using PIV card. This solution is currently tested to run Sun OpenSSO Enterprise 8 (running on Glassfish v2), ActivClient (from ActivIdentity) and BioSP (from Aware) and PIV Smartcards on a Sun Ray environment. It works. If you are curious to know this special sauce, please bear with me. I will post the documentation including solution ingredients and other configuration details …very soon.