Hi Dirk, > This all works beautifully for a ‘bare’ binding which just references the > custom SupportingToken. Once I tried to move this to the symmetric binding, > things no longer worked.
The AbstractTokenInterceptor is only really designed to be used in the "standalone" case of a SupportingToken with no security binding, as the PolicyBasedWSS4J interceptors only kick in with a security binding. However, I think your "hack" is actually ok for your use-case. It'd be interesting to see what is required to get it working if it was a SignedSupportingToken for example. > And finally, I noticed that AbstractTokenInterceptors#handleMessage returns > immediately if the new stax functionality is engaged. Are custom > SecurityPolicy assertions supported under the new stax Interceptors? Or is > there another base class to extend? Custom assertions/tokens are supported, but only by configuration - see here: https://svn.apache.org/repos/asf/webservices/wss4j/trunk/ws-security-stax/src/main/resources/wss/wss-config.xml The reason the AbstractTokenInterceptors stuff is disabled for StAX is that the streaming code actually handles the use-case of UsernameToken/SAML/Kerberos with no bindings without any changes. Colm. On Mon, Mar 9, 2015 at 9:23 PM, dhogan <[email protected]> wrote: > Hi- > I am running cxf-3.0.4. > > I would like to reference the following custom SupportingToken in my > SecurityPolicy bindings: > > <sp:SupportingTokens> > <wsp:Policy> > <ForgeRock:OpenAMSessionToken > > sp:IncludeToken=" > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient > " > > xmlns:ForgeRock="http://schemas.forgerock.org/ws/securitypolicy";> > <wsp:Policy/> > </ForgeRock:OpenAMSessionToken> > </wsp:Policy> > </sp:SupportingTokens> > > Using http://cxf.apache.org/docs/developing-assertions.html and > > http://cxf.547215.n5.nabble.com/PolicyException-when-using-BST-with-custom-ValueType-td5743444.html > as my guide, I implemented custom AbstractToken subclass, and the > associated > AssertionBuilder<Element> subclass, which is registered with the > AssertionBuilderRegistry on the client and server side. Likewise, I > implemented an AbstractTokenInterceptor subclass and the associated > AbstractPolicyInterceptorProvider subclass, which was registered with the > PolicyInterceptorProviderRegistry on the client and server side. > > This all works beautifully for a ‘bare’ binding which just references the > custom SupportingToken. Once I tried to move this to the symmetric binding, > things no longer worked. Investigating a bit, it turns out that the > AbstractTokenInterceptor is always added after the > PolicyBasedWSS4JOutInterceptor, and that the latter is only added by the > WSSecurityInterceptorProvider when e.g. a symmetric binding was added. > Things worked for the ‘bare’ binding because the > PolicyBasedWSS4JOutInterceptor was not part of the interceptor chain. The > PolicyBasedWSS4JOutInterceptor just invokes the SAAJOutInterceptor, and > then > sets the PolicyBasedWSS4JOutInterceptor.SECURITY_PROCESSED flag on the > message, which prevents the AbtractTokenInterceptor from calling either > addToken or processToken when it finally is invoked. > > So I just re-implemented the handleMessage method on my > AbstractTokenInterceptor subclasses, disabled the SECURITY_PROCESSED flags, > and surprisingly, everything worked (though I was not specifying a signed > and/or encrypted SupportingToken in my SecurityPolicy bindings). I’m > wondering if this is a dirty hack, or a viable approach? I’d appreciate any > course-corrections and/or confirmations as to the basic approach described > above, and my ‘dirty hack.’ > > And finally, I noticed that AbstractTokenInterceptors#handleMessage returns > immediately if the new stax functionality is engaged. Are custom > SecurityPolicy assertions supported under the new stax Interceptors? Or is > there another base class to extend? > > Thanks > > Dirk > > > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/Custom-SecurityPolicy-Assertions-and-the-Symmetric-binding-tp5754879.html > Sent from the cxf-user mailing list archive at Nabble.com. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
