Chapter 10. Role

Roles are direct typed connections between Identity and Group objects. If you think about a sentence: "John is the Manager of XX Team" what matters is the context. So "John (Identity) is the Manager (RoleType) of XX Team (Group)". The whole sentence describes the Role that John has. This type of information is hard to map with typical Group object as John can be a manager of several different groups and other identities (Marry, Jack, Stan...) can have the same RoleType in context of different groups (XY Team, YY Team). Within each Realm (concept of Realms is described later) we can define several RoleType objects with unique names. Each Role defines a unique combination of Identity, Group and RoleType within Realm.

Roles are managed with RoleManager interface:

RoleManager roleManager = identitySession.getRoleManager();

roleManager.createRoleType("manager");
RoleType adminRT = roleManager.createRoleType("administrator");

Role role1 = roleManager.createRole("manager", annUser.getId(), parisOffice.getId());
roleManager.createRole(adminRT, stefanUser, itDep);

assertTrue(roleManager.hasRole(stefanUser, itDep, adminRT));
                
            

At the SPI level the main difference between plain association is that IdentityObjectRelationship has a IdentityObjectRelationshipName which is simple mapping of a RoleType used in the API

What is important to note about the Role concept is that it is not natural in all kinds of identity stores. Entities represented on attached figures are easy to map in the database. However in store like LDAP typical relationships are represanted in a more plain manner. For example:

                
dn: uid=admin,ou=People,o=test,dc=portal,dc=example,dc=com
objectclass: top
objectclass: inetOrgPerson
objectclass: person
uid: admin
cn: Java Duke
sn: Duke
userPassword: admin
mail: email@email.com

dn: cn=Administrators,ou=Groups,o=test,dc=portal,dc=example,dc=com
objectClass: top
objectClass: groupOfNames
cn: Administrators
description: Portal admin role
member: uid=admin,ou=People,o=test,dc=portal,dc=example,dc=com
                
            

The whole relationship between User "admin" and Group "Administrators" is described by one attribute value ("member"). In such typical LDAP tree shape there is no place to store additional information that are needed to describe Role shown above. Obviously it is possible to shape LDAP tree in a way that will allow such a mapping but in most cases it is not possible to redesign already used LDAP server tree.