Hi Jim,
I'm looking into some of the property handling now, though mostly around
addressing settings and how those are handled by the RM code. But there
have been a lot of changes in the 3.0 RM implementation, so it would be
great if you could test against trunk and verify that the problem is
still there.
That said, you or Aki would probably know more about how this should be
handled than I do. How would you expect the properties from
bindingProvider::getRequestContext() would be accessed from the RM code?
I'd thought these properties would be copied into the Message when it's
being initialized. If the RM code needs to access them indirectly I can
add that in.
Right now I'm looking into the handling of decoupled endpoints - it
looks like some problems have been introduced lately in that area.
Regards,
- Dennis
On 05/06/2014 12:32 PM, Jim Ma wrote:
Hi Denis,
Is this already in your todo list and going to improve in the future?
Or it's an issue in our ws-rm implementation at the moment we should
take a look ?
Regards,
Jim
On Thu, Apr 24, 2014 at 10:18 PM, Jim Ma <[email protected]
<mailto:[email protected]>> wrote:
HI Dennis,
I tested against 2.7.11 and 2.7.x-fixes. As Aki said, this only
doesn't work when setting these ws-security properties in request
context with standard jaxws api. It works well by spring xml
configuration like what WSRMWithWSSecurityPolicyTest does now.
With spring configuration, these properties are put in
ClientProxyFactoryBean, and can be accessed in the new created RM
message; while setting them in
bindingProvider::getRequestContext() with jaxws api, only the
message in the same context can retrieve these values.
Regards,
Jim
On Thu, Apr 24, 2014 at 8:54 PM, Aki Yoshida <[email protected]
<mailto:[email protected]>> wrote:
Hi Dennis,
a combined scenario of ws-rm + ws-sec works fine in general. (and
there is a test case in systests/ws-rm that Jim mentioned).
But I think Jim is trying to control some of its behavior by
passing
some properties in the client context and that won't work if those
properties are not copied into the new client's context.
regards, aki
2014-04-24 13:28 GMT+02:00 Dennis Sosnoski <[email protected]
<mailto:[email protected]>>:
> Hi Jim,
>
> Which version of the code are you using? I've been working
on combining
> WS-RM and WS-Security in the 3.0 code. There are still some
pieces that need
> to be put in place (especially persisting the security
properties so
> messages can be retransmitted), but the basic security+rm
operation has been
> working for me in my tests.
>
> Regards,
>
> - Dennis
>
> Dennis M. Sosnoski
> Java Web Services Consulting
<http://www.sosnoski.com/consult.html>
> CXF and Web Services Security Training
> <http://www.sosnoski.com/training.html>
> Web Services Jump-Start <http://www.sosnoski.com/jumpstart.html>
>
>
> On 04/24/2014 06:40 PM, Jim Ma wrote:
>>
>> Hi All,
>> When I tried to put all the security configuration
properties in the
>> requestContext and call a service with both RM and security
policy
>> enabled(like the service in WSRMWithWSSecurityPolicyTest) :
>>
bp.getRequestContext().put(SecurityConstants.CALLBACK_HANDLER, new
>> KeystorePasswordCallback());
>>
bp.getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES,,
>> getResource("/META-INF/security-client.properties"));
>> ....
>> This doesn't work as expected and there is exception thrown:
>> Failed to send RM protocol message {
>> http://schemas.xmlsoap.org/ws/2005/02/rm}CreateSequence
<http://schemas.xmlsoap.org/ws/2005/02/rm%7DCreateSequence>.:
>> org.apache.cxf.interceptor.Fault: Security configuration
could not be
>> detected. Potential cause: Make sure jaxws:client element
with name
>> attribute value matching endpoint port is defined as well as a
>> ws-security.signature.properties element within it.
>>
>> After I investigated the code, I saw all these ws-scurity
configuration
>> properties are not copied into the new created message by
RMClient which
>> initialized by RM interceptor.
>> That's the root cause for this failure.
>> I went back to look at jaxws spec about BindingProvider's
requestContext
>> and it's scope. There isn't clue and detail to say if these
properties
>> should be copied into the new created message like RM
message from the
>> message which send out the real payload with user's setting
though
>> requestContext.
>> Do you think we should copy them ? or What can do to
support this easily?
>> Thanks in advance.
>>
>> Jim
>>
>
