> So my question is: is CXF doing the right thing here?
No...it's a bug that I've just fixed in WSS4J:
http://svn.apache.org/viewvc?view=revision&revision=r1626783
It'll be picked up in the next CXF release.
Colm.
On Fri, Sep 19, 2014 at 6:19 PM, Longsine, Pohl
wrote:
> So this is interestin
So this is interesting. There appear to be two different WS-Security
namespace URIs in the WSDL, and if we manually change the one instance of:
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
…to…
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702";>
…then the service c
We followed this suggestion and found out that Basic 256 is being
asserted, but with the wrong namespace.
It is tying it to http://schemas.xmlsoap.org/ws/2005/07/securitypolicy
However, the namespace in the WSDL is http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702";>
On 9/19/14 6:16 AM
The AlgorithmSuite security policies are asserted if "valid" in the
AlgorithmSuitePolicyValidator:
if (valid) {
String namespace =
algorithmSuite.getAlgorithmSuiteType().getNamespace();
String name =
algorithmSuite.getAlgorithmSuiteType().getName();
We followed your suggestion and put breakpoints in every method in that
class. We could not witness any unassert happening there.
Where in the CXF codebase would a Basic256 assertPolicy(...) happen in the
first place? Judging by how other things are asserted (such as lax/strict
layout) we would e
Hi,
I don't see anything obviously wrong in the messages. If "Basic256" policy
validation is failing, then it sounds like there is a mismatch somewhere in
the AlgorithmSuitePolicyValidator:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob_plain;f=rt/ws/security/src/main/java/org/apache/cx
A member of my team wrote this to pass on to you:
Thank you so much for your guidance so far.
We had a chance to monitor the actual request being sent and it is being
signed and encrypted. Here is the request, response, modified wsdl with
copied policy as suggested, and the stack trace.
https
Yes, we do have JCE in place.
Sorry about not using a pastebin. Most of those are blacklisted by our
draconian gateway, but I see that Github gists have somehow slipped
through the cracks, so next time I'll use that.
>
>
>On 9/16/14 6:15 PM, "Dennis Sosnoski" wrote:
>
>>I'm not sure what's go
Hi Pohl,
Sorry the mirage faded away. :-(
The problem with your policy (at least from the standpoint of the CXF
code) is that it's in a bunch of separate pieces. That adds a lot of
bulk to the WSDL, but otherwise is not normally a problem - the
different pieces are applied in different places and
On Aug 14, 2014, at 4:58 PM, Dennis Sosnoski wrote:
> Hi Paul,
>
> I think I see what's going on here. Your AuthenticationDiacapEndpoint_policy
> which specifies the use of RM and AsymmetricBinding doesn't set anything to
> be signed, instead leaving that to the individual input and output po
Hi Paul,
I think I see what's going on here. Your
AuthenticationDiacapEndpoint_policy which specifies the use of RM and
AsymmetricBinding doesn't set anything to be signed, instead leaving
that to the individual input and output policies (such as
AuthenticationDiacapEndpoint_Activate_Input_po
On 8/13/14 4:32 PM, "Daniel Kulp" wrote:
>The policy has aassertion in it so I would
>have expected the signatures to be encrypted. The CXF request has two
>ncryptedData elements which MAY correspond to the two Signatures that
>the .NET client is sending. No really sure though as I don¹t k
On Aug 13, 2014, at 5:06 PM, Longsine, Pohl wrote:
> I am replying to my own question to provide one more interesting piece of
> information, in hopes of helping someone read and interpret what is going
> on here.
>
> I asked the .NET team to capture the SOAP messag from their own test
> client
Dennis, this turned out a bit differently than thought a couple of weeks
ago.
When the .NET team who own the service turned off W-SecureConversation
(which isn't needed) it had the side-effect of also causing thei end to
fail to digitally sign the SOAP traffic. Signing is a requirement for us
A
Yes, using standard WS-Security (signing and/or encrypting) should be
fine. It's just the combination with WS-SecureConversation where there
are likely to be problems at present.
- Dennis
On 08/02/2014 04:43 AM, Longsine, Pohl wrote:
I do have a higher level question I'd like to pose. I'm
I do have a higher level question I'd like to pose. I'm still fuzzy about
the
relationships between all of the various standards under the WS-* umbrella.
If it turns out that the .NET team who exposes this service still wants to
sign their SOAP responses, should it be possible without involving
W
Great, glad to hear that helped! And thanks for letting me know. :-)
- Dennis
On 08/02/2014 04:03 AM, Longsine, Pohl wrote:
Dennis,
I am a colleague of Ramzi's. It turns out that WS-SecureConversation was
not an actual requirement. We were able to ask the .NET team who owns the
service to t
Dennis,
I am a colleague of Ramzi's. It turns out that WS-SecureConversation was
not an actual requirement. We were able to ask the .NET team who owns the
service to turn it off. We also removed the interceptors as you
recommended. We managed to invoke the service after making those two
changes
Hi Ramzi,
CXF version 3 has not been tested for interoperable RM+SC with other
stacks, and I'm not surprised if you run into problems. It's unlikely
you'd have a better experience with older versions of CXF, though you
can always give it a try. Certainly the older versions are not going to
su
Thank you Dennis,
I am new to those standards so that was very enlightening. However if you don't
mind from your reply I gathered the following:
1. CXF Version 3 does not mix RM and Secure conversation
2. Based on the standard we need to use UsesSequenceSTR but that is not
supported in CXF
3.
Hi Ramzi,
There are issues in combining WS-SecureConversation with
WS-ReliableMessaging in the 3.0.x release. I did some work to support
this last year, but it was not a priority for the group I was working
with. Since I didn't have a working endpoint to test with I didn't
pursue it at that t
21 matches
Mail list logo
