Grouper Developers Forum

[Tom Barton <>]

I agree that we should add the ability to have attributes affixed to 
memberships and stems as we do currently for groups. Some of these 
attributes will support future in-built grouper functionality (eg, aging 
of groups or memberships) while others will support a site's own custom 
needs.

Currently, only a grouper system admin can add new group attributes to 
the deployment and package them into group types. I'd like whatever we 
do for memberships and stems to parallel what we do for managing group 
attributes, ie, have a single style of attribute management across 
grouper objects that have attributes.

There are two current limitations on group attribute management that we 
might want to address. First, currently an attribute can only be 
assigned to a single group type. We might instead want attributes to be 
assignable to more than one type. Second, currently attributes are 
either lists of Subjects or single-valued strings. Should we extend the 
set of attribute-types? Eg, support multi-valued strings? Go further 
down the path of attribute-types that's been blazed by the X.500 folks? 
Worry about character encodings and variant syntaxes? I don't want to 
make things any more complicated than necessary to support real use 
cases, but we might need to think carefully about how to systematically 
add attribute-types before adding any more in an ad hoc manner.

I think there are two aspects of existing attribute management that 
should be preserved. First is the packaging of attributes into bundles 
called "group types". This was done to mimic the X.500 model, 
recognizing that a given attribute-relying capability may require 
several attributes for its purpose. I guess we wouldn't call them 
*group* types any longer. Maybe objectclasses, using X.500 terminology. 
The second aspect to be preserved is keeping the ability to create new 
attributes and "objectclasses" limited to grouper system admins.

To keep a new attribute-management capability realistic and suitably 
limited, I'd like us to focus on one or a small number of actual uses. 
For starters, I can see aiming to support the following in 1.5:

1. Group and membership life cycle management, ie, automated activating, 
deactivating, and reactivating memberships and groups.

2. Attribute-based selection of stems. Eg, to support different 
provisioning schemes.

3. Support for grouper's role in what comes out of the discussion of 
MACE privilege management, as that becomes clearer.

Tom

Chris Hyzer wrote:
> Here is a stream of consciousness on something I would like to work on 
> for 1.5… I would like to make this generic so when use cases appear 
> later on we have flexibility (sort of like how we have more hooks than 
> we need right now J ).  Thoughts?  Use cases to add?
>
>  
>
> https://wiki.internet2.edu/confluence/display/GrouperWG/Grouper+Attributes
>
>  
>
> Regards,
>
> Chris