Grouper Developers Forum

[Tom Barton <>]

Chris Hyzer wrote:
> 1. If you want to query assignments on assignments, you need to query
> the assignments with a special flag, or provide the assignmentId
>
> 2. Security:
>
> Groups:
>
> - read attribute
>   - view group and read attribute
>
> - assign attribute
>   - admin group and update attribute

I can imagine use cases in which a group's admin is not the same as the 
person who's responsible for some of the attributes assigned to the 
group, ie, there's two sources of authority to be combined: for 
membership and ordinary group info, and for a special attribute (maybe a 
priv). I think we'd need to add some new element to grouper's security 
structure to support this type of separation of duties. The model above 
doesn't do it.

More commonly, I think, attributes are available to group admins as 
ordinary means to decorate a group. In this case I can imagine the 
UPDATE priv for an ordinary attribute to be set to Everyone, and your 
assignment security model works fine, although it's overkill for this 
use case.

It seems that to cover both use cases we need a way to list which 
Subjects can assign an attribute to which other objects. I can see 
scoping the other objects by the stems in which they reside. Eg, Subject 
1 can assign Attribute royal:privs:palace_key to all objects under 
royal:musketeer:, enabling Subject 1 to assign that priv to any group of 
musketeers, to any memberships in those groups, or to any substem of 
royal:musketeer:.

Until we implement something along those lines, is it sufficient to just 
let a group ADMIN assign any attribute they can READ to the group?

> Stems
>
> - read attribute
>   - read attribute
>
> - assign attribute
>   - create in stem? and update attribute

The analog for a stem of ADMIN for a group is STEM. Like my rationale 
for groups, for the time being perhaps just let those with STEM who can 
READ an attribute assign it to the stem.

> Members
>
> - read attribute
>   - read attribute
>
> - assign attribute
>   - wheel or root? and update attribute

Wheel sounds right, at least for now. I don't see the need for UPDATE on 
the attribute here.

> AttributeDef
>
> - read attribute
>   - read attributedef and read attribute
>
> - assign attribute
>   - admin on attributeDef and update on attribute

Just READ on attribute, as for groups & stems above.

> Membership (immediate or any): note, only members list on groups
>
> - read attribute
>   - read the group and read the attribute
>
> - assign attribute
>   - update the group and update the attribute

Only READ on the attribute, as above.

> Assignment on attribute assignment
>
> - read attribute
>   - read the underlying assignment (follow the above rules), and read 
> the attribute
>
> - assign the attribute
>   - update the underlying assignment? (follow the above rules), and 
> update the attribute

Is "this assignment expires next Wednesday" an example of an assignment 
on an attribute assignment? What's a better example, to help guide our 
thinking about this?

> 3. Assignment of attributes on memberships is only on members list

... and not on privilege lists, eg, readers, updaters, etc. Agree.

> 4. If you want to assign an attribute to an immediate membership or an 
> attribute assignment, you need to get the ID of it first
>
> 5. If you want to assign an attribute to an any membership, you need to 
> provide the groupLookup and the subjectLookup