Core Security Patterns Weblog

In a typical Single Sign-On (SSO)/Federation scenario using SAML, the Service Provider (SP) initiates the user authentication request using SAML AuthnRequest assertion with an Identity Provider (IDP). The IDP authenticates the principal and returns a SAML AuthnStatement assertion response confirming the user authentication. If the user is successfully authenticated, the SP is required to have the subject’s profile attributes of the authenticated principal for making local authorization decisions. To obtain the subject’s profile attributes (ex. organization, email, role), the SP initiates a SAML AttributeQuery request with the target IDP.  The IDP returns a response SAML AttributeStatement assertion listing the name of the attributes and the associated values.  Using the subject’s profile attributes, the SP can perform authorization operations.

Ofcourse, it looks simple…here is the complexity – Last two weeks I spent on building a Proof-of-Concept that conforms to HSPD-12 Back-end Attribute Exchange specifications and SAMLv2 Attribute Sharing Profile for X.509 Authentication based systems (Both specifications are mandated as part of Federal Identity, Credential and Access Management (ICAM) initiative of Federal CIO Council).  I had been experimenting with an Identity Federation scenario that makes use of Smartcard/PKI credentials – Card Authentication Key (CAK)/X.509 Certificate on a PIV card authenticates a PKI provider (using OCSP) and then using its X.509 credential attributes (Subject DN) for looking up off-card user attributes from an IDP (that acts as an Attribute Authority). The IDP provides the user profile attribute information to the requesting SP. In simpler terms, the SP initiated X.509 authentication directly  via OCSP request/response with a Certificate Validation Authority (VA) of a Certificate Authority (CA). Upon successful authentication, the SP  initiates a SAML AttributeQuery to the IDP (which acts as an Attribute Authority), the SAML AttributeQuery uses the SubjectDN of the authenticated principal from the X.509 certificate and requests the IDP to provide the subject’s user profile attributes.

Using Fedlet for SAML X.509 Authentication based Attribute Sharing

SAML Attribute Exchange for X.509 based Authentication

Fedlet is a lightweight SAMLv2 based Service Provider (SP) implementation (currently part of Sun OpenSSO 8.x and sooner to be available in Oracle Identity Federation) for enabling SAMLv2 based Single Sign-On environment. In simpler terms, Fedlet allows an Identity Provider (IDP) to enable an SP that need not have federation implemented. The SP plugs in the Fedlet to a Java/.NET web application and then ready to initiate SAML v2 based SSO authentication, authorization and attribute exchanges.  A Fedlet installed and configured with a SP can set up to use multiple IDPs where select IDPs can acts as Attribute Authorities. In this case, the Fedlet need to update its configuration with the IDP Metadata configuration (such as entity ID, IDP Meta Alias, Attribute Authority Meta Alias – same as IDP ). In addition, the Fedlets are capable of performing XML signature verification and decryption of responses from the IDP must identify the alias of signing and encryption certificates.

Here is the quick documentation, which I referred  for putting together the solution using Fedlets for SAMLv2 Attribute Sharing for X.509 based authentication scenarios. In case, if you want your Service Provider to use OpenSSO for PIV/CAC based certificate authentication, you may refer to my earlier entry on Smartcard/PKI authentication based SSO (Using OpenSSO). Besides that you should be good to test-drive your excercise. Ofcourse, you can use Fedlets for Microsoft .NET service providers but it was’nt in my scope of work !

In case of SP requiring to fetch multiple user profile attributes you may also choose to use SPML based queries (SPML Lookup/Update/Batch Request/Response) to an Identity Manager (acting as Attribute Authority) – assuming it facilitates an SPML implementation). If you are looking for a solution that requires user profile attributes after a single-user X.509 authentication, then SAML Attribute query should help fetching a single user profile of an authenticated principal !

With increasing incidents of online frauds through username/password compromises and stolen/forged identity credentials - Strong authentication using multi-factor credentials is often considered as a  defensive solution for ensuring high-degree of identity assurance to accessing  Web applications. Adopting multi-factor credentials based authentication has also become a most common security requirement for enabling access control to critical online banking transactions and to safeguard online customer information  (Mandated by FFIEC authentication guidelines). One-time Passwords using Tokens, USB dongles, Java Smartcards/SIM cards, Mobile Phones and other specialized devices has become the most simplest and effective option that can be easily adopted as the “second-factor credential (Something I have)” for strong authentication solution.   Although…and there is a myriad ways to create one-time passwords, the overwhelming developer issue is to make it to work by readily integrating it with existing applications and further enabling them for use in Web SSO and Federation scenarios.

One-time Password (OTP) Authentication using OpenSSO

The One-time password (OTP) is commonly generated on a physical device such as a token and is entered by the user at the time of authentication, once used it cannot be reused which renders it useless to anyone that may have intercepted it during the authentication process.

Sun OpenSSO Enterprise 8.x offers a ready-to-use OTP based authentication module that allows to deliver One-time passwords via SMS (on Mobile phones) and Personal email or combination of both. OpenSSO implements Hashed Message Authentication Code (HMAC) based One-time password (HOTP) algorithm as defined in RFC 4226 - an IETF – OATH (Open Authentication) joint initiative. The HOTP is based on HMAC-SHA-1 algorithm - using an increasing 8-bit counter value and a static symmetric key that is known to the HOTP generator and validation service.  In a typical OpenSSO deployment, the HOTP authentication module is configured to work as part of an authentication chain that includes a first-factor authentication (ex. Username/Password authentication with LDAP, Datastore). This means that atleast one of the existing authentication must be performed successful before commencing HOTP authentication.

