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/sec >urity/src/main/java/org/apache/cxf/ws/security/wss4j/policyvalidators/Algo >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.
