invoking data connector dynamically in attribute resolver

Robert A Basch rbasch at mit.edu
Wed Jun 20 23:39:50 BST 2012


With no template conditional, if the filter is constructed with the value
of the dependency, e.g.:

  (attrname=${attributeDependency.get(0)})

and that dependency attribute has no values, then an exception occurs, and
resolution fails completely.  (This is with IdP version 2.3.3, with uApprove
enabled).  A similar error occurs if there is no filter (i.e. via a template
conditional).

Thanks,
Bob


On Jun 20, 2012, at 6:00 PM, Chad La Joie wrote:

> 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
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net



More information about the users mailing list