Can an intercept trigger a re-resolution of attributes?

[Christopher Bongaarts]

On 8/1/2016 3:21 PM, Cantor, Scott wrote:
>> 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.
> Caching aside, yes.
>
>> >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).
> The one in the profile flow is the "normal" one. That runs before the interceptors.

This got me closer, i think.  I noticed that some flows use alternate 
lookup/context strategies, and some leave them unspecified (default?).

So with this bean definition in my intercept beans.xml file:
     <bean id="ResolveAttributes"
class="net.shibboleth.idp.profile.impl.ResolveAttributes" scope="prototype"
c:resolverService-ref="shibboleth.AttributeResolverService"
             p:maskFailures="true">
         <property name="attributesToResolve">
             <bean parent="shibboleth.CommaDelimStringArray" 
c:_0="umnPasswordStatus" />
         </property>
     </bean>

it almost works.  Clicking continue on the page lets me retry until my 
password status attribute changes, and when it does, it lets me through, 
but it seems to be clobbering my "real" attributes as there's nothing 
left to return (which makes sense given that the profile resolves them 
prior to running the post-auth intercept).  I also get this error 
message every time I click continue:

2016-08-01 16:18:54,550 - ERROR 
[net.shibboleth.idp.attribute.context.AttributeContext:113] - Unfiltered 
attributes have already been set in this flow.

Both of these sound to me like I should be using some sort of temporary 
attribute context within the intercept, but I'm not quite sure where it 
should go in the Giant Context Tree, or how to specify it (perhaps 
defining more shibboleth.ChildLookup(orCreate) beans).

Or maybe I just need to re-run the resolver/filter one more time after 
the intercept finishes?  (Seems like yet another red flag that I should 
be doing this in a login flow instead of an intercept.)

-- 
%%  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/20160801/ba137759/attachment.html>