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/cxf/ws/security/wss4j/policyvalidators/AlgorithmSuitePolicyValidator.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. > > 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
