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.
- IDM Resource adapter that supports provisioning/de-provisioning/reconcilliation of user accounts with Biometric enrollment middleware. Alternatively, you would able integrate through Java BioAPI (JNI Wrapper) if the biometric provider support BioAPI.
- IDM access to Biometric enrollment repository database as a managed resource – Configured as a database resource. This resource is enabled with read-only access to the CBEFF information of the biometric enrollment system.
- Extend the user attributes to include a Text/String attribute (bioAttribute) that identifies “Biometric Information”.
- Ensure all user forms of target resources are updated to include a derivation that identifies the bioAttribute.
<Property name=’title’ value=’bioAttribute’/>
- Configure the resource adpaters that requires provisioning of biometric information. Incase, of provisioning of PIV Smart cards you may choose to use the XML Resource Adapter that captures all the demographic data and it can be combined to use the CBEFF information available from the ‘bioAttribute’ data obtained from the database resource.
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.