Grouper Users - Open Discussion List

[Chris Hyzer <>]

> Still the question why the privilegeType/Name route could not be used
> remains...

Not exactly sure what you are asking for here, but let me explain/discuss a 
bit.

The privileges for groups and stems are pluggable.  Meaning is someone 
implements this interface, they should be able to control privileges in a 
different way than a different type of list on a group/stem:

http://viewvc.internet2.edu/viewvc.py/grouper/src/grouper/edu/internet2/middleware/grouper/privs/AccessAdapter.java?revision=1.3&root=I2MI&view=markup

or for stems:

http://viewvc.internet2.edu/viewvc.py/grouper/src/grouper/edu/internet2/middleware/grouper/privs/NamingAdapter.java?revision=1.4&root=I2MI&view=markup

Again, the default implementation in grouper is to use a different type of 
list ("access" or "naming"), and the list name as you say is in 
grouper_fields.  

select type, name from grouper_fields where type in ('access', "naming") 
order by 1,2;

TYPE   NAME
access admins
access optins
access optouts
access readers
access updaters
access viewers
naming creators
naming stemmers

Ideally we would add another suite of methods that work on privileges, just 
like we have for memberships of groups.  The issue is there are higher 
priority tasks we are working on so it wont be available for a while.  But it 
is on our list.

So, it would not be a lot of work if we just allow querying privileges just 
like any other list.  However, there are some issues:

1. In the API it is not allowed.  This is simply a matter of uncommenting 
some code if we want to allow this

        - In this case you would be able to do a hasMember, getMembers, 
getGroups, deleteMember on privileges

2. There is no input for these web service operations for stems

        - So either this is only a group based activity, or we add some 
params to the web service for stemName/stemUuid.  The stem information would 
be returned in params as well.  Again, this is not the cleanest it could be, 
but it does scale to handle permissions of other things without adding tons 
of web service operations... maybe there is some generic getGroups operation 
since we would need to return stems (or potentially other things)

3. How does the web service behave?  If the web service just operates on the 
lists, it is easiest.  However, if an institution switches to non-default 
permissions, then it wont work.  If the web service uses the privilege 
management interface, then it should be fine, it is just a bit awkward that a 
call to read the members of the "admins" list would not be reading a list at 
all, but would be doing whatever the privilege interface specified.

So.... I think we have three options:

a. Wait for the privilege web services.  In the meantime people can use GSH 
or the API

b. Implement the quick and dirty reading/writing to lists

c. [compromise] Use the current web service operations to manage privileges 
and if you read or write to a list, it actually uses the privilege interfaces 
which may or may not actually read or write to that list, but it will do the 
right thing...


Thinking more about it, it seems like people need this functionality sooner 
than later, so maybe we should consider option C.

Does this make sense?  Do people have thoughts about what they want?

Thanks!
Chris




> -----Original Message-----
> From: Martin van Es 
> [mailto:]
> Sent: Wednesday, March 04, 2009 3:46 AM
> To: Grouper Users Mailing List
> Subject: Re: [grouper-users] finding privileges on groups via WS
> interface
> 
> Hi,
> 
> I needed the exact functionality described a couple of days ago. The
> example
> is mostly clear but is there any documentation on the mapping of group
> privileges (types/names) to fieldName/Value? It's like having 2
> interfaces for
> the same question, why not stick to the privilegeType/Name version?
> Also, I was unable to find (javadoc) documentation on the
> privilegeType/Name
> enum values or fieldName/Values. Is there any?
> 
> I found this mail:
> http://mail.internet2.edu/wws/arc/grouper-users/2009-02/msg00055.html
> 
> Which seems to answer part of my question, but where would I look
> without the
> mailinglist?
> 
> Ok... (I'm writing and thinking aloud now): it seems to be 'documented'
> in the
> grouper_fields table (privilege and type mapped to name).
> 
> Still the question why the privilegeType/Name route could not be used
> remains...
> 
> 
> Regards,
> Martin
> 
> On Monday 23 February 2009 19:43:25 Chris Hyzer wrote:
> > I looked into it, and found out why I never added it to WS, because
> the
> > grouper API doesn't have a method for it.  :)
> >
> > Anyways, I added it, feel free to get latest from the 1.4 branch, and
> try
> > it out.  I need to do more testing before closing the bug, but the
> test I
> > did through a WS call worked fine.
> >
> > I added the API:
> >
> > gsh 0% subj = findSubject("10021368")
> > subject: id='10021368' type='person' source='pennperson' name='Chris
> Hyzer'
> > gsh 1% sess = GrouperSession.start(subj)
> > edu.internet2.middleware.grouper.GrouperSession:
> > 8d17a97d-3d1a-4e39-a44c-01a3fead792d,'10021368','person' gsh 2%
> member =
> > MemberFinder.findBySubject(sess, subj)
> > member: id='10021368' type='person' source='pennperson'
> > uuid='6512f26a-98b5-486c-bc94-ac26e0d9a7ca' gsh 3% field =
> > FieldFinder.find("admins")
> > access privilege: 'admins'
> > gsh 4% member.getGroups(field);
> > group: name='aStem:whateverGroup2' displayName='aStem:disp2'
> > uuid='b3be109a-afb6-49d0-8aaf-73cbd130f967' group:
> name='aStem:aGroup'
> > displayName='aStem:aGroup' uuid='4992b987-3329-418e-ba83-
> 9d9335305902'
> > group: name='aStem:whateverGroup' displayName='aStem:disp1'
> > uuid='2703916b-ac8a-4830-9a60-698a3b1faf97' gsh 5%
> >
> > Then I added a param on the getGroups web services (all flavors,
> though
> > here is an example in rest batch):
> >
> > <WsRestGetGroupsRequest>
> >   <subjectLookups>
> >     <WsSubjectLookup>
> >       <subjectId>10021368</subjectId>
> >     </WsSubjectLookup>
> >     <WsSubjectLookup>
> >       <subjectId>10039438</subjectId>
> >     </WsSubjectLookup>
> >   </subjectLookups>
> >   <actAsSubjectLookup>
> >     <subjectId>GrouperSystem</subjectId>
> >   </actAsSubjectLookup>
> >   <params>
> >     <WsParam>
> >       <paramName>fieldName</paramName>
> >       <paramValue>admins</paramValue>
> >     </WsParam>
> >   </params>
> > </WsRestGetGroupsRequest>
> >