Grouper Users - Open Discussion List

[Tom Zeller <>]

The selection of the groups, members, and stems to be provisioned is
the hackiest part of ldappcng. Hacks can be considered compliments (I
took it that way) but it means improvements should be made.

Previously in ldappc (not ng), the selection of the groups (and their
members and stems) to be provisioned was performed via a single
<grouper-queries /> configuration element which selected groups by
attribute or by stem or by their union.

When considering how to reproduce the <grouper-queries /> logic in
ldappcng, I was not sure which xml configuration file to use. Either
the shibboleth attribute resolver configuration or the ldappcng spml
configuration. I opted against the ldappcng.xml config file, since the
spml spec doesn't discuss how to select the objects to be provisioned
- perhaps a lookup request against a "provider" with an arbitrary
query.

Instead, the business logic provided by <grouper-queries /> was added
to the grouper plug-in to the shibboleth attribute resolver
configuration by attempting to connect the subject api source with the
shibboleth attribute resolver data connector. A source returns
subjects which consist of an identifier and attributes, while data
connectors return attributes (of an identifier). The
SourceDataConnector interface extends DataConnector and provides a
method to get all identifiers (principal names). When ldappcng handles
a bulk[Calc|Diff|Sync] request it calls all of the source data
connectors' methods to get the identifiers of all the objects to be
provisioned.

The <GroupFilter /> configuration element of ldappcng filters the
identifiers of all the objects to be provisioned returned from the
source data connectors, and reproduces the ldappc <grouper-queries />
logic of selection by attribute or by stem, and in addition to union
provides intersection and, what's the third group operation, minus ?
(Let's see if TomB reads this far)

I imagine we'll provide additional filters in addition to selection by
exact attribute or by stem, I'd like to see us plug in grouper-ws. I
hope that ldappcng's xml configuration element for group, member, and
stem selection will be the same as that which a grouper web service
accepts, but in a flat file (at first, hopefully someone will point me
in the right direction regarding how to expose ldappcng as a web
service, eventually). Since we're re-using shibboleth's spring
configuration model, extending these filters should be straightforward
for deployers.

If someone was interested in provisioning something besides grouper,
that something would at a minimum need to provide the
SourceDataConnector interface. Writing a custom DataConnector seems
common (according to shibboleth-users), and providing the additional
"get all identifiers" method should be straightforward for rdbms and
ldap based data connectors.

We might should talk on grouper-dev regarding the connection points
between the source api and the shibboleth data connector, and perhaps
with other projects as well, if this is interesting.

TomZ

>> What's missing is good documentation, I've created a bug to
>> ensure I follow through :
>>
>> https://bugs.internet2.edu/jira/browse/GRP-467
>>
>> This is similar to a previous thread :
>>
>> https://lists.internet2.edu/sympa/arc/grouper-users/2010-06/m
>> sg00062.html
>>
>> I'm working on the wiki, however, for right now :
>>
>> The -calc <id>, -diff <id>, and -sync <id> options operate
>> only on the one object with the given <id>, for example, a
>> group where the id is the group name.
>>
>> The -bulkCalc, -bulkDiff, and -bulkSync options operate on the
>> identifiers of all objects returned from the Grouper
>> DataConnectors in the Attribute Resolver configuration. All
>> objects are provisioned by default. An optional <GroupFilter>
>> filters the objects to be provisioned.
>>
>> See "Group Filters" on
>> https://spaces.internet2.edu/display/GrouperWG/Grouper+and+Sh
>> ibboleth+Integration.
>>
>> For example, to provision groups (and their members) in a
>> specific stem :
>>
>> <resolver:DataConnector id="GroupDataConnector"
>> xsi:type="grouper:GroupDataConnector">
>>     <grouper:GroupFilter xsi:type="grouper:StemName"
>> name="stem:name" scope="SUB" />
>> </resolver:DataConnector>
>>
>> <resolver:DataConnector id="MemberDataConnector"
>> xsi:type="grouper:MemberDataConnector">
>>     <grouper:GroupFilter xsi:type="grouper:StemName"
>> name="stem:name" scope="SUB" />
>> </resolver:DataConnector>
>>
>> There are more examples in the junit test cases of the
>> grouper-shib project :
>>
>> http://anonsvn.internet2.edu/cgi-bin/viewvc.cgi/i2mi/tags/GRO
>> UPER_1_6_0/ldappcng/grouper-shib/src/test/resources/test/edu/
>> internet2/middleware/grouper/shibboleth/dataConnector/
>>
>> http://anonsvn.internet2.edu/cgi-bin/viewvc.cgi/i2mi/tags/GRO
>> UPER_1_6_0/ldappcng/grouper-shib/src/test/resources/test/edu/
>> internet2/middleware/grouper/shibboleth/dataConnector/GroupDa
>> taConnectorTest-resolver.xml?revision=6828&view=co
>>
>> Hopefully this will be enough for now to keep you rolling. Of
>> course, let us know what else you need.
>>
>> TomZ
>>
>> On Wed, Jul 14, 2010 at 9:46 AM, Paul Engle 
>> <>
>> wrote:
>>>
>>> All,
>>>
>>> I'm slowly wrapping my head around the new ldappc-ng
>>> provisioning utility, and it looks great. But I don't
>>> immediately see a way to provision just a subtree of the
>>> grouper hierarchy as I did with ldappc with the
>>> <grouper-queries/> section. Am I missing something? When I
>>> do a - -calc <stemName>, the output doesn't have anything
>>> but that individual stem. Is there a way to make it recurse
>>> from a given point?
>>>
>>> In our current environment, I use several different instances
>>> of ldappc to provision separate sections of the grouper
>>> hierarchy in different manners (different objectclasses,
>>> attributes, etc.) It looks like the new provisioner will be
>>> able to handle this all in one configuration (yay!) But I'd
>>> like to be able to test the separate sections individually
>>> while I'm still learning without having to provision the
>>> entire database.
>>>
>>>  -paul