<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 8/1/2016 3:21 PM, Cantor, Scott wrote:<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE1129CC56F@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<blockquote type="cite" style="color: #000066;">
<pre wrap="">An Action bean is probably sufficient for what we want to do - I can
<span class="moz-txt-citetags">> </span>invoke it prior to looping back to the start of the flow, and presumably
<span class="moz-txt-citetags">> </span>it will check the newly resolved attribute.
</pre>
</blockquote>
<pre wrap="">Caching aside, yes.
</pre>
<blockquote type="cite" style="color: #000066;">
<pre wrap=""><span class="moz-txt-citetags">> </span>The "pre-resolution" I meant is probably your "normal" resolution here
<span class="moz-txt-citetags">> </span>(I meant the one that happens "during"/immediately after authN, as
<span class="moz-txt-citetags">> </span>opposed to the ResolveAttributes action in e.g. the SAML2 profile flow).
</pre>
</blockquote>
<pre wrap="">The one in the profile flow is the "normal" one. That runs before the interceptors.</pre>
</blockquote>
<br>
This got me closer, i think. I noticed that some flows use
alternate lookup/context strategies, and some leave them unspecified
(default?).<br>
<br>
So with this bean definition in my intercept beans.xml file:<br>
<bean id="ResolveAttributes"<br>
class="net.shibboleth.idp.profile.impl.ResolveAttributes"
scope="prototype"<br>
c:resolverService-ref="shibboleth.AttributeResolverService"<br>
p:maskFailures="true"><br>
<property name="attributesToResolve"><br>
<bean parent="shibboleth.CommaDelimStringArray"
c:_0="umnPasswordStatus" /><br>
</property><br>
</bean><br>
<br>
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:<br>
<br>
2016-08-01 16:18:54,550 - ERROR
[net.shibboleth.idp.attribute.context.AttributeContext:113] -
Unfiltered attributes have already been set in this flow.<br>
<br>
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).<br>
<br>
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.)<br>
<pre class="moz-signature" cols="72">--
%% Christopher A. Bongaarts %% <a class="moz-txt-link-abbreviated" href="mailto:cab@umn.edu">cab@umn.edu</a> %%
%% OIT - Identity Management %% <a class="moz-txt-link-freetext" href="http://umn.edu/~cab">http://umn.edu/~cab</a> %%
%% University of Minnesota %% +1 (612) 625-1809 %%
</pre>
</body>
</html>