invoking data connector dynamically in attribute resolver

[Chad La Joie]

Why do you think you have to do that?

On Wed, Jun 20, 2012 at 5:55 PM, Robert A Basch <rbasch at mit.edu> wrote:
> 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
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered