MessageHandlers and SOAP faults

[Brent Putman]

Probably mostly for Scott...

Working on the WS-Security SAML Assertion token validation MessageHandler.

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.

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

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.

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?

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:

profileRequestContext.setOutboundMessageContext(new
MessageContext<Fault>());

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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150611/f50312a3/attachment.html>