On Mar 9, 2013, at 8:24 PM, Martin Gainty <[email protected]> wrote:
> assuming your policy declare this namespace > xmlns:wsp=http://schemas.xmlsoap.org/ws/2004/09/policy > Axis2 1.6.2 MTOM enforces existence of wsp:Policy element in policies > processed by Axis-MTOM > > Here is the XSD > http://schemas.xmlsoap.org/ws/2004/09/policy/ws-policy.xsd > > In that regard I would *assume* CXF would support the same SecurityPolicy > 1.1 as Axis Well, Axis2/Rampart also does not enforce the child wsp:Policy element within HttpsToken elements from what I can tell. For example: http://svn.apache.org/repos/asf/axis/axis2/java/rampart/trunk/modules/rampart-integration/src/test/resources/rampart/policy/sc-6.xml is technically not valid as the HttpsToken is in the http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 namespace (WS-SecPol 1.2) and that version of the SecPol spec does not have the child Policy element marked optional: http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826544 However, the older 1.1 version of WS-SecPol did have the child Policy as optional: http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf (section 6.3.10) and thus a lot of policies that have been updated from 1.1 to 1.2 are invalid. I probably should have been clearer and stated that we are only talking about 1.2 based policies as it is optional in 1.1. To verify, I also checked the Rampart HttpsTokenBuilder for 1.2 and it does: HttpsToken httpsToken = new HttpsToken(SPConstants.SP_V12); if (element.getFirstElement()!= null) { Policy policy = PolicyEngine.getPolicy(element.getFirstElement()); policy = (Policy) policy.normalize(false); for (Iterator iterator = policy.getAlternatives(); iterator.hasNext();) { processAlternative((List) iterator.next(), httpsToken); break; // since there should be only one alternative } } return httpsToken; so if there isn't a child Policy element, it returns quietly. So no enforcement. Dan > Author Tags: reading Author tags that say Craig McClanahan even though he > hasnt touched that code in 10 yrs > > +1 deprecate that tag! They are now removed from the wss4j 2.0 stuff. Yea! :-) Dan > > Martin > > > > Subject: Re: WSS4J 2.0 and some "compatibility" things... > > From: [email protected] > > Date: Fri, 8 Mar 2013 09:24:42 -0500 > > To: [email protected] > > > > > > On Mar 8, 2013, at 9:02 AM, Daniel Kulp <[email protected]> wrote: > > > > > > > > Marc/Colm, > > > > > > Started looking into the wss4j2 integration stuff on Colms branch in CXF > > > and have a question: > > > > > > In CXF, we have a few places where we're a little more "relaxed" during > > > parsing since most of the policies that out there may not be 100% > > > correct. The first example I hit was the ws:Policy child element in an > > > HttpsToken. wss4j2 throws an exception in this case whereas CXF logs a > > > warning and continues. What are your thoughts on this? Should we be > > > completely strict or accept the technically invalid policies that are > > > very common? Changing the code in HttpsBuilder to: > > > Policy nestedPolicy; > > > if (nestedPolicyElement == null) { > > > //throw new IllegalArgumentException("sp:HttpsToken must have an inner > > > wsp:Policy element"); > > > nestedPolicy = new Policy(); > > > } else { > > > nestedPolicy = factory.getPolicyEngine().getPolicy(nestedPolicyElement); > > > } > > > seems to work fine. Likely should have a LOG in there….. > > > > Likewise for TransportBinding/AlgorithmSuite when using SecurityPolicy 1.1. > > Yes, spec says required, but lots of "real world" policies don't have it. > > (including most of the one's in the CXF system test suite. :-( ) > > > > Dan > > > > > > > > > > Also, any objections if I go through the code and remove the @author and > > > @version tags? Highly discouraged at Apache…. but the $Author$ and > > > $Revision$ things and such don't get expanded with git. :-) > > > > > > > > > Thoughts? > > > > > > -- > > > Daniel Kulp > > > [email protected] - http://dankulp.com/blog > > > Talend Community Coder - http://coders.talend.com > > > > > > > -- > > Daniel Kulp > > [email protected] - http://dankulp.com/blog > > Talend Community Coder - http://coders.talend.com > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
