Grouper Users - Open Discussion List

[Tom Zeller <>]

> Can shib's existing DataConnector implementations be used with ldappcng, so
> that it can be used to provision info from grouper, ldap, rdbms, and flat
> files?

Yes and no. The bulk operations which operate on multiple identifiers
require an extension to the DataConnector interface. The notion of
returning all principals from a DataConnector is not part of shib, as
far as I can tell. This, and incremental provisioning, are on my list
for discussion for IdPv3 work.

> Does GroupFilter apply only to the grouper DataConnector?

Yes, all 3 grouper DataConnectors : GroupDataConnector,
MemberDataConnector, and StemDataConnector, which are all included in
the one grouper-api shib plug-in (although the WS based plug-in should
be on the map somewhere).

> BTW, "minus" is fine. "Relative complement" is probably the term you were
> seeking. :-)

Nice.

> Tom
>
> Tom Zeller wrote:
>>
>> 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
>
>