grouper-dev - Re: [grouper-dev] LDAPPC 1.5.0 example configuration
Subject: Grouper Developers Forum
List archive
- 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:
Regarding the design of your attribute authority, is it "pluggable", so thatA question: can the various extensions to the shibboleth attribute resolverIf you are referring to the attribute filtering engine, then yes, I've
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?
provided a simple attribute authority which supports this.
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
- LDAPPC 1.5.0 example configuration, Tom Zeller, 07/27/2009
- Re: [grouper-dev] LDAPPC 1.5.0 example configuration, Tom Barton, 07/28/2009
- Re: [grouper-dev] LDAPPC 1.5.0 example configuration, Tom Zeller, 07/28/2009
- Re: [grouper-dev] LDAPPC 1.5.0 example configuration, Tom Barton, 07/28/2009
- Re: [grouper-dev] LDAPPC 1.5.0 example configuration, Tom Zeller, 07/28/2009
- Re: [grouper-dev] LDAPPC 1.5.0 example configuration, Tom Barton, 07/28/2009
- Re: [grouper-dev] LDAPPC 1.5.0 example configuration, Tom Zeller, 07/28/2009
- Re: [grouper-dev] LDAPPC 1.5.0 example configuration, Tom Barton, 07/28/2009
- Re: [grouper-dev] LDAPPC 1.5.0 example configuration, Tom Zeller, 07/28/2009
- Re: [grouper-dev] LDAPPC 1.5.0 example configuration, Tom Barton, 07/28/2009
Archive powered by MHonArc 2.6.16.