<html>

  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

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

    <br>

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

    <br>

    Then it calls the existing standard 'c14n/saml' subflow to resolve

    the canonical principal name represented by the Assertion.<br>

    <br>

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

    <br>

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

    <br>

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

    <br>

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

    <br>

    <br>

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

    <br>

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

    <br>

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

    <br>

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

    <br>

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

    <br>

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

    <br>

    Thanks,<br>

    Brent<br>

    <br>

    <br>

    <br>

  </body>

</html>