Grouper Users - Open Discussion List

[Martin van Es <>]

Hi Tom,

I think Chris answered my question in his last post to the list, but here's 
what I want to accomplish using WS's:

Students log in to a custom interface using a federation account. Once 
they're 
logged in, they are greeted with their self-service interface (showing all 
groups to which the subject (="Organization.uid") is member or admin). One of 
the things they can do is invite others to the groups they have created. To 
see what groups were created by this user, I was planning on (ab)using the 
admin privilege on the group. So in short I need a WS call to get 'all groups 
for which Subject has admin rights', to distinguish them from the list of 
'groups of which Subject is member'.

I was planning to use getGroups using the newly implemented params: 
fieldName/admins for this.

Maybe there's a much better or easier route to accomplish this that I have 
looked over? Would creating an 'owner' GroupType and adding the creator to 
this list be easier to search for?

To answer Chris' question: my intuition would be to have a priviligeType and 
Name like you do in the getGrouperPrivileges operation (access/admin) to get 
a 
match on all groups for which the subject has admin rights (I think this is 
what option 1 in Chris' reply means). The fieldName/Value route does the 
same, 
but seems awkward (and hard to understand) to a novice's eye, that's all.

Hope this clarifies my quest a bit ;)

Regards,
Martin


On Wednesday 04 March 2009 19:28:36 Tom Barton wrote:
> 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/m
> >iddleware/grouper/privs/AccessAdapter.java?revision=1.3&root=I2MI&view=mar
> >kup
> >
> > or for stems:
> >
> > http://viewvc.internet2.edu/viewvc.py/grouper/src/grouper/edu/internet2/m
> >iddleware/grouper/privs/NamingAdapter.java?revision=1.4&root=I2MI&view=mar
> >kup
> >
> > 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
> >