TrustEngine refactoring

[Brent Putman]

On 8/20/14 9:26 PM, Cantor, Scott wrote:
>
> That one runs later as the inbound subflow, what used to be the security
> policy. I don't know, does the populate action have to complete before the
> subflow runs? I wouldn't necessarily have thought so but I haven't
> reviewed the changes.

I wouldn't have thought so either.  I thought as long as the populate
action ran before SAMLMDClientCertAuthSecurityHandler, it would be ok,
but apparently not.  At least, the tests failed.  I don't have details
at the moment.

> Which is the first action or handler that relies on the context being
> populated?


AFAIK the only action that needs the client TLS stuff is the
SAMLMDClientCertAuthSecurityHandler.  So I just tried putting the
populate action right before that one in the SOAPSecurityPolicy - which
doesn't really fit b/c it's not a "policy", but I didn't think it
mattered in a technical sense.  I just wanted to see if it would work,
and it didn't.



> We have some options anyway, like attaching a condition predicate that
> checks the binding, or various fun tricks that can be played like defining
> the same bean name in every flow but turning it into a no-op in some of
> them.

Is there a way to "extend" the DecodeMessage action from the abstract
flow, just for the SOAP flows, to effectively append the new action on
the end of the abstract version?  That's what I wanted to do, seemed
semantically cleanest, but wasn't sure how.