Authnicrp allows a Relying Party (RP) to accept Information Cards for a user's authentication and authorization to access Web resources protected by a Security Policy Agent. In this version, the processing of the security token is delegated to the OpenInfocard library that has been slightly modified to be embedded in the module. You should check the README file, which contains instructions for building and installing the module in an OpenSSO instance.
A claim is a piece of information about a subject that an Identity Provider asserts about that subject. In the world of claims-based identity, a digital identity is simply represented by a security token that contains one or more claims, each of which carries some piece of information about the user the token identifies, such as name, age, address, employers, and the like. Claims can represent pretty much anything about a user depending on what is required by the RP services. Claims-based identity is a powerful concept that stems from the work of Microsoft on the Identity Metasystem and Information Cards (CardSpace in Microsoft's parlance). For a complete description of the concept, I recommend reading David Campbell's white paper "Introducing Geneva". There is also an Information Card Foundation dedicated to making the Information Card technology successful, which has documentation, best practices and references to contributions for Replying Party and Identity Selector software. Several open-source initiatives are being developed to facilitate the adoption and use of claims-based identity, spanning both the enterprise and the Internet ecosystems.
The Authnicrp Authentication Module at a Glance
In order to understand the Authnicrp authentication module, it is important to understand that it combines the functionalities of three other OpenSSO authentication modules. Namely, the Membership, Anonymous and Data Store standard modules. With Authnicrp, it is possible, using an Information Card, to:
- login as an anonymous user,
- create a user account dynamically based on the mapping of the claims provided in the security token,
- login as a user registered in the data store of OpenSSO's Identity Repository (Generic LDAPv3, Sun DS with OpenSSO schema, Active Directory or JDBC database).
In the User Profile radio button selection you should tick:
- 'Ignored' for anonymous user login
- 'Required' for a registered user login
- 'Dynamic' for the dynamic creation of a user account if the account doesn't already exist
The Authnicrp service configuration pane contains parameters that enable the module to operate according to the authentication profile chosen and the security requirements of the RP.
- Assign a user ID to the anonymous profile
- Assign default roles applied to the dynamic creation profile
- Assign a status to the subject
- Assign an authentication level to the service instance
- The application server's keystore settings used to get the Web site's private key used to process the encrypted security token.
RP Security Requirements
The security requirements stated by the RP are entirely configurable at the realm level. Here, the site administrator can specify the list of required claims and optional claims. Verification elements defined in the claims catalog of the Information Card Foundation can also be specified, including the method employed for verifying the verified claims.
Dynamic Creation of a User Account
The Dynamic profile is used for self-provisioning of new user accounts using the claims of the security token. The configuration pane provides a flexible mechanism by which the administrator can define a claim to Identity Repository attribute mapping. It is also possible to define a set of default roles, or even better, provide a role DN to a role check-in pluggin that will be instantiated by the authentication module for determining whether the digital identity matches the requirements of a given role or not. The class "com.identarian.infocard.opensso.rp.rcheck.ComOfAge", provided in the module, gives an example of how a pluggin can be specified to check the matching programmatically. In the particular case of the ComeOfAge role, the pluggin returns true if any of the age-18-or-over, or coppa-certified-adult claims are provided in the security token.
That's it for today. Claims-based Identity in OpenSSO (Part II) will show how the anonymous profile works, and how to obtain the user's claims from OpenSSO in a Web application.