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.