On Mar 28, 2016, at 11:37 AM, Eric Wittmann <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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-dev