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