Update on OpenSSO Authnicip

Last December I posted an article about the OpenSSO's Authnicip extension module. That's the extension to issue Information Cards and Security Tokens to an Identity Selector. I said, the code doesn't compile anymore with the latest build of openinfocard and that I would try to fix it. This was easy enough, so I have done it to the best of my knowledge with no guaranty of course. However, I don't currently have the commit rights for this extension. So, until I figure that out, and for those who can't wait (I doubt it), I can send a tar file upon request.

Don't say OpenSSO, say OpenAM

The news arrived on teletwitter yesterday... A new open-source shop headed by Lasse Andressen- Sun's former CTO for Central & Northern Europe-was born February 1st, 2010 under the name of ForgeRock. ForgeRock is apparently providing a "home" for OpenSSO, OpenESB and Liferay portal projects with the clever intend to ramp up the security integration stack. This is good news, not surprising, and certainly bound to happen following Oracle's announcement to pull "useful" parts (i.e. Fedlet, STS, Entitlement) out of OpenSSO to feed into Oblix without clearly indicating what's next with OpenSSO and its community. ForgeRock says "to be committed to the continued open development of OpenAM (understand OpenSSO) and aims to meet Sun's original product roadmap". That's great! Coupe things puzzle me though... How on Earth can they release OpenSSO Express Build 9 (re-branded OpenAM Build 9) today since the official bits aren't released yet? Or maybe they are, only we don't know it. And second, what engineering resources will they commit to continue the development on the basis of the OpenSSO's source tree? To be followed...

How about the OpenSSO's Information Card Issuer?

How about OpenSSO as an Information Card issuer...? Some of you may have noticed the existence of an extension known as Authnicip (for Information Cards Identity Provider) in the OpenSSO extension's source code repository... Wouldn't be cool to issue Information Cards with OpenSSO? That's what this module is aimed for. As for Authnicrp (for Information Cards Relying Party) the extension relies quite a bit upon the openinfocard project to deal with the lower level protocols of the Identity Metasystem. It turns out that this code hasn't been update for 18 months, and that it doesn't compile with the latest version of openinfocard's library any more. A quick review of the code makes me optimistic that this issue can be fixed relatively easily. I'll keep you posted on my progress with some follow up articles that will explain how to use Authnicip in conjunction with Authnicrp, the Information Cards authentication module.

OpenSSO SSOToken Standard Properties

That's a note for myself that can be useful to others... Thanks to Charles Wesley for the trick.
Also, you can check this link : http://docs.sun.com/app/docs/doc/820-3748/adudc?a=view.
Always look at the documentation before asking silly questions...

• CharSet: ex. "UTF-8"
• UserId: ex "fb"
• FullLoginURL: ex. "/opensso/UI/Login?module=LDAP"
• successURL: ex. "/opensso/console"
• cookieSupport: ex. "true"
• AuthLevel: Ex. "0"
• SessionHandle: ex. "shandle:"
• UserToken: ex. "upgradeuser"
• loginURL: ex. "/opensso/UI/Login"
• IndexType: ex. "module_instance"
• Principals: ex. "uid=foobar,ou=people,dc=red,dc=iplanet,dc=com"
• moduleAuthTime: ex. "LDAP+2009-11-10T20:38:16Z|anon1+2009-11-10T20:37:44Z
• amlbcookie: ex. "01"
• sun.am.UniversalIdentifier: ex. "id=foobar,ou=user,dc=red,dc=iplanet,dc=com"
• Organization: ex. "dc=red,dc=iplanet,dc=com"
• Locale: ex. "en_US"
• HostName: ex. "red.iplanet.com"
• com-iplanet-am-console-location-dn: ex. "dc=red,dc=iplanet,dc=com"
• AuthType: ex. value="LDAP|anon1"
• UserProfile: ex. "Required"
• Host: ex. "red.iplanet.com"
• clientType: ex. "genericHTML"
• AMCtxId: ex. "6747059ed30ea08a01"
• authInstant: ex. "2009-11-10T20:38:16Z"
• Principal: ex. "uid=upgradeuser,ou=people,dc=red,dc=iplanet,dc=com"

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)

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.

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.