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.
