cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@gmail.com>
Subject Re: WSRM in combination with WS-Security: timestamp problem
Date Mon, 04 Mar 2013 11:20:50 GMT
2013/3/1 John Li <john@mycubes.nl>:
> Hello Aki,
>
> I just created an issue for this problem: cxf-4866. Thanks!
>
> I have an additional issue with the usage of WSRM. Non-repudiation is an
> important security topic as well. By reading the specification, it seems
> that the element signatureConfirmation is an answer to this requirement.
> But it requires a response from the server. For this reason, we did a
> blocking call with WSRM support added but we run into the following issue.
>
> If the Source application fires a blocking call, it will wait for response
> from the server. Now in the case that the message was lost, WSRM will
> retransmit the message but the Source application is directly getting an
> error back from the RMS. This means that to the Source application it seems
> that the call failed but the WSRM retransmit actually was successful. I am
> wondering if this is by design or is this actually an bug?

Hi John,
This is an interesting question. The use of signatureConfirmation in
WS-RM may only work in some specific cases.
I am not sure about your statement. What is exactly the call pattern
that you are using? Could it be that you are using a request-response
call with a synchronous anonymous response endpoint? If you use a
oneway call with a synchronous anonymous endpoint ack (i.e., each ack
returned in the http response per call), this combination may work.
That means, the signatureConfirmation is attached to each ack that
confirms the delivery of the original request as well as its signature
integrity.
Does this make sense?
thanks.
regards, aki


>
> On application level, this inconsistency can cause lots of problems. But if
> we only do non-blocking calls with WSRM, it seems that we cannot use the
> signatureConfirmation element since it is provided through the response of
> the original message.
>
> Any insight on this would be very much appreciated!
>
> With kind regards,
> John
>
>
>
> On Thu, Feb 28, 2013 at 4:30 PM, Aki Yoshida <elakito@gmail.com> wrote:
>
>> Hi John,
>> there was some discussion on this topic at dev@cxf some years ago. But
>> there seems to be no jira ticket about it.
>> So if you can create one, that would be great.
>>
>> Thanks.
>> Regards, aki
>>
>> 2013/2/28 John Li <john@mycubes.nl>:
>> > Hi Aki,
>> >
>> > Since it's a known limitation, is there maybe already an CXF issue that
>> we
>> > can follow to keep track of the progress? It's great to hear that you
>> have
>> > a clear view on how to solve the issue. This issue is an important
>> blocker
>> > since for example the european standards mandates a reliable profile
>> where
>> > timestamps are required. This would mean that the cxf framework at the
>> > current moment cannot be used for those implementations.
>> >
>> > If there is anything you can see that I can help with the implementation,
>> > just let me know. I will do my best.
>> >
>> > Regards,
>> > John
>> >
>> >
>> >
>> > On Thu, Feb 28, 2013 at 11:28 AM, Aki Yoshida <elakito@gmail.com> wrote:
>> >
>> >> 2013/2/28 John Li <john@mycubes.nl>:
>> >> > Hi all,
>> >> >
>> >> > I have been working with the WSRM implementation of Apache CXF and
now
>> >> I'm
>> >> > combining it with WS-Security. After a struggle the createSequence
>> call
>> >> is
>> >> > successfully finished with WS-Security added but I am running into
a
>> >> > problem with the retransmission. If no acknowledgement is received,
>> the
>> >> RMS
>> >> > is retransmitting the message with the same timestamp which is causing
>> >> > WS-Security to throw an error regarding a replay attack.
>> >> >
>> >> > After looking through the internet a bit I found the following post
>> >> > describing exactly the problem that I run into now and how it is
>> solved
>> >> in
>> >> > Axis2/Sandasha2/Rampart combination (http://wso2.org/library/1027).
>> >> >
>> >> > Then I found the following post on the net where Dennis mentions this
>> >> > problem to Aki (
>> >> >
>> >>
>> http://mail-archives.apache.org/mod_mbox/cxf-users/201103.mbox/%3C7b229db0-0865-47ec-8efe-2058b5808177@default%3E
>> >> > )
>> >> > 'There are some deeper issues here around the way messages are
>> persisted.
>> >> >
>> >> > Right now the message is just captured as sent on the wire. This works
>> >> > fine for plain messages, but once you add in WS-Security the handling
>> >> > needs to change so that the security information (timestamps, in
>> >> > particular) can be updated for each retransmission. That's going to
>> >> > require intercepting the message at a different point in the
>> processing,
>> >> > and persisting in a different form.'
>> >> >
>> >> > In the documentation I found the following statement regarding the
>> >> control
>> >> > that we have on the order of interceptors.
>> >> > 'The RetransmissionIntercepor will be added on the fly by the
>> >> > RMOutInterceptor so need not appear in your configuration file.'
>> >> >
>> >> > Can maybe someone help me define if this issue has been sovled or
>> >> addressed
>> >> > in a CXF issue? Or is there some way to force the retransmission
>> >> > interceptor to go through the signing face again without creating
>> >> multiple
>> >> > signature elements like what the Axis2 solution had?
>> >>
>> >>
>> >> Hi John,
>> >> this is a known limitation for the current WS-RM implementation. To
>> >> solve this, we need to split the current processing chain in two parts
>> >> so that we persist the plain message with the rm-props in the first
>> >> part and in the second part, we perform the rest of the processing
>> >> that includes an optional ws-sec processing and the final message
>> >> serialization and transmission. I was working on this some time ago
>> >> along with another change in the inbound side but somehow I was
>> >> interrupted with other stuff.
>> >>
>> >> A related limitation that could be solved with this change is the
>> >> create-sequence's transmission error handling. Currently, you get an
>> >> exception when the create sequence message fails. For some
>> >> applications, it would be nice to have this message also queued and
>> >> retried so that the application does not need to handle this situation
>> >> using its own queuing.
>> >>
>> >> I'll try to close some of the things that I have next week.
>> >>
>> >> Regards, aki
>> >> >
>> >> > Any help is greatly appreciated. Many thanks in advance.
>> >> >
>> >> > With kind regards,
>> >> > John
>> >>
>>

Mime
View raw message