<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 8/3/2016 2:06 PM, Cantor, Scott wrote:<br>
<blockquote cite="mid:d6307bc3-2343-0414-74b1-d600ed28df97@osu.edu"
type="cite">
<blockquote type="cite" style="color: #000066;">
<pre wrap="">I'm starting to wonder if I need to do something within the regex
<span class="moz-txt-citetags">> </span>predicate (which is basically just the abstract attribute predicate with
<span class="moz-txt-citetags">> </span>the match method overridden to check regex instead of the string map).
</pre>
</blockquote>
<pre wrap="">The predicate also has to have a matching strategy function injected to
locate the context, and I don't know offhand what the default is. I
assume it's also going to look under the RP context.</pre>
</blockquote>
<br>
Bingo! Since 99.999% of the time the attribute predicate will be
used somewhere that wants to use the "standard" resolution results,
it defaults to RPC->AC. Configuring the predicate bean with the
same strategy as the Resolve action bean makes it work.<br>
<br>
<tt> <bean id="isPasswordExpired"
class="edu.umn.oit.idm.shib.RegexAttributePredicate"</tt><tt><br>
</tt><tt> p:pat="^[Xs].*" p:attributeId="umnPasswordStatus"</tt><tt><br>
</tt><tt>
p:attributeContextLookupStrategy-ref="shibboleth.ChildLookupOrCreate.AttributeContext"/></tt><br>
<br>
I suspect using the child lookup or create helper is fine here
despite this strategy being lookup only.<br>
<br>
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.<br>
<br>
One piece still left that I haven't verified: since there may be a
few minutes delay while the user changes their password, the RP
context attributes may no longer be current, so I might need to
re-resolve the "real" attributes when the user finally gets through,
in order for them to be "current". This would of course only affect
SPs that receive attributes that are likely to have changed
(certainly the password status and last password change time). Of
course, now I have a pretty good idea of how to do that :)<br>
<br>
Thanks as always for all your help and advice!<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>