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

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

    <br>

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

    <br>

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

    <br>

    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. 

  </body>

</html>