Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] grouper attributes

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] grouper attributes

Chronological Thread 
  • From: Tom Barton <>
  • To: Chris Hyzer <>
  • Cc: "" <>
  • Subject: Re: [grouper-dev] grouper attributes
  • Date: Mon, 29 Dec 2008 09:57:08 -0600

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.


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?



  • grouper attributes, Chris Hyzer, 12/11/2008
    • Re: [grouper-dev] grouper attributes, Tom Barton, 12/29/2008

Archive powered by MHonArc 2.6.16.

Top of Page