Grouper Developers Forum

[Tom Zeller <>]

>>> A question: can the various extensions to the shibboleth attribute 
>>> resolver
>>> be used here too, for example, to filter returned values by regex, or to
>>> select values of one attribute contingent on the value returned for
>>> another attribute?
>>
>> If you are referring to the attribute filtering engine, then yes, I've
>> provided a simple attribute authority which supports this.
>
> Regarding the design of your attribute authority, is it "pluggable", so that
> attribute-massaging capabilities that can be plugged in to a shib AA can
> also be plugged in to the ldappc AA? Or are you, the developer, obliged to
> code such capabilities in yourself? Or some third model?

"Everything" is pluggable.

I've provided an attribute-authority since the SAML AA's encode via
SAML - we just want Strings.

I've modeled ldappc after shibboleth, whereby components are pluggable
via Spring. For example, in the description of ldappc-services.xml at
the bottom of

https://wiki.internet2.edu/confluence/display/GrouperWG/LDAPPC+1.5.0+Example+Configuration

ldappc is defined as a shibboleth service which requires an attribute
authority, which in turn requires an attribute resolver :

<Service id="ldappc" depends-on="attribute-authority" ...

<Service id="attribute-authority" depends-on="attribute-resolver" ...

<Service id="attribute-resolver" ...

So, deployers can implement the shibboleth interfaces as they see fit.
Ldappc is the component that is not itself pluggable, since that's
what we're providing :-)

Ldappc asks the attribute-resolver/authority for the attributes to be
provisioned, and then executes the provisioning. Any shibboleth
attribute extension is supported since ldappc operates subsequently.
Ldappc is an attribute consumer.

Right now in my existing code there are some assumptions made, for
example that all provisioned targets accept SPML requests, but I've
tried to minimize them. I'm balancing abstraction with getting this
thing rolling.

TomZ