Grouper Users - Open Discussion List

[Tom Barton <>]

Martin,

Could you describe in more detail your needs for managing 
grouper-specific privileges via web services? I may have just overlooked 
it, but I couldn't find what I was looking for in your recent postings.

We're very eager to help you accomplish what you need.

Thanks,
Tom

Chris Hyzer wrote:
> > 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>