Can an intercept trigger a re-resolution of attributes?

[Christopher Bongaarts]

On 8/1/2016 2:27 PM, Cantor, Scott wrote:
>> The password change opens in another window, so when the user is done
>> changing password, they could go back to the expired password view page
>> and click a "Continue" button/link.  The problem I've bumped into is
>> that simply transitioning from the expired password view to the
>> beginning of our intercept flow (where it checks the password status
>> LDAP attribute) does not pick up any changes to the LDAP entry.
> Meaning you're trying to prevent them skipping it I guess. I tend to think that's a bit more of a "do it in the login flow" use case. As I keep noting, while intercepts are fully supported in preventing a request from being services, they aren't well suited to impacting a login retroactively.

The idea was that the user would click "Continue", and if they had 
changed their password, they would end up being "logged in" and sent 
along to the SP.  If they had not, they would stay on the expired 
password view until the LDAP attribute changed.

>> Is there a way to trigger re-resolution of (perhaps specific) attributes
>> during an intercept flow?  Either as a flow action, or directing to
>> another flow somehow?
> You can, yes. 3.3 makes it easy (yes, I know) because there's a simple shortcut implemented now to run attribute resolution in a script. Doing it as a flow is possible, but you pretty much have to wire it up yourself, it's not something exposed that you can reuse.
>
> The contract is, I think, documented in the wiki though.
>
> https://wiki.shibboleth.net/confluence/display/IDP30/AttributeResolver
>
> Bottom of page. Implemented in a single ResolveAttributes Java action bean, and then there's a companion bean to fo filtering.

An Action bean is probably sufficient for what we want to do - I can 
invoke it prior to looping back to the start of the flow, and presumably 
it will check the newly resolved attribute.

>
>> If it's not possible, I suspect we'll have to pull the password status
>> check into the actual login flow somehow.  I'm having trouble figuring
>> out where the "pre-resolution" of attributes is happening, though.
> The "support" for attribute lookup during authentication, apart from the LDAP features, is like the initial-authn feature, pointless and badly implemented. If that's what you mean by pre-resolution.
>
> "Normal" resolution happens shortly after authentication completes and before the interceptors run.

The "pre-resolution" I meant is probably your "normal"  resolution here 
(I meant the one that happens "during"/immediately after authN, as 
opposed to the ResolveAttributes action in e.g. the SAML2 profile flow).


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