Delegation flow: authn and c14n

[Brent Putman]

On 9/2/15 7:26 PM, Cantor, Scott wrote:
>> 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 have tried this alternate approach out and honestly, I think I prefer
this.  The Liberty delegation flow doesn't really need to do
"authentication" as we define it normally for user-facing stuff.  Doing
it this way replaces all the complex parent flow stuff with 2 actions
and a call to the SAML c14n subflow.  I think I'm going to provisionally
check this in, and if this turns out to be a bad idea, we can revisit.

Also like this b/c it avoids all the issues I already noted with the
deployer having to (at least currently) add stuff to user-space config
to make authn work with the authn subsystem.  All the work is internal
to the flow, so user does nothing.

So far so good.  That then leads to: This approach actually works fine
up until you get to the (big, lot of actions) BuildResponse action
state.  It blows up on AddAuthnStatementToAssertion b/c there is in fact
no AuthenticationResult.  At least at a technical level, I think that's
actually OK, because next up on the TODO list was dealing with the
AuthenticationStatement that gets populated.  In the Liberty flow you
don't generate or build it: it is cloned as-is from the inbound
Assertion token processing.  So actually need special processing here
anyway. 

Any problem with this proposed solution:  Add an activation condition to
AddAuthnStatementToAssertion which says "only run if the profile ID IS
NOT the Liberty SSOS one".  And then add a new Action to BuildResponse
which says "only run if the profile IS the Liberty SSOS one".  Is there
a better way?  I briefly thought of adding the special handling right to
AddAuthnStatementToAssertion, but seems simpler to just keep them
separate. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150924/2a371e2e/attachment.html>