Grouper has a hierarchical namespace of folder in which to organize Groups, Roles, and Permissions. For large deployments of Grouper the namespace can make the UI overwhelming for users to find the objects they want to manage. Since the namespace is conducive to be organized by delegation privileges and not by application, there should be a way to cross-list Grouper Objects by service.
In Grouper 2.2 the UI should make it possible to filter the registry by a service to make the namespace trivial to navigate which makes the UI easier to use. Users could add certain services to their "favorites" and the UI could remember their recently used services.
Service design
The design for this enhancement is based on the attribute framework. There is an attribute definition type reserved for this, called: service. Originally it was called "domain" but never used, and this has been refactored to "service" in 2.2+, and is automatically migrated on upgrade. A service attribute is assignable to folders, groups, and attribute definitions (which includes permissions). Any user who can create objects in a folder can create a service attribute and attribute name and assign it to their objects.
Creating services
The service attribute definition can be created via GSH or the UI. Here is a GSH example of creating a service:
AttributeDef jiraServiceDef = new AttributeDefSave(grouperSession)
.assignCreateParentStemsIfNotExist(true).assignAttributeDefType(AttributeDefType.service)
.assignName("apps:jira:jiraServiceDefinition").assignToAttributeDef(true)
.assignToGroup(true).assignToStem(true).save();
AttributeDefName jiraService = new AttributeDefNameSave(grouperSession, jiraServiceDef)
.assignCreateParentStemsIfNotExist(true)
.assignName("apps:jira:jiraService").assignDisplayExtension("Central IT production Jira issue tracker").save();
Here are screenshots on the UI of creating a service definition and name:
Assigning service tags
Service tags can be assigned to Groups/Roles/Folders/Attributes/Permissions by GSH, UI, WS, or rule. If you want to have a service attribute which is cascaded to all objects in a folder or subfolders, then you can assign a rule to automatically assign the service tag on object create (note, this rule type did not exists in Grouper 2.1 and before).
Service attribute validation
A Grouper Service attribute definition can not be assigned to objects other than groups/roles, folders, and attribute/permission definitions. It is a marker attribute (i.e. tag), which has no value. It is single assignable, i.e. you cannot assign the attribute more than once to the same object owner.
Services privileges
Services have the same privileges that attributes have: READ, VIEW, ADMIN, UPDATE. Note, the VIEW privilege is more complicated, generally you dont have to worry about assigning this, since if someone cannot VIEW the service, but can manage groups in the service, then they still CAN see the service in the UI/WS. This makes using services a lot easier. If you have a cross listed group among services, you can decouple the groups using groups as members of groups so users involved in other services dont see your service. It is also possible (e.g. if your service has a large population), you could make the service public (VIEWABLE by GrouperEveryEntity).
If someone can READ a service, then they can see which objects the service tag is assigned to. If someone can UPDATE a service, then they can (un)assign the service tag. If someone can ADMIN a service then they can rename, move, delete, view/change privileges etc for the service. You can assign privileges of a service via UI / GSH
GSH/API example of service privileges
//the directory is public
directoryServiceDef.getPrivilegeDelegate().grantPriv(SubjectFinder.findAllSubject(), AttributeDefPrivilege.ATTR_VIEW, false);
UI example of service privileges
Using Grouper services
Services should be exposed by the UI/WS/API. i.e. you should be able to do a GroupFinder filter and restrict the results to a certain service. You should be able to list the services for a user. You could be able to browse the repository and operate comboboxes in the context of a particular service.
Questions
- If you are a member of a group in a service, then should you see it in your service drop down? (yes because it would be too hard to maintain if each user of a service has to be assigned to VIEW the service)
- Can you see groups you are a member of if you cannot READ that group (My Memberships)? I think that is the current functionality
- Can we stop supporting the privilege interfaces except for the default implementation. This will make queries easier and more efficient. If someone wants externalized privileges in Grouper then they will have to sync them into the Group-Field setup we have now.