Grouper Developers Forum

[Chris Hyzer <>]

The use case I am interested in isn’t listed, maybe you thought it was implicit, but someone goes to the Grouper UI and they want to manage a group which is in a service.  E.g. they want to add someone to be an admin of the PTO application.  But they forgot which group to edit… so if they select in the UI that they want to work in the PTO application, then the UI will filter everything so that it is very easy to know which groups are in that service.

 

I can add that and your list to the wiki and we can see what we can tackle in the 2.2 UI and what can be pushed back

 

Thanks,

Chris

 

From: [mailto:] On Behalf Of Tom Barton
Sent: Tuesday, November 27, 2012 11:32 AM
To:
Subject: Re: [grouper-dev] organizing services in grouper

 

Chris,

Should we specify one or more use cases, to ensure that the implementation meets their needs? Possible ideas:

• 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.

Thanks,
Tom

On 11/27/2012 9:20 AM, Chris Hyzer wrote:

Im working on this task now:

 

https://spaces.internet2.edu/display/Grouper/Organizing+services+in+Grouper

 

I think we should simplify what we had previously discussed.

 

I originally thought you could tag the following objects in grouper with a service tag: groups, roles, folders, permission definitions

 

However, I think there are two reasons to simplify to mandate that you can only assign the service tag to folders.

 

1. The queries will be a lot simpler, quicker, and more reliable (and even possible)

2. It is a best practice to have a root folder for a service

3. Makes it easier (and less chaotic) to setup a service, just assign one attribute to one folder

 

If you have a root folder for a service, and you use groups outside of that folder in that service, then you should probably create that group in the service folder and add the external group as a member (another Grouper best practice).

 

Here are some more thoughts about the direction of this enhancement

 

 - service tag can be assigned to a folder

 

 - any objects in the folder or subfolder are objects of the service

 

 - users can be an admin of a service, or a user of a service (these are virtual roles for UI purposes)

 

 - a service admin has create/stem privileges on a service folder, admin/update on a service group/role/entity, or admin/update on a service attribute/permission, or admin on the service attribute

 

 - a service user is a member of a service group/role (including having permissions)

 

 - note, just because a service admin can admin one object in the service, does not mean they can edit any other objects

 

 - service users do not need to be able to view the service attribute

 

 - a service has attributes: name, display name, description.  Currently those are just in the attribute name object.  Other metadata?  Perhaps, e.g. a URL, a help email or URL, etc.  Might want to have one service name per service attribute definition

 

 - note, for permissions, either the role or the permission definition needs to be in the service folder or subfolder, or both

 

 - in the API / WS you can get:

  - the users of a service (subjects and/or members?)

  - the admins of a service (subjects and/or members?)

  - groups in a service that the subject is a user of

  - groups in a service that the subject is an admin of

  - folders in a service that the subject is a user of

  - folders in a service that the subject is an admin of

  - attribute/permission definitions that the subject is a user of (api only to start)

  - attribute/permission definitions that the subject is an admin of (api only to start) 

  - attribute/permission names in a service that the subject is a user of

  - attribute/permission names in a service that the subject is an admin of

  - memberships of groups/roles of a service that the subject is a user of

  - privileges of groups/roles of a service that the subject is an admin of?

  - permission assignments of groups/roles of a service that the subject is a user of

  - privilege assignments of attributes/permissions of a service that the subject is an admin of?

 

I will be working on this, so let me know if you have thoughts asap :)

 

thanks,

chris