Grouper has a hierarchical namespace of folders 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.
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. 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").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 (TODO, IT SHOULD ONLY BE ASSIGNABLE TO FOLDERS!):
Assigning service tags
Service tags can be assigned to Folders by GSH, UI, WS, or rule. The service tag applies to the folder, all objects in the folder, and subfolders
Service attribute validation
A Grouper Service attribute definition can not be assigned to objects other than folders. 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.
GSH/API example of service privileges
//the directory is public
directoryServiceDef.getPrivilegeDelegate().grantPriv(SubjectFinder.findAllSubject(), AttributeDefPrivilege.ATTR_VIEW, false);
UI example of service privileges (TODO: NOTE ONLY ASSIGNABLE TO FOLDERS!!!)
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.
Metadata
We should have a requirement that there is one service definition per service name, and there could be some built in metadata on the service definition, like who the owner is, a link if people have problems, contact info, description, etc.
Use Cases
- An admin of a service can go to the UI and see which services they are an admin of, and filter the UI by that service
- A "My Services" thing in the v2.2 UI that shows users what services they can access, or perhaps can't access, and that shows users that are also a service admin for one or more services an indication that they have that role and maybe even an ability to exercise it.
- A user wants to know whether they are permitted to access a given service, and if not, a step they might take towards (re)establishing their access to it.
- Service Desk staff able to do the same on behalf of a user.
- Report on all services whose access is managed by a given grouper instance, even if those services aren't all provided by the same IT shop.
- Service names are assigned by multiple people given that permission, and so they must not collide.
- Services could filter the subjects able to be resolved?
- A user of a service can go to the UI and see which services they are a user of, and filter the UI by that 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. if it is then it will continue to work