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" <cohei...@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_longs...@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" <cohei...@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/se >>c >> >>>urity/src/main/java/org/apache/cxf/ws/security/wss4j/policyvalidators/Al >>>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_longs...@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_longs...@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" <d...@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.
