<div dir="ltr">Thanks, I will definitely keep tabs on your progress :)</div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-30 16:02 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Note, here are a couple of JIRA issues created for these features in case you're interested in tracking our progress on them:<br>
<br>
<a href="https://issues.jboss.org/browse/APIMAN-1072" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/APIMAN-1072</a><br>
<a href="https://issues.jboss.org/browse/APIMAN-1077" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/APIMAN-1077</a><span class=""><br>
<br>
-Eric<br>
<br>
On 3/30/2016 4:26 AM, Benjamin Kastelic wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Just one more thing ...<br>
If a SOAP API is published on Apiman and you request the WSDL by using<br>
the gateway endpoint URL, you get the original WSDL - address is<br>
pointing to the real endpoint URL and not the gateway endpoint URL.<br>
I have solved this temporarily by adding URL rewrite policies to all<br>
SOAP APIs, which replace the real endpoint URL with the gateway endpoint<br>
URL.<br>
I guess it would be best if this policy was handled by the gateway<br>
internally so that you wouldn't have to worry by adding a correct policy<br>
to the API configuration.<br>
<br>
2016-03-29 20:29 GMT+02:00 Benjamin Kastelic<br></span>
<<a href="mailto:kastelic.benjamin@gmail.com" target="_blank">kastelic.benjamin@gmail.com</a> <mailto:<a href="mailto:kastelic.benjamin@gmail.com" target="_blank">kastelic.benjamin@gmail.com</a>>>:<span class=""><br>
<br>
OK, now I understand what you meant.<br>
I believe this would be a reasonable solution :)<br>
<br>
2016-03-29 20:18 GMT+02:00 Eric Wittmann <<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a><br></span>
<mailto:<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a>>>:<span class=""><br>
<br>
My plan was unclear! Let's go with another example:<br>
<br>
Step 1 - the Gateway receives the following HTTP request:<br>
<br>
----<br>
POST /apiman-gateway/MyOrg/soap-api/2.7 HTTP/1.1<br></span>
Host: <a href="http://www.example.org" rel="noreferrer" target="_blank">www.example.org</a> <<a href="http://www.example.org" rel="noreferrer" target="_blank">http://www.example.org</a>><div><div class="h5"><br>
Content-Type: application/soap+xml; charset=utf-8<br>
X-API-Key: API-KEY-FOR-ACTIVE-CLIENT<br>
SOAPAction: ExampleAction<br>
<br>
<?xml version="1.0"?><br>
<soap:Envelope xmlns:soap="<a href="http://www.w3.org/2003/05/soap-envelope" rel="noreferrer" target="_blank">http://www.w3.org/2003/05/soap-envelope</a>"><br>
<soap:Header><br>
<ns1:Header1 xmlns:ns1="uri:ns1">foo</ns1:Header1><br>
<ns2:Header2 xmlns:ns2="uri:ns2">bar</ns2:Header2><br>
</soap:Header><br>
<soap:Body><br>
<m:GetStockPrice xmlns:m="<a href="http://www.example.org/stock/RHT" rel="noreferrer" target="_blank">http://www.example.org/stock/RHT</a>"><br>
<m:StockName>Red Hat</m:StockName><br>
</m:GetStockPrice><br>
</soap:Body><br>
</soap:Envelope><br>
----<br>
<br>
We'll parse the first part of the envelope so that we can read<br>
the headers and make them available to any policies. After<br>
that's done, we'll invoke the policy chain as per normal.<br>
However, because it's a SOAP api, there will exist a<br>
SOAPRequestInfo object in the policy context. So policies can<br>
read and/or modify the soap information. This class might look<br>
something like this:<br>
<br>
public class SOAPRequestInfo {<br>
private String action;<br>
private String encoding;<br>
private Map<QName, SOAPHeader> headers;<br>
}<br>
<br>
This allows interested policies (like your ws-security) policy<br>
to have easy access to all the soap related stuff. It also<br>
allows you to alter these things. Including<br>
adding/removing/modifying the SOAP headers.<br>
<br>
So let's assume that we have a policy which *adds* a SOAP header<br>
(ns3:AddedHeader) and another policy which *removes* one<br>
(ns2:Header2). The policy code might look like this:<br>
<br>
SOAPRequestInfo soapInfo = context.getAttribute(<br>
Constants.SOAP_INFO, (SOAPRequestInfo) null);<br>
soapInfo.getHeaders().remove(new QName("uri:ns2", "Header2"));<br>
soapInfo.getHeaders().put(<br>
new QName("uri:ns3", "AddedHeader"),<br>
createSoapHeader()<br>
);<br>
<br>
<br>
In that case, this is the HTTP request that will be sent/proxied<br>
to the back-end API:<br>
<br>
----<br>
POST / HTTP/1.1<br></div></div>
Host: <a href="http://www.example.org" rel="noreferrer" target="_blank">www.example.org</a> <<a href="http://www.example.org" rel="noreferrer" target="_blank">http://www.example.org</a>><span class=""><br>
Content-Type: application/soap+xml; charset=utf-8<br>
SOAPAction: ExampleAction<br>
<br>
<?xml version="1.0"?><br>
<soap:Envelope xmlns:soap="<a href="http://www.w3.org/2003/05/soap-envelope" rel="noreferrer" target="_blank">http://www.w3.org/2003/05/soap-envelope</a>"><br>
<soap:Header><br>
<ns1:Header1 xmlns:ns1="uri:ns1">foo</ns1:Header1><br>
<ns3:AddedHeader xmlns:ns3="uri:ns3">bar</ns3:AddedHeader><br>
</soap:Header><br>
<soap:Body><br>
<m:GetStockPrice xmlns:m="<a href="http://www.example.org/stock/RHT" rel="noreferrer" target="_blank">http://www.example.org/stock/RHT</a>"><br>
<m:StockName>Red Hat</m:StockName><br>
</m:GetStockPrice><br>
</soap:Body><br>
</soap:Envelope><br>
----<br>
<br>
Sound reasonable?<br>
<br>
-Eric<br>
<br>
<br>
On 3/29/2016 1:42 PM, Benjamin Kastelic wrote:<br>
<br>
If I understand you correctly Eric, only the soap:Body part<br>
will be<br>
forwarded to the registered API?<br>
What if the API still needs to receive the soap:Header part?<br>
<br>
2016-03-29 15:34 GMT+02:00 Keith Babo <<a href="mailto:kbabo@redhat.com" target="_blank">kbabo@redhat.com</a><br>
<mailto:<a href="mailto:kbabo@redhat.com" target="_blank">kbabo@redhat.com</a>><br></span>
<mailto:<a href="mailto:kbabo@redhat.com" target="_blank">kbabo@redhat.com</a> <mailto:<a href="mailto:kbabo@redhat.com" target="_blank">kbabo@redhat.com</a>>>>:<span class=""><br>
<br>
Sounds cool to me. Header policy will need to be QName and<br>
DOM-aware, so that namespace-qualified headers can be<br>
added and<br>
appropriate namespace definitions can be added to the<br>
DOM if<br>
required. Of course you already know all this, but<br>
pointing it out<br>
makes me feel useful.<br>
<br>
> On Mar 29, 2016, at 8:38 AM, Eric Wittmann<br>
<<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></span><span class="">
<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>>>> wrote:<br>
><br></span><div><div class="h5">
> That's an interesting idea. It'd be harder to<br>
inject the headers<br>
into the request than it is to inject HTTP request headers,<br>
obviously. But not impossible. We'd need to be aware<br>
of the change<br>
to any Content-Length that may be set.<br>
><br>
> This makes the implementation slightly more<br>
complicated, because<br>
I think the HTTP connector will need to be made smarter<br>
(it will<br>
need to send the <soap:Envelope> and <soap:Header><br>
sections first,<br>
then just stream the remaining request body as-is.<br>
><br>
> So perhaps what we have is this:<br>
><br>
> 1. <?xml version="1.0"?><br>
> 2. <soap:Envelope<br>
xmlns:soap="<a href="http://www.w3.org/2003/05/soap-envelope" rel="noreferrer" target="_blank">http://www.w3.org/2003/05/soap-envelope</a>"><br>
> 3. <soap:Header><br>
> 4. <ns1:Foo actor="..."<br>
xmlns:ns1="uri:ns1">BAR</ns1:Foo><br>
> 5. </soap:Header><br>
> 6. <soap:Body><br>
> 7. <m:GetStockPrice<br>
xmlns:m="<a href="http://www.example.org/stock/Surya" rel="noreferrer" target="_blank">http://www.example.org/stock/Surya</a>"><br>
> 8. <m:StockName>IBM</m:StockName><br>
> 9. </m:GetStockPrice><br>
> 10. </soap:Body><br>
> 11. </soap:Envelope><br>
><br>
> Lines 1-5 will be read and consumed by apiman<br>
*before* any<br>
policies are executed. We'll actually keep reading<br>
until we find<br>
<soap:Body> in the request body. We'll throw out<br>
everything before<br>
line #6 from our in-memory buffer, resulting in a<br>
buffer with just<br>
line #6 (and any extra bytes after that based on our<br>
I/O chunk size).<br>
><br>
> The policies will be executed, which may result in<br>
soap headers<br>
being added, modified, or removed. If all policies<br>
pass, then we<br>
proxy the request to the back-end. Normally the HTTP<br>
connection<br>
would simply send all bytes from the HTTP request<br>
as-is. Instead,<br>
we'll need to *generate* new content for lines 1-5,<br>
with the newly<br>
modified soap headers. Once the generated content is<br>
sent, then we<br>
send the contents of the in-memory buffer (which<br>
contains line #6+<br>
any additional bytes). After that, we proxy the<br>
remaining bytes<br>
from the HTTP request as-is.<br>
><br>
> This may be starting to take shape. :)<br>
><br>
> Additional thoughts?<br>
><br>
> -Eric<br>
><br>
> PS: @Keith - we'll likely have a separate Policy for<br>
manipulating SOAP headers, rather than re-use the<br>
existing HTTP<br>
headers policy.<br>
><br>
> On 3/29/2016 8:13 AM, Keith Babo wrote:<br>
>> Sounds like a reasonable first step to me. Just to<br>
make life<br>
slightly<br>
>> more complicated, will the headers policy be<br>
updated to allow<br>
add/remove<br>
>> of SOAP:Headers? :-)<br>
>><br>
>> ~ keith<br>
>><br>
>>> On Mar 29, 2016, at 7:52 AM, Eric Wittmann<br>
<<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>
<mailto:<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a>>><br></div></div><span class="">
>>> <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>
<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>>>>> wrote:<br>
>>><br></span><div><div class="h5">
>>> OK so here's what I propose (feedback welcome):<br>
>>><br>
>>> *If* an API's 'type' is set to SOAP, then we will<br>
*always* look<br>
for a<br>
>>> soap envelope in the body. If no body is found or<br>
no soap<br>
envelope is<br>
>>> found in the body, then a standard apiman error<br>
will be thrown.<br>
>>><br>
>>> If an envelope *is* found, then we will read the<br>
body of the HTTP<br>
>>> request until we find "<soap:Body>". We'll<br>
extract the<br>
<soap:Header><br>
>>> and parse its children. While parsing, we'll<br>
obviously keep<br>
the data<br>
>>> we read in a memory buffer. Once parsing is done,<br>
we'll<br>
include the<br>
>>> soap headers, soap action, and the global encoding<br>
type in some<br>
sort<br>
>>> of soapinfo object and include that in the policy<br>
context.<br>
>>><br>
>>> Finally, after all that is done, we'll process the<br>
request as<br>
normal,<br>
>>> executing the policy chain, then processing the<br>
request body,<br>
etc. The<br>
>>> entire request payload will still be processed<br>
(remember that<br>
we saved<br>
>>> the bytes we read in a memory buffer).<br>
>>><br>
>>> So from the perspective of a policy, everything<br>
will look identical<br>
>>> except that a SOAPInfo object will be available in<br>
the policy<br>
context.<br>
>>><br>
>>> Thoughts?<br>
>>><br>
>>> -Eric<br>
>>><br>
>>> On 3/28/2016 1:48 PM, Benjamin Kastelic wrote:<br>
>>>> Yup, I agree. That would probably be best, since<br>
several<br>
validators<br>
>>>> (wss4j for example) require DOM Elements<br>
(javax.xml.soap.SOAPHeader) to<br>
>>>> function.<br>
>>>><br>
>>>> Best regards,<br>
>>>> Benjamin<br>
>>>><br>
>>>> 2016-03-28 19:14 GMT+02:00 Eric Wittmann<br>
<<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>
<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>
<mailto:<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a>><br></div></div><div><div class="h5">
<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>
>>>> <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>
<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>
>>>> Thanks! In that case, making the headers<br>
available as DOM<br>
Element<br>
>>>> objects (perhaps with a simple QName based<br>
lookup) would be<br>
best.<br>
>>>><br>
>>>> -Eric<br>
>>>><br>
>>>> On 3/28/2016 12:39 PM, Keith Babo wrote:<br>
>>>><br>
>>>> SOAP:Headers can be complex types.<br>
WS-Security is a good<br>
>>>> example of<br>
>>>> this in practice.<br>
>>>><br>
>>>> ~ keith<br>
>>>><br>
>>>> On Mar 28, 2016, at 11:37 AM, Eric Wittmann<br>
>>>> <<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>
<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>
<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>
<mailto:<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a>>>><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></div></div><div><div class="h5">
<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>
>>>> <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>
<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>
>>>> <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>
<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>>>>>> wrote:<br>
>>>><br>
>>>> That's a bit hacky, but also sort of a<br>
genius<br>
approach as<br>
>>>> well. I'm<br>
>>>> actually a little bummed I didn't think<br>
of it. :)<br>
>>>><br>
>>>> As for extending SOAP support - I was<br>
thinking that<br>
I could<br>
>>>> make the<br>
>>>> relevant changes to apiman if you would<br>
be willing<br>
to provide<br>
>>>> feedback/guidance/testing. My SOAP<br>
expertise is<br>
quite stale<br>
>>>> at this<br>
>>>> point, so having some eyeballs on these<br>
changes would be<br>
>>>> very useful.<br>
>>>><br>
>>>> To start off with, what pieces of the<br>
SOAP envelope<br>
should<br>
>>>> be extracted<br>
>>>> prior to calling the policy chain?<br>
Some candidates are:<br>
>>>><br>
>>>> * The encoding style<br>
>>>> * All SOAP headers<br>
>>>> * SOAPAction (already available as an<br>
HTTP header)<br>
>>>> * ???<br>
>>>><br>
>>>> For the soap headers, all of the<br>
examples I've seen<br>
take the<br>
>>>> following<br>
>>>> form:<br>
>>>><br>
>>>> <HeaderName<br>
xmlns="elementNS">Header-Value</HeaderName><br>
>>>><br>
>>>> It can also have the optional "actor" or<br>
"mustUnderstand"<br>
>>>> attributes.<br>
>>>> The SOAP envelope schema is pretty lax<br>
though, so<br>
I'm not<br>
>>>> sure if the<br>
>>>> above is a convention or a rule. Can<br>
headers be more<br>
>>>> complex than the<br>
>>>> above?<br>
>>>><br>
>>>> -Eric<br>
>>>><br>
>>>> On 3/26/2016 7:06 AM, Benjamin Kastelic<br>
wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> I temporarily solved the problem by<br>
storing the<br>
request<br>
>>>> body, which is<br>
>>>> contained in ApiRequest.rawRequest<br>
object, in a<br>
>>>> temporary buffer. I then<br>
>>>> process the data (authentication)<br>
and based on the<br>
>>>> results proceed with<br>
>>>> the policy chain or report a<br>
failure. Then in<br>
the end()<br>
>>>> method of the<br>
>>>> requestDataHandler method I write<br>
the contents of my<br>
>>>> temporary buffer<br>
>>>> using super.write(IApimanBuffer).<br>
That way I can<br>
forward<br>
>>>> the request to<br>
>>>> then ext policy in the chain. But<br>
this is still<br>
a hacky<br>
>>>> way of doing<br>
>>>> this.<br>
>>>><br>
>>>> I would be glad to help with<br>
extending SOAP<br>
support. But<br>
>>>> I would need a<br>
>>>> few pointers where to start. The<br>
way of storing SOAP<br>
>>>> headers in the<br>
>>>> ApiRequest object seems like a good<br>
idea.<br>
>>>><br>
>>>> 2016-03-24 18:40 GMT+01:00 Eric<br>
Wittmann<br>
>>>> <<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>
<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>
<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>
<mailto:<a href="mailto:eric.wittmann@redhat.com" target="_blank">eric.wittmann@redhat.com</a>>>><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>
<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>
>>>> <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>
<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>
>>>> <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>
<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>
>>>> <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>
<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>
>>>> <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>
<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<br>
excellent<br>
question. I<br>
>>>> will do my best<br>
>>>> to answer and note that I am<br>
CC'ing the<br>
apiman-dev<br>
>>>> mailing list so<br>
>>>> others can chime in.<br>
>>>><br>
>>>> First let me say that a<br>
WS-Security policy<br>
sounds<br>
>>>> great - we haven't<br>
>>>> focused much on the WS-*<br>
protocols because<br>
we get<br>
>>>> much more demand<br>
>>>> for managing REST APIs than<br>
SOAP APIs. That<br>
said,<br>
>>>> better SOAP<br>
>>>> support is certainly on the<br>
radar. When that<br>
>>>> happens, my hope is<br>
>>>> that processing the envelope<br>
might be a core<br>
part of<br>
>>>> the gateway and<br>
>>>> so implementing policies that<br>
use information in<br>
>>>> there will be<br>
>>>> easier. Perhaps your<br>
implementation can be the<br>
>>>> genesis of some of<br>
>>>> that work!<br>
>>>><br>
>>>> To your question - without core<br>
changes to<br>
apiman,<br>
>>>> the approach you<br>
>>>> *need* to take is to have your<br>
policy implement<br>
>>>> IDataPolicy. I<br>
>>>> believe you may have already<br>
tried that, and<br>
>>>> observed that you<br>
>>>> cannot send proper policy<br>
failures from that<br>
>>>> method. You are right<br>
>>>> - that's something we will need<br>
to fix! I<br>
think you<br>
>>>> should be able<br>
>>>> to throw a runtime exception<br>
from the<br>
>>>> write(IApimanBuffer chunk)<br>
>>>> method if you detect an error.<br>
However,<br>
this is a<br>
>>>> little bit hacky!<br>
>>>><br>
>>>> Instead, I suggest (if you're<br>
up for it) that we<br>
>>>> perhaps work<br>
>>>> together to bake SOAP support<br>
directly into<br>
the core<br>
>>>> of apiman, such<br>
>>>> that the SOAP envelope is<br>
read/parsed<br>
*before* the<br>
>>>> policy chain is<br>
>>>> executed. We could expose, for<br>
example, the<br>
SOAP<br>
>>>> headers as a<br>
>>>> proper Map<> stored either in<br>
the context or<br>
on the<br>
>>>> ApiRequest.<br>
>>>> This would allow you to<br>
properly implement most<br>
>>>> (all?) WS-*<br>
>>>> protocols as proper apiman<br>
policies in the<br>
>>>> apply(ApiRequest request)<br>
>>>> method.<br>
>>>><br>
>>>> Thoughts?<br>
>>>><br>
>>>> -Eric<br>
>>>><br>
>>>><br>
>>>> On 3/24/2016 7:58 AM, Benjamin<br>
Kastelic wrote:<br>
>>>><br>
>>>> Greetings,<br>
>>>><br>
>>>> I first thought to write<br>
this question as an<br>
>>>> issue on Github,<br>
>>>> but it<br>
>>>> seemed better to write you<br>
a direct email.<br>
>>>><br>
>>>> I am making a custom WS<br>
Security policy,<br>
that<br>
>>>> reads the body and<br>
>>>> check<br>
>>>> the UsernameToken security<br>
header. This<br>
works<br>
>>>> OK, but now I've<br>
>>>> hit a wall.<br>
>>>><br>
>>>> In the doApply method I get<br>
the rawRequest<br>
>>>> object and read the<br>
>>>> body from<br>
>>>> the ServletInputStream of<br>
the request. The<br>
>>>> problem I'm facing<br>
>>>> now is<br>
>>>> that the input stream was<br>
read and it<br>
can't be<br>
>>>> reset back to it's<br>
>>>> initial state.<br>
>>>><br>
>>>> I was also trying to<br>
implement the same<br>
logic<br>
>>>> in the<br>
>>>> requestDataHandler<br>
>>>> method, but I don't know if<br>
it is even<br>
possible<br>
>>>> to send a failure<br>
>>>> message to the request<br>
chain from there.<br>
>>>><br>
>>>> Any suggesstions ?<br>
>>>><br>
>>>> Best regards,<br>
>>>> Benjamin<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Lp, Benjamin<br>
>>>><br>
>>>><br>
_______________________________________________<br>
>>>> Apiman-dev mailing list<br>
>>>> <a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a>><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a>>><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a>><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a>>>><br>
>>>> <mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a>><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a>>>><br>
>>>> <mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a>><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a>>><br>
>>>> <mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a>><br>
<mailto:<a href="mailto:Apiman-dev@lists.jboss.org" target="_blank">Apiman-dev@lists.jboss.org</a><br>
<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>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Lp, Benjamin<br>
>><br>
<br>
<br>
<br>
<br>
--<br>
Lp, Benjamin<br>
<br>
<br>
<br>
<br>
--<br>
Lp, Benjamin<br>
<br>
<br>
<br>
<br>
--<br>
Lp, Benjamin<br>
</div></div></blockquote>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Lp, Benjamin</div></div>
</div>