JanRain at the Burton Interoperability Conference


Today at the Burton Catalyst conference in San Diego, a group of companies are showing interoperability between identity systems and technologies, and JanRain is taking part. In addition to providing one of the leading OpendID identity providers (IDPs), which provides a significant level of interoperability with other identity systems in its own right, JanRain has developed endpoints that connect disparate IDPs, including OpenID IDPs and SAML IDPs, to advanced authentication processes and classifications defined by the National Institute of Standards and Technology (NIST), under a standard known as Special Publication 800-63.

What that means is that a relying party (website consuming identities), using endpoints like this, can ask for authentications for identifiers presented to be classified according to security levels that categorize the strength and nature of the authentication process applied by the identity provider. FIPS-140-2 identified four levels of security to be applied to an authentication:

Level 1: LITTLE or NO confidence in the asserted identity’s validity. Passwords and other mechanisms support validation that the same claimant is accessing the same resource. In practice, this typically means an identifier is protected by a shared secret like a password that is verified by the Identity Provider.

Level 2: SOME confidence in the asserted identity’s validity. Under level 2, authentication can be single factor, but identity proofing is required. An example of this would be the association of a verified cell phone account in the claimant’s name that can be used as an identifying credential.

Level 3: HIGH confidence in the claimant’s asserted validity. Under level 3, two separate but related tokens must be presented attesting to the identity of the claimant and their control over the presented identifier.

Level 4: VERY HIGH confidence in the claimant’s asserted validity. This is the highest practical process for assuring the validity of the credentials and identity presented. This level requires use of cryptographically secure computational resources for the tokens invoked according to NIST FIPS-140-2 Level 3 cryptographic security.

Level 1 covers the basic interactions in most OpenID interactions, and in basic web sign-in processes; a password is provided via secure transport (typically HTTPS) against an identifier, which a relying party or an identity provider verifies as a match. If we are to classify current OpenID transactions happening on the web today, the vast majority would be classified as “Level 1″ transactions. Level 4 is a very demanding, expensive and highly impractical process to implement for typical sign in capabilities on the web, even for commercial transactions, and thus is not of particular interest to this project.

The focus of the interop efforts here has been on integrating the assertions frameworks of disparate IDPs regarding authentication processes that conform to Level 2 and Level 3 standards. This has potentially significant benefits for relying parties in providing a normalized interface for qualifying the strength of the claims presented by its users.

Being able to verify that a user signing in has been authenticated to NIST Level 3, by way of multi-factor token authentication tied to a verified profile can justify a range of actions for the user that would not be available under Level 1 authentication. For example, executing high value financial transactions or making administrative changes in the web site configuration. With a “vocabulary for strong authentication” available, and one that works across a wide range of IDPs and assertions protocols, relying parties can implement features and capabilities into their sites that may have been previously too high risk, or too difficult to manage with “in-house authentication”.

OpenID and PAPE

OpenID supports the semantics of NIST authentication assurance levels via PAPE — OpenID Provider Authentication Policy Extension 1.0. PAPE provides a mechanism for an OpenID authentication to return to the relying party with the strength of the authentication performed by the OpenID IDP declared in terms of NIST authentication levels (1-4).

The interop application being shown at Burton Catalyst this week from JanRain shows PAPE being requested by the relying party site, and various levels of authentication security are returned, depending on what identifier is provided and belonging to which identity provider. For example, providing an OpenID managed by JanRain’s “myOpenID.com”, configured with JanRain’s “Call VerifID” service, which invokes a cell phone call-based authentication process for validating user credentials, results in successful authentications that come back to the relying party specifying a “Level 2″ authentication process was performed, employing a multi-factor token verification process.

One of the objectives of this project was to provide interoperability between disparate authentication protocols, and to demonstrate identity assurance semantics that are normalized across protocols, with the NIST authentication levels being the “common language” that the interoperability server would speak. There are several small but manageable differences between an OpenID rendering of NIST authentication level assurances and a SAML 2 assertion of the same. For example, PAPE does not identify a URI for passwords.

This is not a show-stopper, but an issue that gets quickly identified as an interoperability issue: OpenID + PAPE and SAML otherwise use URIs as the “atoms” for their metadata, and OpenID doesn’t have a “type” for a password credential. Another issue is that SAML 2 doesn’t have an explicit means to bind NIST 800-63 assurance levels to an AuthnContext, something PAPE does for OpenID.

Nevertheless, the simple SAML 2 IDP that accompanies the relying party app at http://interop.janrain.com/ demonstrates a simple way to make SAML assertions with NIST 800-63 levels express in its response to the relying party. In the SAML part of the relying party UI, users must “pre-register” with the private (JanRain) SAML IDP, or enter the email address of one of the other available IDPs, and the output will be expressed to the relying party (and in this case, to the user) in the same, normalized format as the OpenID/PAPE responses.

JanRain’s Interop Server

JanRain has deployed a relying party site that provides tests and UI controls for accessing interoperable access to IDPs that provide authentication assertions for validated identities according to the NIST classifications. The servers at interop.janrain.com provide a simple set of inputs for providing an identifier to be authenticated, and will process those identifiers with the connected IDPs and return the results along with an extended set of reporting information about the authentication.

Thus far, the project has focused on coalescing OpenID and SAML as the assertion protocols at work. But other protocols like Kerberos, WS-Federation and a number of others remain as areas for future interoperability work on advanced authentication for remote credentials in Internet environments. The endpoints at interop.janrain.com show how the classifications can be consolidated for a relying party even though different assertion protocols are being used behind the scenes. We look forward to continuing this effort to widen both IDP support as well as interoperability on NIST authentication level semantics with assertion protocols like Kerberos and WS-Federation.

 

___

Michael Graves

Chief Technology Officer

JanRain, Inc.