Grouper Developers Forum

[Chris Hyzer <>]

Maybe you could give an example end to end of what this would look like so it is more concrete.  i.e. if the config file has this, then this data is retrieve from this source, and the result is something else.

 

Also regarding this:

 

> Shibboleth users might benefit from this, as they could produce group membership attributes directly from Grouper, as an

> alternative to provisioning an LDAP directory and the LdapDataConnector.

 

At the current time the main “read” point of Grouper has been LDAP so that the grouper DB does not need to be always available… so I think we should currently assume that for Shib connectivity.  Though I would like to see long term a replicated readonly DB for grouper (through notifications) which is always available, with a web service connector… J

 

Chris

 

 

From: [mailto:] On Behalf Of Tom Zeller
Sent: Thursday, April 16, 2009 10:14 AM
To:
Subject: [grouper-dev] ldappc/provisioning + shibboleth AttributeResolver ?

 

As mentioned on the conference call yesterday, I think it would be interesting to try and re-use Shibboleth's AttributeResolver.

 

The AttributeResolver would be responsible for producing a map of attributes suitable for provisioning, via Map<String, BaseAttribute> resolveAttributes(). At the least, we could use this interface and start with the ShibbolethAttributeResolver implementation - if things don't work out we can always roll our own.

 

I'm thinking that we would write a GrouperDataConnector, which would be responsible for supplying group attributes and memberships from Grouper, simple enough it seems. Shibboleth users might benefit from this, as they could produce group membership attributes directly from Grouper, as an alternative to provisioning an LDAP directory and the LdapDataConnector.

 

I'm not sure if the methodology for resolving subjects to provisioned target identifiers will be part of the GrouperDataConnector, or elsewhere.

 

So far, the primary drawback as far as Grouper is concerned seems to be Shibboleth/SAML configuration and code overhead, which we would likely avoid if we were writing from scratch.

 

The primary benefit is likely the maturity of the already available 'tools' for massaging attributes, e.g. regex, script, template, etc.

 

Another benefit is that we could access attributes outside of Grouper for provisioning - I hadn't really thought of that before. An example here might be an AttributeFilter which looks up in a source ERP (or something) if a member is 'active' when deciding whether or not to provision their memberships.

 

If we were to use Shib's AttributeResolver and speak SPML rather than LDAP to talk to provisioned targets, then it seems we would be in the ballpark of a rather 'generic' provisioner.

 

My report so far,

TomZ