Grouper Users - Open Discussion List

[Tom Barton <>]

Tom,

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?

Does GroupFilter apply only to the grouper DataConnector?

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

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