Delegation flow: authn and c14n

[Brent Putman]

On 9/2/15 7:26 PM, Cantor, Scott wrote:
> On 9/2/15, 6:50 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
>
>
>
>> 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.
> 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.

Yeah, had thought about that, just hadn't tried it yet.  Probably
cleaner and doesn't expose the SAML stuff to the outer flow.

> There's also the feature to programmatically instruct the code not to persist an AuthenticationResult, which probably applies here.

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.

> 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.

Are you referring to something like this:

    <bean id="Liberty.SSOS"
       
class="net.shibboleth.idp.saml.idwsf.profile.config.SSOSProfileConfiguration"

            p:authenticationFlows="WSSSAML2"           
            p:inboundInterceptorFlows="security-policy/saml2-idwsf-ssos"
            p:encryptionOptional="%{idp.encryption.optional:false}" />


Already doing that and it works to select that flow, but it still seems
necessary to set the *available* flows via idp.properties.


>> 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.
> Sure.

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. 

>
>> (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?)
> 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.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150902/79b9ad8d/attachment.html>