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.
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. 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). The service attribute definition can be created via GSH or the UI.
- rename attribute def type from domain to service
- service attribute definitions can be created via GSH or the UI (soon to be WS)
confluenceServiceDefCreate.jpg
confluenceServiceCreate.jpg
- create a service (you need the attribute definition and name)
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();
- validate that the service attribute definition is a marker (no value), not multi-assignable to the same object, and can only be assigned to groups, stems, or attribute definitions
- privileges of the service
- if someone can VIEW it, then it will appear in their list of services in the UI or WS
- do this for admins, or users which are viewing/maintaining memberships/permissions, or even for people who can opt-in to a group
- note, 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 that group using groups as members of groups so users involved in other services dont see your service. If you have a huge population (e.g. 100k+) interested in the service, just make it public. If you have a limited population, but you want it to be seen by people who can manage groups, you could set something up with rules or the loader to maintain a list of service users and assign that group of users as viewers of the service.
- 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
- is 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 (soon to be WS)
//the directory is public
directoryServiceDef.getPrivilegeDelegate().grantPriv(SubjectFinder.findAllSubject(), AttributeDefPrivilege.ATTR_VIEW, false);
servicePrivileges.jpg
- a group or folder or attribute definition is considered to be in a service if the service attribute is assigned to it, or if it is in a folder or subfolder that is assigned to the service
- new GroupFinder, StemFinder, AttributeDefFinder, AttributeDefNameFinder (chaining)
attributeDefNameFinder
services
(where can view, update, read, admin, optin, optout)
or
(where group has member or priv on person and group has the attribute)
or
(where attributeDef has priv on person and attributeDef has the attribute)
or
(where folder has priv on person and folder has the attribute)
rules for service tags? takes care of cascading
- add rule for assigning attribute on group/stem/attributeDef in folder (sub or immediate)
QUESTIONS:
- if you are a member of a group in a service, then should you see it in your service drop down? (yes?)
- can you see groups you are a member of if you cannot READ that group (My Memberships)?
TODO:
- how to you do authn and prevent csrf with jsonp? for csrf do we need to have a token that can be used in subsequent requests?
- other WS for permissions
- attribute def save
- attribute def delete
- attribute def find
- action list (including inheritance)
- action (un)assign
- action inheritance (un)assign
- attribute def privilege list
- attribute def privilege (un)assign
- not support the privilege interfaces except for the default implementation