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/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.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
