Rolemaps

You use a rolemap to specify the principals that take on roles listed in a policy, and to apply the access controls to one or more VOB objects.

The intention is that you can define a small number of policies that determine ‘how' you apply permissions to objects. You then define a number of rolemaps for each policy describing ‘who' takes on the roles in the policy. By separating the ‘how' and the ‘who', you should be able to reuse your policies multiple times and reduce the complexity of your security administration.

For example, your policy could list what things the Developer, Manager, and TeamLead roles can do. Then you define several rolemaps, one for each team, defining the groups or users that take on the Developer, Manager or TeamLead roles. You then use each team's rolemap to protect the objects that are unique to their team (such as a collection of elements).

Each VOB gets a default rolemap, DefaultRolemap, during chflevel or mkvob. The default rolemap is empty. The default rolemap controls all objects in the VOB until new objects are created with a reference to some other rolemap, or until an existing object is reprotected with cleartool protect -chrolemap rolemap-selector object-selector.

You create new rolemaps with cleartool mkrolemap, specifying an input file containing the role mappings of the form Role:Rolename → Group:groupname. (You can also put a user or one of the other special principal kinds on the right hand side of the mapping.) Permission to create rolemaps is controlled by the VOB object's effective ACL.

You modify rolemaps with chrolemap. Permission to modify a rolemap is controlled by the rolemap's rolemap (just like any other controlled object). You can see the effective ACL governing changes to a rolemap with cleartool describe -eacl rolemap:rolemap-name.

Rolemap modifications, either through mkrolemap -replace or chrolemap, will affect containers on disk for all elements that are using the rolemap for ACL information. This may take a long time to execute if a large number of elements are protected by the rolemap. In a replicated environment with preserving replicas, importing an oplog with a rolemap modification will modify the containers on disk, and may take a long time to execute.

Role:Reader --> Group:DOMAIN/developers
Role:Manager --> Group:DOMAIN/mgrs
Role:Developer --> User:DOMAIN/danny
Role:Integrator --> Group:DOMAIN/integs
Role:Developer --> Group:DOMAIN/devs
Role:Administrator --> User:DOMAIN/vobadmin

For information about permissable identities to which roles may be assigned, see Identities for policies and rolemaps.