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