Grouper Developers Forum

[Tom Barton <>]

 wrote:
> > > We would need a notional field, or perhaps the 'name' field to
> > > indicate whether a group itself can be deleted. Could be
> > > simplified to GrouperAccess.has(GrouperSession s, GrouperGroup g,
> > >  GrouperMember,READ/WRITE)
>
>
> > I'm sorry - I still haven't understood a use case requiring that
> > deletion be split off from the ADMIN priv. I know I'm getting
> > denser with age, maybe if you write real slowly ... :-)
>
>
> At Bristol I can envision a loader creating lots of empty groups
> which are then administered by a human - who shouldn't actually
> delete the group. This would allow conformity of naming, and
> standardisation of structure which we think will  make training
> easier, and will reduce the workload of departmental administrators.
> UPDATE privilege would suffice for changing membership, but if we
> want to allow some attributes to be modified as well we have to give
> ADMIN privilege.

The field-level read-write privs that are enjoyed by the abstract access 
privs (READ, VIEW, UPDATE, ADMIN, OPTIN, OPTOUT) are mapped in the 
grouper_field table. These can be altered (with care when it comes to 
base type fields!) by sites in the same way that sites can extend the 
set of group fields and group types. And in the case of privs over 
site-defined fields, the site *must* put something in the readPriv and 
writePriv columns of the grouper_field table for each new field. You 
could opt, for example, to extend UPDATE to have writePriv over 
additional fields.

That much is true even in 0.5. The intent is by 0.6 or 0.7 to have the 
API's enforcement of the security model completed. Only two priv 
management actions need to be baked in code: granting of ADMIN to 
creators of new groups, and granting of STEM to creators of new 
namespaces. The rest should be data driven, ie, the API treats the 
access privs appearing in the grouper_field table as primitives and 
mediates read-write field level access accordingly.

If we achieve that design, then it will also be possible for a site to 
extend the acces priv model as they see fit. However, as with the 
ability to extend group types, I don't see any support for this being 
put into the API until after v1.0, if at all.

> > > ...
>
> > > What I mean is for Subject searches implemented through 
> > > edu.internet2.middleware.subject.SubjectTypeAdapter to have the
> > > same facility as GrouperQuery, namely, to qualify resultsets 
> > > based on who is doing the searching.
>
>
> > Ok. We could pass a subjectID along to the
> > subjectTypeAdapter<Type>Impl class, in case it has a capability to
> > use its own security to filter results based on that subject.
>
> We might need to send the type as well?

Yes.

Tom