grouper-dev - Re: [grouper-dev] grouper attribute framework
Subject: Grouper Developers Forum
List archive
- From: Tom Zeller <>
- To: Chris Hyzer <>
- Cc: "" <>
- Subject: Re: [grouper-dev] grouper attribute framework
- Date: Thu, 11 Jun 2009 12:06:50 -0500
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=CwVddueVAg8oxRh8G7pNF0bez9ASSho07w/fovBgfYeK0t6s5wN5JwB3qv/U6JbgCf Ij6LJ3WXL+P3QPMbx4KpT4GK/ezLlQQHAx8Y0n8a6u+EITTe0X8bnChC6o+4RZ1iFjyA 1XdmeMdTlWHv3/Kte9f1/YijkdX3gXEfMhBy4=
When provisioning with the Shib AttributeResolver, access to source data is based on attribute name. So, to provision subjects of a group with AccessPrivilege.ADMIN, I specify the "admins" source attribute in the provisioning configuration and map "admins" to Group.getAdmins(). My suggestion is that we help folks out by using a source attribute name more descriptive (and not likely to collide with a deployer's custom attribute) then just "admins", maybe "grouper:privilege:admin", or as TomB has already described. Perhaps, yes, this could be specific to provisioning.
Respectfully I would prefer not to do this. If we start down this path, and we add another piece of metadata, do all the names change? I think it should be similar to how we have group types and attributes, where if you need metadata on a group, you go to grouper and ask for it. I definitely think we need namespaces, and it is #2 on my list on the wiki, but I don’t think we should constrain how users name things, or try to pack information inside of other information… of course when provisioning out of grouper, maybe in cases where the downstream system needs this, maybe it could be massaged there… could that work?
Thanks,
Chris
From: [mailto:] On Behalf Of Tom Zeller
Sent: Thursday, June 11, 2009 9:41 AM
To: Chris Hyzer
Cc:
Subject: Re: [grouper-dev] grouper attribute framework
I'm wondering if we might want to support/encourage namespaces in attribute names.
(I think there's folks on this list with lots of experience with such things :-)
My rationale is that often a group is represented as a collection of attributes, whether it be for provisioning, auditing, or transmission across a wire, and it might be beneficial for a consumer to be able to determine attribute 'metadata' based on name, since a consumer might have access only to an attribute's name and value.
For example, an attribute describing a stem might be named "grouper:stemAttribute:name".
I don't think we need any special code, we should consider an attribute name to be a String, but in practice we should use a reasonably simple naming convention - which I hope others will have more experience suggesting.
TomZ
On Thu, Jun 11, 2009 at 1:19 AM, Chris Hyzer <> wrote:
Hey,
There was already a wiki page on the attribute framework, and I updated it.
https://wiki.internet2.edu/confluence/display/GrouperWG/Grouper+Attributes
Note, this doesn't specify which release the features will go in, I assume 1.5 will be a limited edition as we get started with attributes. :)
Let me know any feedback.
Regards,
Chris
- grouper attribute framework, Chris Hyzer, 06/11/2009
- Re: [grouper-dev] grouper attribute framework, Tom Zeller, 06/11/2009
- Re: [grouper-dev] grouper attribute framework, Tom Barton, 06/11/2009
- RE: [grouper-dev] grouper attribute framework, Chris Hyzer, 06/11/2009
- RE: [grouper-dev] grouper attribute framework, Chris Hyzer, 06/11/2009
- Re: [grouper-dev] grouper attribute framework, Tom Zeller, 06/11/2009
- RE: [grouper-dev] grouper attribute framework, Chris Hyzer, 06/11/2009
- Re: [grouper-dev] grouper attribute framework, Tom Zeller, 06/11/2009
- Re: [grouper-dev] grouper attribute framework, Tom Barton, 06/11/2009
- Re: [grouper-dev] grouper attribute framework, Niels van Dijk, 06/12/2009
- RE: [grouper-dev] grouper attribute framework, Chris Hyzer, 06/12/2009
- Re: [grouper-dev] grouper attribute framework, Tom Barton, 06/12/2009
- Re: [grouper-dev] grouper attribute framework, Tom Zeller, 06/11/2009
Archive powered by MHonArc 2.6.16.