<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 9/2/15 7:26 PM, Cantor, Scott wrote:<br>
</div>
<blockquote cite="mid:723EBABE-4008-4BC1-9CE3-7524D8A25405@osu.edu"
type="cite">
<pre wrap="">On 9/2/15, 6:50 PM, "dev on behalf of Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfofputmanb@georgetown.edu"><dev-bounces@shibboleth.net on behalf of putmanb@georgetown.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The trick was then realizing that the finalization of this authn flow should not remove the SubjectCanonicalizationContext as typically happens elsewhere, but instead to just copy the canonicalized principal name into a new UsernamePrincipal in the existing Subject.
</pre>
</blockquote>
<pre wrap="">
Well, nominally it could remove the one it used internally and then fulfill its obligation to the overall authn flow by creating a new one. So it's all in how one looks at it I guess.</pre>
</blockquote>
<br>
Yeah, had thought about that, just hadn't tried it yet. Probably
cleaner and doesn't expose the SAML stuff to the outer flow. <br>
<br>
<pre wrap="">
</pre>
<blockquote cite="mid:723EBABE-4008-4BC1-9CE3-7524D8A25405@osu.edu"
type="cite">
<pre wrap="">There's also the feature to programmatically instruct the code not to persist an AuthenticationResult, which probably applies here.
</pre>
</blockquote>
<br>
Don't think I knew about that. That sounds like what I was after.
I didn't want anything that related to the delegation act of
"authentication", such as it is, to be in any way stored for the
user's regular tracking of authentication data.<br>
<br>
<pre wrap="">
</pre>
<blockquote cite="mid:723EBABE-4008-4BC1-9CE3-7524D8A25405@osu.edu"
type="cite">
<pre wrap="">
I was going to say, I need to check whether configuring the flows on the profile config bean overrides or subsets the set of flows active via property. We probably want it to override, that way you could hardwire the flow to activate in the default profile config bean/parent.</pre>
</blockquote>
<br>
Are you referring to something like this:<br>
<br>
<tt> <bean id="Liberty.SSOS"</tt><tt><br>
</tt><tt>
class="net.shibboleth.idp.saml.idwsf.profile.config.SSOSProfileConfiguration"
</tt><tt><br>
</tt><tt> p:authenticationFlows="WSSSAML2" </tt><tt><br>
</tt><tt>
p:inboundInterceptorFlows="security-policy/saml2-idwsf-ssos" </tt><tt><br>
</tt><tt>
p:encryptionOptional="%{idp.encryption.optional:false}" /></tt><br>
<br>
<br>
Already doing that and it works to select that flow, but it still
seems necessary to set the *available* flows via idp.properties.<br>
<br>
<br>
<blockquote cite="mid:723EBABE-4008-4BC1-9CE3-7524D8A25405@osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">The other direction I had in mind for this was to use the transition override stuff we had been discussing to short-circuit some of what's in sso-abstract-flow.xml. Basically have DoProfileWork transition to a profile-specific state chain that just does hardwired
authn/c14n (no selection, etc), and then when it completes, resume the parent flow with ResolveAttributes. Essentially bypass all the parent authn stuff.
</pre>
</blockquote>
<pre wrap="">
Sure.</pre>
</blockquote>
<br>
I started trying to do that, but it got really complicated because
there are assumptions built into some of the authn-related abstract
actions that assume stuff populated on e.g. AuthenticationContext.
So I bailed for now. <br>
<br>
<blockquote cite="mid:723EBABE-4008-4BC1-9CE3-7524D8A25405@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">(Semi-related: just wanted to confirm that there isn't any issue with this flow or ECP (the SOAP client flows) with all the new client storage stuff we've added to sso-abstract-flow.xml. I assume that detects non-browser and bypasses HTML storage?)
</pre>
</blockquote>
<pre wrap="">
Yes. Loading of state from cookies (which is irrelevant for this case, but doesn't hurt anything) takes place prior to calling the subflow, and it does call the write subflow even for non-browser profiles to get the cookie set again, but it always skips the views. Not heavily tested yet though, I still need to run ECP tests with all that on.</pre>
</blockquote>
<br>
This flow isn't throwing any obvious errors on that stuff, but I
don't know what to look for as far as it doing things it ideally
shouldn't.<br>
<br>
</body>
</html>