Delegation flow: authn and c14n

[Brent Putman]

I've managed to get something working for the authn and c14n aspects of
the Liberty SSOS delegation flow. Wanted to run over some details in
case this is the wrong direction, and also to point out some potential
issues.

What I did so far was to create a simple flow (attached) which just
does some processing on the WS-S SAML 2 Assertion token that had
previously been validated and sets up to c14n the token's NameID.
Essentially all it really does is put the Assertion's NameID into the
Subject NameIDPrincipal.

Then it calls the existing standard 'c14n/saml' subflow to resolve the
canonical principal name represented by the Assertion.

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.

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.

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


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

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.

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?

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.

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

Anyway, with this authn/c14n now flow being at least functional, the
Liberty SSOS flow now successfully processes a request end-to-end. 
There's still some other stuff to do, like policy enforcement and
dealing with quirks of the issued Assertion (cloning the delegated
AuthenticationStatement, reflecting and updating the delgation
condition chain).  But it's coming together.

Thanks,
Brent



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150902/552950b3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wss-saml2-authn-flow.xml
Type: text/xml
Size: 1096 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/dev/attachments/20150902/552950b3/attachment.xml>