Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] LDAPPC 1.5.0 example configuration

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] LDAPPC 1.5.0 example configuration


Chronological Thread 
  • From: Tom Barton <>
  • To: Tom Zeller <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] LDAPPC 1.5.0 example configuration
  • Date: Tue, 28 Jul 2009 14:12:40 -0500

Excellent. Thanks. -Tom

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




Archive powered by MHonArc 2.6.16.

Top of Page