Grouper Developers Forum

[Tom Barton <>]

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