Grouper Users - Open Discussion List

[Tom Barton <>]

Martin,

Thanks, yes, that's quite clear.

A workaround such as an "owner" custom attribute should indeed work, as 
it skirts the underlying issue of grouper web services needing to 
respect the access and privilege interfaces that grouper relies on in 
order to implement privilege management in a manner that can be 
outsourced to an external privilege management system.

The "proper" solution, Chris's option (a), will provide the needed 
capability and respect this approach to internal privilege management, 
but won't be available for a while. What's your timeframe?

We've also been running into other difficulties with trying to maintain 
the potential for outsourcing management of grouper's internal 
privileges. We'll be discussing the situation on the next grouper-dev 
call, and potentially on an upcoming mace-paccman call as well. These 
experiences are making me reconsider how to recognize the separate 
concerns of enterprise privilege management and application-specific 
privilege management, and what a privilege management interface should 
do to respect those separate concerns.

Tom

Martin van Es wrote:
> 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