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.
- To access the protected.jsp resource, the user must be successfully authenticated
- To access the comeOfAge.jsp resource, the user must be successfully authenticated and must possess the ComeOfAge role
- 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)