[Apiman-dev] Apiman - WS Security policy

[Eric Wittmann]

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 at redhat.com
>> <mailto:eric.wittmann at 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 at redhat.com
>>> <mailto:eric.wittmann at redhat.com>
>>> <mailto:eric.wittmann at 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 at lists.jboss.org <mailto:Apiman-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/apiman-dev
>