Grouper Developers Forum

[Tom Zeller <>]

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