MessageHandlers and SOAP faults

[Brent Putman]

On 6/13/15 1:21 PM, Cantor, Scott wrote:
>
>>  What's the reason or use case for *not* wanting to send the FaultString (much less the Detail) if that's what the Fault emitter wanted? 
> Just the general requirement to be able to mask any detailed information that might have security implications.

Obviously I agree with the underlying sentiment, but on what basis
would the AddSOAPFault - or really the predicate injected into it -
really be able to make that determination?  Vs. the thing that
generated the Fault in the first place.  Since the predicate doesn't
actually evaluate the candidate fault message, it can only work an as a
general/global flag, all-or-nothing.


>
>> Yes, that is actually the other problem I see with the AddSOAPFault approach, hence my initial comments about the generics.  The way I always envisioned SOAP fault handling to work (or any error handling pipeline where the error message type wasn't the same as the "regular" message type) was via a dedicated outbound pipeline.  That was the point behind the stuff I put into messaging-api, package org.opensaml.messaging.error.
> I don't remember ever seeing any of that code.

It predated most or all of what became the IdP, esp use of SWF.  So
we've never used.  But it was part of my conceptual model when I was
designing the messaging stuff.



>
> If you want to rewrite these flows, I guess all I can say is you're welcome to do that, they're virtually all implementation classes and system flows. There's nothing inherently fixed about any of it, which is very deliberate.

I haven't looked at them in detail yet, so I don't know whether it's
important or not.

However, I was thinking more about what you said re: some actions
assuming that the outbound message type was an Envelope.  Those might
be a problem, esp if we need to compose those with the newer actions
for the delegation flow.  Can you off-hand give me any examples, or
point me to package names, etc?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150613/4f2762b7/attachment.html>