Grouper Developers Forum

[Tom Barton <>]

I think you're posing the question of which configuration style should 
be chosen in this instance: in the attribute resolver style, or in the 
grouper-ws style. I think that having consistency within a single 
configuration task is more important than consistency across distinct 
elements of the toolkit. Would there also be less parsing code to 
maintain over time if you stay with "attribute resolver only" config style?

Does that help?

Tom

Tom Zeller wrote:
> How do folks feel about embedding grouper WS xml in the attribute config 
> file for ldappc ?
>
> Most provisioning tools 
> I've seen are essentially attribute mappers, which map a source attribute to a target attribute, 
> both selected by a string name, 
> with functions likes regex's or scripts to massage attribute values.
>
> Memberships, however, aren't described completely by an attribute name. 
> I had suggested using namespaces to help, but even so, namespaces are 
> limited.
>
> Let's consider eduCourseMember, whose provisioned value looks something 
> like role@course, e.g. instructor@edu:course:name. To provision this 
> value, we'll need to provision members differently (than we do for the 
> default "members" list) for a group of a particular type, position in 
> the stemspace, and/or for a custom list of a group. Since we need to 
> provision in a different way, we'll need to select these memberships 
> somehow.
>
> I see two approaches for providing criteria which determine how a 
> membership is provisioned : (1) existing shibboleth attribute filtering 
> rules or (2) grouper WS.
>
> The shib attribute filtering rules expressed in xml might be something 
> like :
>
> <... id="eduCourseMember" ...
>   <filter rule="allow" groupType="course" >
>
> while using grouper WS it might be
>
> <... id="eduCourseMember" ...
>  <WsRestGetGroupsRequest .... something ...
>
> Initial responses ?
>
> Thanks,
> TomZ