mercredi 14 octobre 2009

Claims-based Identity in OpenSSO (Part III)

In Claims-based Identity in OpenSSO (Part II) I talked about how to use an Information Card to sign-in within OpenSSO using the ignore user profile. In this post, I will show how the Information Card Module (a.k.a the Authnicrp Module ) and OpenSSO's core services can be configured to perform claims-based access control and self-provisioning actions using the dynamic user profile. Simply put, the required or dynamic profiles require that an active user account exist in the OpenSSO's Identity Repository in order to authenticate a subject successfully, and this regardless of whether the subject's Information Card meets the security requirements of the Relying Party (RP) or not.

Self-Provisioning

In addition, the dynamic user profile allows for dynamically provision a new user account (when one doesn't exist or is not associated with an Information Card yet) using the Information Card's claims. As always, it is up to the subject to decide what optional claims can be shared or not with the RP during the sign-up process. This feature is referred to as claims-based self-provisioning, whereby the administrator defines claim to attribute mapping rules as shown in the configuration pane below:



Exact mapping rules may differ from one Identity Repository to another. For example, OpenDS and Active Directory have significant different schemas, thus requiring different attribute names to Information Card claims mapping rules.

In the required or dynamic profiles, the Authnicrp module link a user account with one or more Information Cards (when they are presented for the first time to the module) using the Personal Private Identifier (PPID). This association is performed under two conditions: 1) the user is successfully authenticated with regular username / password credentials or creates a new account, 2) the claims contained in the security token match the security requirements of the Relying Party (RP). Once the binding is completed, any Information Card associated with a user account can be used for sign-in, in lieu of the username / password credentials, until the card expires or is removed from the account.

Claims-based Access Control

The Authnicrp module offers also the possibility to link a self-provisioned user account with an LDAP group or role. This capability is achieved through the creation of a role-resolver-plug-in that is declared in the Authnicrp module's configuration pane as shown in the figure below.


In this case, the ComeOfAge plug-in is invoked by Authnicrp every time an Information Card is presented. The function of the plug-in is to return 'true' whenever the digital identity of the subject matches the criteria of ComeOfAge role or 'false' otherwise. It is up to the developer of the role-resolver-plug-in to implement the matching logic that is appropriate.

An administrator can set up as many role-resolver-plug-ins as necessary in a module instance for the task at hand. Each plug-in is invoked in sequence by the Authnicrp module. Typically, a role-resolver-plug-in implements the RoleCheckPlugin interface that has only one method:

boolean isIdentityMatchingRole(InfocardIdentity identity, String role);

The two short videos below show the onscreen sign-in and sign-up experiences for a user of an Information Card. The browser window on the left points to a website protected by a Security Agent executing different security policies. The browser window on the right points to the OpenSSO's administration console.
  1. To access the protected.jsp resource, the user must be successfully authenticated
  2. To access the comeOfAge.jsp resource, the user must be successfully authenticated and must possess the ComeOfAge role
  3. To access the corporate.jsp resource, the user must be successfully authenticated and must belong to the group 'employee' in Identity Repository for the realm. Self-provisioning is used to dynamically create a new user account.
To display the video, click on the images below (please use full screen mode)


Video 1
Video 2

samedi 10 octobre 2009

Information Card and OpenID Foundations to collabortate on the Open Trust Framework

Mary Rudy of the Information Card Foundation (ICF) announced recently a joint effort with the OpenID Foundation (OIDF) to collaborate on the Open Government Initiative that will enable the US government to accept Information Cards and OpenIDs from industry identity providers.

At Gov 2.0 last month, Vivek Kundra, the Federal CIO, announced a pilot project to have government websites accept industry identity credentials. The Information Card and OpenID foundations issued a joint press release naming ten industry Identity Providers and the National Institutes of Health (NIH) as the first agency to participate in a pilot project.

"As part of enabling this initiative, the ICF has worked closely with the US General Services Administration (GSA) Identity Credential and Access Management (ICAM) committee to define profiles of the Information Card IMI 1.0 standard for use by US government websites for levels of Assurance 1-3. In order for US government websites to know which IdPs conform to the GSA’s profile and privacy policies, the GSA is requiring that IdPs be certified" said Mary Ruddy.

To that aim, the ICF and OIDF are collaborating to create an Open Trust Framework program that can perform this certification. The Open Trust Framework is explained in the joint white paper Open Trust Frameworks for Open Government.

dimanche 4 octobre 2009

Net-ID 2009 is over

Special thanks to Stefanie Schiebenhoefer and team at Computas, as well as Hellmut Broda for the excellent and friendly organization of Net-ID 2009. I wish I had better managed my time to run a more complete demo of the OpenSSO Information Cards module... But for those interested, there is one screencast and more to come on this topic in the "Claims-based Identity in OpenSSO" series. It was particularly impressive to meet and hear in person some of the big names of the Identity Management sphere like Gerry Gebel, from Burton Group, whom I am an assiduous reader.