Try it yourself

To deploy OTP for Web SSO authentication, all you would need is to have OpenSSO Enterprise 8.x and configured up and running…. and then follow these steps:

1. Login to OpenSSO Administrator console, select the “Access Control” tab, select your default “Realm”, select “Authentication”. Click on “Module Instances” and click on “New” to create a Module instance. Assign a name to the module instance (ex. HOTP) and select “HOTP” as type.
2. Configure the HOTP authentication module properties.  You need to identify the values for Authentication Level, SMTP Server (Access credentials including host name, port, username, password), One-time password validity length (Maximun validity time valid since creation and before OTP expires), One-time Password length (6 or 8 digits), One-time Password Delivery (“SMS” or “Email” or “Both” to receive SMS and Email). 
   •  
     

     Configuring HOTP Authentication Module Properties

      

3. Configure an Authentication Chain that includes HOTP authentication module with any other authentication module (ex. Datastore, LDAP). You may note HOTP authentication cannot act as primary authentication since it HOTP authentication does not identify the user profile, so it must be combined with an authentication module that identifies the calling user identity. To create an authentication chain… goto the OpenSSO administrator console, select “Access Control”, Goto “Authentication Chaining”, click on “New”, assign a name to the authentication chain (ex. Two-factor”) and the choose “HOTP” module instance and select “Required”.
   •  
     

     Configuring the Two-factor authentication chain including HOTP

      

4. Now the OpenSSO One-time Authentication Module is ready for use as par of “Two-factor” authentication chain.
5. Create an User Profile that identifies the user’s “Telephone Number” attribute with the Mobile Phone Number appended with the SMS Gateway domain.
   • For example:
     • AT&T (USA) :  YourPhoneNumber@txt.att.net  (178199931234@txt.att.net)
     • SprintPCS   :   YourPhoneNumber@messaging.sprintpcs.com
     • T-Mobile  :     YourPhoneNumber@tmomail.net
     • Virgin Mobile:  YourPhoneNumber@vmobl.com
     • Verizon: YourPhoneNumber@vtext.com
     • Metro PCS: YourPhoneNumber@MyMetroPcs.com
     • For a complete list of Email to SMS Gateways refer to: http://www.mutube.com/projects/open-email-to-sms/gateway-list/
6.  Test drive the configured One-time Password based SSO authentication, by accessing the URL of the configured “Two-factor” authentication chain as follows:
   • http://openssoserver:port/opensso/UI/Login?service=Two-factor
7. As a result, you will be prompted to perform username/password authentication and then followed by HOTP. To deliver One-Time Password, click “Request OTP Code”, the One-time password will be delivered to your Mobile via SMS and also via email (provided in your User profile).

   • 

     One-time Password based SSO

   • As verified using my Blackberry…the OTP showed up as follows:    

Adopting to One-time Pasword based authentication credentials certainly helps to defend against many illegitimate access using compromised user credentials such as Passwords, PIN and Digital certificates.  Using OpenSSO based OTP authentication is just a no-brainer… try it for yourselves, I am sure you will enjoy !

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:

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.

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.

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:

1. OpenSSO Enterprise 8
2. Glassfish V2 Enterprise (Configured to use NSS for FIPS mode)
3. BiObex Middleware (Biometric enrollment and authentication provider)
4. SecuGen Hamster IV (FIPS-201) or Hamster Plus Fingerprint Scanners.
5. BiometricLoginModule (Currently made available through BiObex).
6. OpenSSO policy agent (based on your target web container) to help enforce authentication on your protected resources.

Here is my quick presentation that digs deeper into the architecture and deployment steps for enabling Biometric SSO using OpenSSO and BiObex.

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.

1. The communication, callbacks and biometric samples acquired from the device (In transit to the JAAS LoginModule and then to Biometric authentication provider)  has been cryptographically protected ensuring a trusted path with both transport and message-level security (as per FIPS-140 requirements). This ensures end-to-end confidentiality and integrity of the messages/communication and thwarts image capture, rogue injection and replay attacks.
2. The user session is verified for proof-of-origin that includes host verification and validation for known IPs and hostnames.
3. The deployment requires authentication chain with username/password or Certificate authentication (ex. Smartcard PKI) modules to ensure Biometric authentication is used as a second or third factor of the authentication.
4. OpenSSO callbacks prompt for random fingerprints as enrolled in BiObex.

Multi-factor Authentication Chain : OpenSSO and BiObex

Biometric SSO allows users to access multiple applications (for example, Java EE or Web portal applications) after doing a single biometric authentication. In this case, the biometric authentication is managed by the identity provider infrastructure (ex. OpenSSO) that provides single sign-on services to support participating applications (protected resources). The identity provider encapsulates and protects access by making use of pluggable authentication modules (including a JAAS LoginModule for the Biometric authentication provider) from authentication providers. Upon authentication, the identity provider issues an SSO token that is trusted by all participating applications. This means the identity provider grants or denies access to the secured application or resource by issuing an SSO token that represents the user’s sign-on and session information. All participating applications trust the SSO token issued by the identity provider and grant the caller request to proceed for further processing based on the policies and privileges.

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.