Can an intercept trigger a re-resolution of attributes?

[Christopher Bongaarts]

On 8/4/2016 5:54 PM, Cantor, Scott wrote:
>> The data connector appears to still read all the attributes - doesn't
>> >appear that simply defining the attributesToResolve on the resolve
>> >action bean is sufficient to limit it at that level, though it does dump
>> >all the attributes except for the attributesToResolve after looking them
>> >up.  It may end up faster that way anyway in our environment, since LDAP
>> >can leverage its entry cache if nothing's changed yet.
> If you resolve an attribute, it will resolve the dependencies of just
> that attribute, but if that's still your main LDAP query, then it's
> going to run that query. It won't resolve all the attributes on top of
> that query. You're telling it what IdPAttribute to resolve.

Indeed, the attribute resolver was not actually Resolving all the 
attributes, it was just the LDAP read was still returning them all.

> Keep in mind that if the LDAP connector is caching, that's going to
> cause problems getting it to re-resolve the data since it will just give
> you back the same results.

The entry cache I mentioned was part of our LDAP server itself, not the 
IdP's LDAP code.  Since it has direct access to the entry it knows to 
invalidate results if the entry has been modified.

We'll watch out for caching on the IdP side when we tackle LDAP 
configuration tuning.  So far it hasn't been a problem - it has always 
picked up the change "immediately" (i.e. within a few seconds).  We're 
still mostly using defaults for LDAP tunables.

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160804/099e94fb/attachment.html>