Delegation flow: authn and c14n

[Cantor, Scott]

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.

>The end result is that when this subflow returns control back to the master 'authn' subflow, the latter should just see the UsernamePrincipal and that's what *it* performs canonicalization on, which is really a no-op since it's just a simple user name.

Yes, normally that's not anything but a formality/hook for the less common cases.

>Does this sound in any way wrong?  Remember that all this is necessary b/c the master 'authn' subflow calls the 'c14n/auth' subflow, and the latter doesn't currently know anything about SAML.  And I don't think we want it to.

I think it's 6 of one. The c14n/auth flow is designed to be a driver for arbitrary technologies (e.g. X.509) so it's not really out of place whichever way you prefer it.

>I do have concerns/questions about whether all the stuff that's happening more broadly with the population of the AuthenticationContext, active/inactive flow tracking and the Session is really correct for this use case.

Unlikely, though in a case that's unusual like this, one could imagine just activating specific login flow(s) directly on the profile config bean as a way of signaling that it's not really going through any kind of selection step.

>This is a weird use case, not like a
> standard user-facing login flow.  For example, does the act of say the "portal" SP authenticating as the user bleed info into the Session or other long-term data structures that is improper or which we don't want?  I just don't know my way around all that
> stuff yet.

Not really, because the session manager won't find the user's IdPSession (because you have no cookie). It may well end up creating a new one though, and that may be useless, but unlikely actively harmful, and we should be able to short-circuit it. There's also the feature to programmatically instruct the code not to persist an AuthenticationResult, which probably applies here.

>On the practical side, doing the authn this way means that the deployer will have to configure stuff before this would work.  Like any other login flow, they need to add the authn flow descriptor as an available flow in the user-space conf/authn/general-authn.xml. 
> They also need to enable it in conf/idp.properties, e.g. set "idp.authn.flows= Password|WSSSAML2".

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.

>Currently I also have this flow defaulted on the Liberty.SSOS profile configuration in system/conf/relying-party-system.xml via the authenticationFlows property.  Don't know if there is a better way to force this to run for that profile.  But since that is configuration, a deployer could inadvertently change that and screw things up in a relying party override.

Theoretically, but I'm more bothered that it has to be in idp.authn.flows, so I should look into that.

>Maybe those aren't deal breakers, but they do seem like warts.  Are there any ideas for making this more transparent and internal to the flow, without requiring user config?

See above, I think that would do it, given that we should be able to add the new login flow to the config file(s) in 3.2. People would have to add it that have earlier versions, but that's a fairly minor thing.

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

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

-- Scott