invoking data connector dynamically in attribute resolver

[Robert A Basch]

Not to beat a dead horse, but I'm just getting back to this, and realized
that I forgot to note another disadvantage of the single attribute
authority approach (besides introducing unnecessary load).

Our additional connectors' queries would be based on dependency attributes
which in most cases will not have a value, so, to avoid an error in the
standard single attribute authority configuration, it looks like we would
have to do something rather inelegant to construct a proper filter/query
to produce no results, using the template language.

For example, in an LDAP connector performing the additional query, I think
we would have to do something like:

    <FilterTemplate>
        <![CDATA[
            #if (${attributeDependency.isEmpty()})
              <dummy filter guaranteed to return no results>
            #else
              <"real" LDAP search filter>
            #end
        ]]>
    </FilterTemplate>

Of course it is not hard to come up with an appropriate dummy filter, and
I don't consider doing that to be inherently unacceptable, but I felt it
was worth mentioning.

Thanks,
Bob


On May 23, 2012, at 6:19 PM, Robert A Basch wrote:

> I imagine the additional data sources are capable of handling the load, but I
> would like to be able to forestall any such issue entirely, if feasible.
> 
> We will certainly consider the trade-offs before proceeding with this approach.
> Generating the attributes based on the added connector results will make the
> resolver configuration more complex in itself, never mind the added complexity
> introduced by maintaining multiple attribute authorities.  (In an ideal world,
> we would be able to pull in the needed data via our standard directory query
> for the principal, but I don't live in that world).
> 
> Thanks,
> Bob
> 
> 
> On May 23, 2012, at 4:26 PM, Chad La Joie wrote:
> 
>> While I am adding this feature to IdPv3 (it's already done actually),
>> the question I always ask people about this is "Is the feature worth
>> the complexity?".  Stuff like this makes configurations more complex
>> and thus more difficult to write and debug.
>> 
>> So, let me ask you the same question, just so I have additional data.
>> Why do you want to do this?  Are the other data sources really slow or
>> very limited in capacity?
>> 
>> On Wed, May 23, 2012 at 4:16 PM, Robert A Basch <rbasch at mit.edu> wrote:
>>> On May 18, 2012, at 9:16 PM, Peter Schober wrote:
>>> 
>>>> Someone from our constituency used the method described in
>>>> https://lists.internet2.edu/sympa/arc/shibboleth-users/2011-05/msg00433.html
>>> 
>>> Thanks, Peter, the multiple attribute authority approach looks promising.  Our
>>> case may be a bit different from the referenced thread, in that we want to invoke
>>> an additional set of connectors (i.e. as well as the standard set) for the relying
>>> parties in question, but that would just make our configuration more cumbersome.
>>> Another possible issue is that uApprove (which we are looking at, but have not yet
>>> deployed) apparently can only deal with one attribute authority, but that may not be
>>> a deal-breaker.
>>> 
>>> Thanks,
>>> Bob
>>> 
>>> 
>>> 
>>> --
>>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>> 
>> 
>> 
>> -- 
>> Chad La Joie
>> www.itumi.biz
>> trusted identities, delivered
>> --
>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net