cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Longsine, Pohl" <Pohl_Longs...@gallup.com>
Subject Re: Apache CXF with WS-Security
Date Fri, 19 Sep 2014 17:19:19 GMT
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:

    <sp:TransportBinding
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">

…to…


    <sp:TransportBinding
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

…then the service call works. (The whole thing: the RM messages and the
actual method call).

So, to sum up, we're running with a locally-hacked WSDL with two changes:
one where we pulled the policies from the methods up to the endpoint (the
change discussed several days ago) plus the namespace change above.

So my question is: is CXF doing the right thing here?  Does CXF want to be
able to interoperate with WCF in the event that it is using old & new
WS-Security namespaces like this? If not, could it be failing in a more
informative manner?



On 9/19/14 11:25 AM, "Longsine, Pohl" <Pohl_Longsine@gallup.com> wrote:

>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 <sp:AsymmetricBinding
>xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
>
>
>
>On 9/19/14 6:16 AM, "Colm O hEigeartaigh" <coheigea@apache.org> wrote:
>
>>The AlgorithmSuite security policies are asserted if "valid" in the
>>AlgorithmSuitePolicyValidator:
>>
>>if (valid) {
>>                String namespace =
>>algorithmSuite.getAlgorithmSuiteType().getNamespace();
>>                String name =
>>algorithmSuite.getAlgorithmSuiteType().getName();
>>                Collection<AssertionInfo> algSuiteAis = aim.get(new
>>QName(namespace, name));
>>                if (algSuiteAis != null) {
>>                    for (AssertionInfo algSuiteAi : algSuiteAis) {
>>                        algSuiteAi.setAsserted(true);
>>                    }
>>                }
>>            } else if (!valid && ai.isAsserted()) {
>>                ai.setNotAsserted("Error in validating AlgorithmSuite
>>policy");
>>            }
>>
>>So I recommend setting a breakpoint above this + see if valid is being
>>set
>>to "false". If so then find out exactly where in the "validatePolicy"
>>method this is happening.
>>
>>Colm.
>>
>>On Thu, Sep 18, 2014 at 8:25 PM, Longsine, Pohl
>><Pohl_Longsine@gallup.com>
>>wrote:
>>
>>> 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 expect something like the following line to be
>>>somewhere
>>> in CXF source:
>>>
>>> assertPolicy(new
>>> QName(binding.getAlgorithmSuite().getName().getNamespaceURI(),
>>> SPConstants.ALGO_SUITE_BASIC256));
>>>
>>> …but we can't find such a thing anywhere. We figured maybe something
>>>like
>>> that should be somewhere below the
>>> AbstractCommonBindingHandler.assertAlgorithmSuite() method.
>>>
>>> In fact, we can't find any use of the SPConstants.ALGO_SUITE_BASIC256
>>> constant at all.
>>>
>>>
>>>
>>>
>>>
>>> On 9/18/14 4:01 AM, "Colm O hEigeartaigh" <coheigea@apache.org> wrote:
>>>
>>> >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/s
>>>e
>>>c
>>>
>>>>urity/src/main/java/org/apache/cxf/ws/security/wss4j/policyvalidators/A
>>>>l
>>>>go
>>> >rithmSuitePolicyValidator.java;hb=HEAD
>>> >
>>> >I recommend putting some breakpoints in there and see where it is
>>> >unasserting the policy (if this in fact is the problem).
>>> >
>>> >Colm.
>>> >
>>> >On Wed, Sep 17, 2014 at 6:05 PM, Longsine, Pohl
>>><Pohl_Longsine@gallup.com
>>> >
>>> >wrote:
>>> >
>>> >> 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://gist.github.com/themmer/b274c9f720c4dcbaec83
>>> >>
>>> >> I believe this proves that JCE is functioning in our environment.
>>>Our
>>> >> Soap handler log unfortunately happens before signing/encryption,
>>>hence
>>> >> the confusion earlier about the request not being correct.
>>> >>
>>> >> One interesting thing: it is failing when the response is coming in
>>>and
>>> >>we
>>> >> are verifying the policy. What is happening is the AssertionInfo for
>>> >> Basic256 policy is not asserted for some reason. See stack trace in
>>>the
>>> >> above gist and the code snippet below for an explanation of what is
>>> >> happening in debug mode.
>>> >>
>>> >> (the following is from AssertionInfoMap.java ­ CXF 3.0.1)
>>> >>
>>> >> Assertion ass = (Assertion)assertion;
>>> >> Collection<AssertionInfo> ail = getAssertionInfo(ass.getName());
>>> >> boolean found = false;
>>> >> for (AssertionInfo ai : ail) {
>>> >>    if (ai.getAssertion().equal(ass)) { // Expression A
>>> >>       found = true;
>>> >>       if (!ai.isAsserted() && !ass.isOptional()) { // Expression
B,
>>> >>where
>>> >> we fail
>>> >>          // I believe Basic 256 should be asserted since it is part
>>>of
>>> >>the
>>> >> Algo Suite
>>> >>          errors.add(ass.getName());
>>> >>          pass = false;
>>> >>       }
>>> >>    }
>>> >> ...
>>> >>
>>> >>
>>> >>
>>> >> We are failing here in AssertionInfoMap. "Expression A" evaluates to
>>> >>true
>>> >> (where the AssertionInfo is the basic 256 assertion info from inside
>>> >> asymmetric binding).  But then "Expression B" evaluates to false
>>>because
>>> >> it is not optional and not asserted (this would be the problem I
>>> >>believe).
>>> >> At this point it adds the error and will fail due to this.
>>> >>
>>> >> Is it possible that the assertPolicy is not called for the
>>>Asymmetric
>>> >> Binding with policies in the lower layers (Basic 256)? The
>>>asymmetric
>>> >> binding is what is failing through the debugger when verifying the
>>> >>policy
>>> >> on the incoming create sequence response.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On 9/17/14 10:33 AM, "Longsine, Pohl" <Pohl_Longsine@gallup.com>
>>>wrote:
>>> >>
>>> >> >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" <dms@sosnoski.com>
wrote:
>>> >> >>
>>> >> >>>I'm not sure what's going on now, Pohl. It looks like the
request
>>> >> >>>message is being sent without security headers, and the
server
>>> >>responds
>>> >> >>>anyway with a signed message. But the stack trace says the
>>>request is
>>> >> >>>not being sent in the first place because of a security
>>>assertion:
>>> >> >>>
>>> >> >>>Caused by: org.apache.cxf.ws.policy.PolicyException: These
poliy
>>> >> >>>alternatives can not be satisfied:
>>> >>
>>>>>>{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}Basic256
>>> >> >>>
>>> >> >>>Do you have the unlimited strength cryptography extensions
>>>installed
>>> >>in
>>> >> >>>your JVM? I believe you need these in order to use Basic256.
That
>>> >>aside,
>>> >> >>>it would be better if you used http://pastebin.com/ or something
>>> >> similar
>>> >> >>>for your files, since it's really hard to read them in the
email.
>>> >> >>>
>>> >> >>>- Dennis
>>>
>>> All information in this message is confidential and may be legally
>>> privileged. Only intended recipients are authorized to use it.
>>>
>>
>>
>>
>>--
>>Colm O hEigeartaigh
>>
>>Talend Community Coder
>>http://coders.talend.com
>
>All information in this message is confidential and may be legally
>privileged. Only intended recipients are authorized to use it.

All information in this message is confidential and may be legally privileged. Only intended
recipients are authorized to use it.
Mime
View raw message