You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by John Li <jo...@mycubes.nl> on 2013/02/28 01:15:27 UTC
WSRM in combination with WS-Security: timestamp problem
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?
Any help is greatly appreciated. Many thanks in advance.
With kind regards,
John
Re: WSRM in combination with WS-Security: timestamp problem
Posted by John Li <jo...@mycubes.nl>.
Hi Aki
Definitely an interesting suggestion. What we do now:
- define a oneWayPing call with no response message
- add wsrm
- client installed on tomcat server will fire the oneWayPing call
- createSequence is sent with replyTo en AckTo anonymous
- acknowledgement are retrieved through piggybacking way only
But with this approach, I assumed that the signatureConfirmation approach
is not usefull since there is no response defined for the call.
So instead of this way, I wanted to explore the following pattern:
- define a twoWayPing call so with request and response message
- add WSRM
- client installed on Tomcat server will fire the twoWayPing call
- createSequece is sent with replyTo en AckTo anonymous
- twoPingCall will be sent after createSequence
- twoPingCall will directly respond to the client a success message with
signatureConfirmation and start a internal thread to do the real work (or
better use message queue)
- response will also contain the acknowledgements headers
Now we force a direct response with signatureConfirmation so we can prove
that the unchanged message is accepted by the receiver. The problem is that
if we simulate a failure on the twoWayPing call, the client will directly
get an exception that the message was not sent while WSRM will do
resubmits. The second call is actually successful but the response is not
processed by the source application since the thread is already gone.
>>>That means, the signatureConfirmation is attached to each ack that
confirms the delivery of the original request as well as its signature
integrity.
But nothing is forcing the server to always add an Ack to the response
message right? It depends on the configuration and different
implementations if they always directly respond with an ack header. I have
configured my acknowledgement interval to be sent every 2 seconds so
actually the acknowledgement of message1 is returned when the response of
message2 is sent. Or am I missing something on this?
I hope my explanation is still making a bit sense.....
With kind regards,
John
On Mon, Mar 4, 2013 at 12:20 PM, Aki Yoshida <el...@gmail.com> wrote:
> 2013/3/1 John Li <jo...@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 <el...@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 <jo...@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 <el...@gmail.com>
> wrote:
> >> >
> >> >> 2013/2/28 John Li <jo...@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
> >> >>
> >>
>
Re: WSRM in combination with WS-Security: timestamp problem
Posted by Aki Yoshida <el...@gmail.com>.
2013/3/1 John Li <jo...@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 <el...@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 <jo...@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 <el...@gmail.com> wrote:
>> >
>> >> 2013/2/28 John Li <jo...@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
>> >>
>>
Re: WSRM in combination with WS-Security: timestamp problem
Posted by John Li <jo...@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?
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 <el...@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 <jo...@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 <el...@gmail.com> wrote:
> >
> >> 2013/2/28 John Li <jo...@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
> >>
>
Re: WSRM in combination with WS-Security: timestamp problem
Posted by Aki Yoshida <el...@gmail.com>.
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 <jo...@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 <el...@gmail.com> wrote:
>
>> 2013/2/28 John Li <jo...@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
>>
Re: WSRM in combination with WS-Security: timestamp problem
Posted by John Li <jo...@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 <el...@gmail.com> wrote:
> 2013/2/28 John Li <jo...@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
>
Re: WSRM in combination with WS-Security: timestamp problem
Posted by Aki Yoshida <el...@gmail.com>.
2013/2/28 John Li <jo...@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
Re: WSRM in combination with WS-Security: timestamp problem
Posted by John Li <jo...@mycubes.nl>.
Hi all,
Sorry for my late response. Not sure if the problem is still actual but
responding on it anyway.
I must say I can't completely recall which issues I exactly ran into while
combining the ws-rm and ws-security standards since it has been a while.
As far as I remember we ran into the following issues:
- receiving end of the ws-rm messages was only expecting the signing and
encryption of the 'real' message and not the ws-rm lifecycle messages.
Solved it by adding the filters in the bus configuration so it would affect
all messages going out or in.
- add support for signatureConfirmation in the response for non-repudiation
- replay-attack due to retries (temporary solved by setting Acknowledgement
interval to 0. The return message then will contain the acknowledgeheaders
as well)
- inorder combined with exactlyOnce and using solely piggybacking as
acknowledgement mechanism is causing an endless loop of retransmissions
until a new message (so not a retransmitted one) is sent to the server.
reason is that the exactlyOnce is cause a soapfault for retransmitted
messages but it contains no acknowledgement headers. Possible ways to solve
this is using a public acksTo address (so not anonymous) or combining it
with ws-makeConnection (not tested).
But I agree with Dennis that the issue described by Carlos seems more like
a configuration issue. I didn't run into this while doing the tests. I also
didn't use jaxws client but I used the simple frontend client proxy to get
a client instance. Maybe that's the reason why I didn't ran into the same
issues.
Hope it helps.
regards,
John
On Tue, Jul 16, 2013 at 11:06 PM, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Perhaps John can tell you what he did to get it working. I'll check into
> that myself next week.
>
> Thanks,
>
> - Dennis
>
>
> On 07/16/2013 11:54 PM, Carlos Aza wrote:
>
>> Hello,
>>
>> Thank you for your response.
>>
>> John said in his very first comment "After a struggle the createSequence
>> call is
>> successfully finished with WS-Security added". I think his original
>> problems
>> where the same as I am having right now. Maybe I should open a new thread
>> to
>> treat the problems of sending the createSequence message when ws-security
>> is
>> enabled. Should I?
>>
>> Thank you,
>> Carlos
>>
>>
>>
>> --
>> View this message in context: http://cxf.547215.n5.nabble.**
>> com/WSRM-in-combination-with-**WS-Security-timestamp-problem-**
>> tp5723872p5730910.html<http://cxf.547215.n5.nabble.com/WSRM-in-combination-with-WS-Security-timestamp-problem-tp5723872p5730910.html>
>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>
>>
>
Re: WSRM in combination with WS-Security: timestamp problem
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Perhaps John can tell you what he did to get it working. I'll check into
that myself next week.
Thanks,
- Dennis
On 07/16/2013 11:54 PM, Carlos Aza wrote:
> Hello,
>
> Thank you for your response.
>
> John said in his very first comment "After a struggle the createSequence
> call is
> successfully finished with WS-Security added". I think his original problems
> where the same as I am having right now. Maybe I should open a new thread to
> treat the problems of sending the createSequence message when ws-security is
> enabled. Should I?
>
> Thank you,
> Carlos
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/WSRM-in-combination-with-WS-Security-timestamp-problem-tp5723872p5730910.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
Re: WSRM in combination with WS-Security: timestamp problem
Posted by Carlos Aza <ca...@indra.es>.
Hello,
Thank you for your response.
John said in his very first comment "After a struggle the createSequence
call is
successfully finished with WS-Security added". I think his original problems
where the same as I am having right now. Maybe I should open a new thread to
treat the problems of sending the createSequence message when ws-security is
enabled. Should I?
Thank you,
Carlos
--
View this message in context: http://cxf.547215.n5.nabble.com/WSRM-in-combination-with-WS-Security-timestamp-problem-tp5723872p5730910.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: WSRM in combination with WS-Security: timestamp problem
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Although there are problems in using WS-RM and WS-Security together with
the existing code I don't think this is one of them. If you look back to
John's original post, his issue was that the timestamp was not being
updated on retransmissions. This looks like more of a configuration issue.
I'm currently working on some other aspects of WS-RM handling, but
should be getting back into the combination with WS-Security next week.
I'll try out this scenario then to see if I run into this problem.
- Dennis
On 07/16/2013 09:12 PM, Carlos Aza wrote:
> Hello Dennis,
>
> The error was missed in the conversion from Nabble to mail. This is what
> appears when WS-RM interceptor tries to send the createSequence message:
>
> 10:18:48.328 [main] ERROR org.apache.cxf.ws.rm.Proxy - Failed to send RM
> protocol message {http://schemas.xmlsoap.org/ws/2005/02/rm}CreateSequence.
> 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.
> at
> org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:195)
> ~[cxf-bundle-2.7.5.jar:2.7.5]
> at
> org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:98)
> ~[cxf-bundle-2.7.5.jar:2.7.5]
> at
> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:165)
> ~[cxf-bundle-2.7.5.jar:2.7.5]
>
> ...
>
> Caused by: org.apache.cxf.ws.policy.PolicyException: 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.
> at
> org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:315)
> ~[cxf-bundle-2.7.5.jar:2.7.5]
>
> ...
>
> The configuration is done via Policy:
>
> <wsp:Policy wsu:Id="RM" xmlns:wsp="http://www.w3.org/2006/07/ws-policy"
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
> <wsam:Addressing
> xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata">
> <wsp:Policy />
> </wsam:Addressing>
> <wsrmp:RMAssertion
> xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
> <wsrmp:BaseRetransmissionInterval
> Milliseconds="10000" />
> </wsrmp:RMAssertion>
> </wsp:Policy>
>
> The interceptors are loaded automatically via ws-policy support.
>
> Thank you in advance.
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/WSRM-in-combination-with-WS-Security-timestamp-problem-tp5723872p5730879.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
Re: WSRM in combination with WS-Security: timestamp problem
Posted by Carlos Aza <ca...@indra.es>.
Hello Dennis,
The error was missed in the conversion from Nabble to mail. This is what
appears when WS-RM interceptor tries to send the createSequence message:
10:18:48.328 [main] ERROR org.apache.cxf.ws.rm.Proxy - Failed to send RM
protocol message {http://schemas.xmlsoap.org/ws/2005/02/rm}CreateSequence.
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.
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:195)
~[cxf-bundle-2.7.5.jar:2.7.5]
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:98)
~[cxf-bundle-2.7.5.jar:2.7.5]
at
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:165)
~[cxf-bundle-2.7.5.jar:2.7.5]
...
Caused by: org.apache.cxf.ws.policy.PolicyException: 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.
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:315)
~[cxf-bundle-2.7.5.jar:2.7.5]
...
The configuration is done via Policy:
<wsp:Policy wsu:Id="RM" xmlns:wsp="http://www.w3.org/2006/07/ws-policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsam:Addressing
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata">
<wsp:Policy />
</wsam:Addressing>
<wsrmp:RMAssertion
xmlns:wsrmp="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
<wsrmp:BaseRetransmissionInterval
Milliseconds="10000" />
</wsrmp:RMAssertion>
</wsp:Policy>
The interceptors are loaded automatically via ws-policy support.
Thank you in advance.
--
View this message in context: http://cxf.547215.n5.nabble.com/WSRM-in-combination-with-WS-Security-timestamp-problem-tp5723872p5730879.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: WSRM in combination with WS-Security: timestamp problem
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Carlos,
I'm working on fixing these issues now, specifically on the combination
of WS-RM with WS-SecureConversation. This is the configuration specified
by the WS-I Reliable Secure Profile
(http://www.ws-i.org/Profiles/ReliableSecureProfile-1.0-2010-11-09.html).
But you left out the error in your email. Can you specify what error
you're encountering?
Thanks,
- Dennis
Dennis M. Sosnoski
Java SOA and 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 07/16/2013 08:35 PM, Carlos Aza wrote:
> Hello,John Li said
> John Li wrote
>> I have been working with the WSRM implementation of Apache CXF and now
>> I'mcombining it with WS-Security. After a struggle the createSequence call
>> issuccessfully finished with WS-Security added [...]
> I am fighting with the same problem. When working with WS-RM or WS-Security,
> they work as a charm, but combining them doesn't work as the WS-RM messages
> (createSequence, ...) fail when passing through WSS4J interceptors.The error
> that appears is:Any clues about how to workaround this problem?Thanks
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/WSRM-in-combination-with-WS-Security-timestamp-problem-tp5723872p5730877.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
Re: WSRM in combination with WS-Security: timestamp problem
Posted by Carlos Aza <ca...@indra.es>.
Hello,John Li said
John Li wrote
> I have been working with the WSRM implementation of Apache CXF and now
> I'mcombining it with WS-Security. After a struggle the createSequence call
> issuccessfully finished with WS-Security added [...]
I am fighting with the same problem. When working with WS-RM or WS-Security,
they work as a charm, but combining them doesn't work as the WS-RM messages
(createSequence, ...) fail when passing through WSS4J interceptors.The error
that appears is:Any clues about how to workaround this problem?Thanks
--
View this message in context: http://cxf.547215.n5.nabble.com/WSRM-in-combination-with-WS-Security-timestamp-problem-tp5723872p5730877.html
Sent from the cxf-dev mailing list archive at Nabble.com.