
<html>

  <head>


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

  </head>

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

    Probably mostly for Scott...<br>

    <br>

    Working on the WS-Security SAML Assertion token validation

    MessageHandler.<br>

    <br>

    I'm still trying to fully grok how all the flows and event stuff

    works in the IdP.  But I think I get that the idea for this so far

    is that the AddSOAPFault action is extracting info via the injected

    functions and building the Fault.<br>

    <br>

    The issue I see is that the default FaultCodeMappingFunction is

    really profile-centric and based on the use of EventContext.  I

    don't think that a stricly implemented MessageHandler can make use

    of that from a dependency point of view - that's in profile-api and

    I generally see that as strictly off-limits for the message-oriented

    SOAP stuff. (The SAML Assertion one technically *could* b/c it's in

    saml-impl, but I don't think it's right).<br>

    <br>

    So I suppose one could inject a different impl of

    Function<ProfileRequestContext,QName> there and also a

    Function<ProfileRequestContext,String> for the fault string. 

    I note though that that approach doesn't allow the Fault emitter to

    specify the full range of Fault data, like FaultActor and Detail.<br>

    <br>

    The way I did it in the delegation extension was to have the

    fault-emitting code store an actual Fault object in a message

    subcontext, and then something later pulls it out.  Can you see any

    reason not to augment the AddSOAPFault action with an additional

    Function<ProfileRequestContext,Fault>, which if non-null and

    it produces anything, bypasses the rest?  Or is there a better way?<br>

    <br>

    Also, I'm just noticing: I think there's some generics issues with

    some of this.  We don't see it because it's all Spring and

    reflection.  But for example in AddSOAPFault, I see:<br>

    <br>

    <tt>profileRequestContext.setOutboundMessageContext(new

      MessageContext<Fault>());</tt><br>

    <br>

    Since the PRC ought to be generically parameterized with an

    OutboundMessageType (that certainly isn't going to be a Fault, for a

    SAML flow it would likely be SAMLObject or even more specific), that

    really isn't kosher.  It only works b/c the AddSOAPFault action

    doesn't even declare generic parameters, which I think is probably

    wrong, since its abstract class does.  Wondering whether all our

    actions are like that.  Anyway, with careful wiring it doesn't

    actually break I guess, it's just perhaps unsettling...<br>

  </body>

</html>