Grouper Developers Forum

[Tom Zeller <>]

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