Yup, I agree. That would probably be best, since several validators (wss4j
for example) require DOM Elements (javax.xml.soap.SOAPHeader) to function.
Best regards,
Benjamin
2016-03-28 19:14 GMT+02:00 Eric Wittmann <eric.wittmann(a)redhat.com>:
Thanks! In that case, making the headers available as DOM Element
objects
(perhaps with a simple QName based lookup) would be best.
-Eric
On 3/28/2016 12:39 PM, Keith Babo wrote:
> SOAP:Headers can be complex types. WS-Security is a good example of
> this in practice.
>
> ~ keith
>
> On Mar 28, 2016, at 11:37 AM, Eric Wittmann <eric.wittmann(a)redhat.com
>> <mailto:eric.wittmann@redhat.com>> wrote:
>>
>> That's a bit hacky, but also sort of a genius approach as well. I'm
>> actually a little bummed I didn't think of it. :)
>>
>> As for extending SOAP support - I was thinking that I could make the
>> relevant changes to apiman if you would be willing to provide
>> feedback/guidance/testing. My SOAP expertise is quite stale at this
>> point, so having some eyeballs on these changes would be very useful.
>>
>> To start off with, what pieces of the SOAP envelope should be extracted
>> prior to calling the policy chain? Some candidates are:
>>
>> * The encoding style
>> * All SOAP headers
>> * SOAPAction (already available as an HTTP header)
>> * ???
>>
>> For the soap headers, all of the examples I've seen take the following
>> form:
>>
>> <HeaderName xmlns="elementNS">Header-Value</HeaderName>
>>
>> It can also have the optional "actor" or "mustUnderstand"
attributes.
>> The SOAP envelope schema is pretty lax though, so I'm not sure if the
>> above is a convention or a rule. Can headers be more complex than the
>> above?
>>
>> -Eric
>>
>> On 3/26/2016 7:06 AM, Benjamin Kastelic wrote:
>>
>>> Hi,
>>>
>>> I temporarily solved the problem by storing the request body, which is
>>> contained in ApiRequest.rawRequest object, in a temporary buffer. I then
>>> process the data (authentication) and based on the results proceed with
>>> the policy chain or report a failure. Then in the end() method of the
>>> requestDataHandler method I write the contents of my temporary buffer
>>> using super.write(IApimanBuffer). That way I can forward the request to
>>> then ext policy in the chain. But this is still a hacky way of doing
>>> this.
>>>
>>> I would be glad to help with extending SOAP support. But I would need a
>>> few pointers where to start. The way of storing SOAP headers in the
>>> ApiRequest object seems like a good idea.
>>>
>>> 2016-03-24 18:40 GMT+01:00 Eric Wittmann <eric.wittmann(a)redhat.com
>>> <mailto:eric.wittmann@redhat.com>
>>> <mailto:eric.wittmann@redhat.com>>:
>>>
>>> Hi Benjamin - thanks for the excellent question. I will do my best
>>> to answer and note that I am CC'ing the apiman-dev mailing list so
>>> others can chime in.
>>>
>>> First let me say that a WS-Security policy sounds great - we haven't
>>> focused much on the WS-* protocols because we get much more demand
>>> for managing REST APIs than SOAP APIs. That said, better SOAP
>>> support is certainly on the radar. When that happens, my hope is
>>> that processing the envelope might be a core part of the gateway and
>>> so implementing policies that use information in there will be
>>> easier. Perhaps your implementation can be the genesis of some of
>>> that work!
>>>
>>> To your question - without core changes to apiman, the approach you
>>> *need* to take is to have your policy implement IDataPolicy. I
>>> believe you may have already tried that, and observed that you
>>> cannot send proper policy failures from that method. You are right
>>> - that's something we will need to fix! I think you should be able
>>> to throw a runtime exception from the write(IApimanBuffer chunk)
>>> method if you detect an error. However, this is a little bit hacky!
>>>
>>> Instead, I suggest (if you're up for it) that we perhaps work
>>> together to bake SOAP support directly into the core of apiman, such
>>> that the SOAP envelope is read/parsed *before* the policy chain is
>>> executed. We could expose, for example, the SOAP headers as a
>>> proper Map<> stored either in the context or on the ApiRequest.
>>> This would allow you to properly implement most (all?) WS-*
>>> protocols as proper apiman policies in the apply(ApiRequest request)
>>> method.
>>>
>>> Thoughts?
>>>
>>> -Eric
>>>
>>>
>>> On 3/24/2016 7:58 AM, Benjamin Kastelic wrote:
>>>
>>> Greetings,
>>>
>>> I first thought to write this question as an issue on Github,
>>> but it
>>> seemed better to write you a direct email.
>>>
>>> I am making a custom WS Security policy, that reads the body and
>>> check
>>> the UsernameToken security header. This works OK, but now I've
>>> hit a wall.
>>>
>>> In the doApply method I get the rawRequest object and read the
>>> body from
>>> the ServletInputStream of the request. The problem I'm facing
>>> now is
>>> that the input stream was read and it can't be reset back to
it's
>>> initial state.
>>>
>>> I was also trying to implement the same logic in the
>>> requestDataHandler
>>> method, but I don't know if it is even possible to send a failure
>>> message to the request chain from there.
>>>
>>> Any suggesstions ?
>>>
>>> Best regards,
>>> Benjamin
>>>
>>>
>>>
>>>
>>> --
>>> Lp, Benjamin
>>>
>> _______________________________________________
>> Apiman-dev mailing list
>> Apiman-dev(a)lists.jboss.org <mailto:Apiman-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/apiman-dev
>>
>
>