You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by dhogan <di...@forgerock.com> on 2015/03/09 22:23:10 UTC
Custom SecurityPolicy Assertions and the Symmetric binding
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.
Re: Custom SecurityPolicy Assertions and the Symmetric binding
Posted by Colm O hEigeartaigh <co...@apache.org>.
> FINE: An exception was thrown when verifying that the effective policy for
> this request was satisfied. However, this exception will not result in a
> fault. The exception raised is: org.apache.cxf.ws.policy.PolicyException:
> These policy alternatives can not be satisfied:
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
Ok I can see what the problem is here, the token wrapper is not being
asserted in the TransportBindingHandler. This is already fixed on CXF
3.0.x. I'm not inclined to fix it for CXF 2.7.x, as it's a minor (logging)
issue.
> I don't see a SupportingTokens class in wss4j 1.6.13, and the
> SupportingToken class in cxf 2.7.8 does not have a parseNestedPolicy
method.
> What am I missing?
I was talking about CXF 3.0.x. Actually thinking about it, I think the
"serialize" stuff is not used by the security runtime.
Colm.
On Fri, Mar 20, 2015 at 3:14 PM, dhogan <di...@forgerock.com> wrote:
> Hi Colm-
> A couple of additional data points: the exact same log entries I encounter
> when consuming an STS issue protected by the OpenAMSessionToken over the
> TransportBinding are logged when I consume an STS issue protected by a UNT
> over the TransportBinding. The logs appear client-side and server-side:
>
> FINE: An exception was thrown when verifying that the effective policy for
> this request was satisfied. However, this exception will not result in a
> fault. The exception raised is: org.apache.cxf.ws.policy.PolicyException:
> These policy alternatives can not be satisfied:
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
>
> Debugging TransportBindingHandler#handleBinding for the UNT case is the
> same
> as the OpenAMSessionToken case - the HttpsToken is not an IssuedToken, so
> the TransportToken is never asserted. I see the same logic in the 3.0.4
> TransportBindingHandler (I'm currently working on the 2.7.8 release). I
> don't see when a HttpsToken could ever be an IssuedToken.
>
> I also don't see the
> org.apache.cxf.ws.security.policy.model.UsernameToken#serialize ever being
> called, neither when the STS instance is being exposed, nor when it is
> consumed.
>
> Thanks
>
> Dirk
>
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Custom-SecurityPolicy-Assertions-and-the-Symmetric-binding-tp5754879p5755303.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Custom SecurityPolicy Assertions and the Symmetric binding
Posted by dhogan <di...@forgerock.com>.
Hi Colm-
A couple of additional data points: the exact same log entries I encounter
when consuming an STS issue protected by the OpenAMSessionToken over the
TransportBinding are logged when I consume an STS issue protected by a UNT
over the TransportBinding. The logs appear client-side and server-side:
FINE: An exception was thrown when verifying that the effective policy for
this request was satisfied. However, this exception will not result in a
fault. The exception raised is: org.apache.cxf.ws.policy.PolicyException:
These policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
Debugging TransportBindingHandler#handleBinding for the UNT case is the same
as the OpenAMSessionToken case - the HttpsToken is not an IssuedToken, so
the TransportToken is never asserted. I see the same logic in the 3.0.4
TransportBindingHandler (I'm currently working on the 2.7.8 release). I
don't see when a HttpsToken could ever be an IssuedToken.
I also don't see the
org.apache.cxf.ws.security.policy.model.UsernameToken#serialize ever being
called, neither when the STS instance is being exposed, nor when it is
consumed.
Thanks
Dirk
--
View this message in context: http://cxf.547215.n5.nabble.com/Custom-SecurityPolicy-Assertions-and-the-Symmetric-binding-tp5754879p5755303.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Custom SecurityPolicy Assertions and the Symmetric binding
Posted by dhogan <di...@forgerock.com>.
>It's asserted via "policyAsserted(transportToken);" in the
>TransportBindingHandler.
A bit of context: I am setting my custom AssertionBuilder and
PolicyInterceptorProvider with the bus associated with my STS client, and
with the bus associated with my STS instance.
I saw this call to policyAsserted, but the surrounding branch is never
entered, as the Token returned from the transportTokenWrapper is an instance
of the HttpsToken class, which is not an IssuedToken subclass.
When I step through the
TransportBindingHandler#handleNonEndorsingSupportingTokens method, I can see
my custom token in the tokens ArrayList in the SupportingToken (line 207),
so it is definitely being included. I can also see a BST containing my
custom assertion in the RST invocation, which my registered policy
interceptors on my STS can extract and validate.
>I would put a breakpoint in WSS4J's SupportingTokens.parseNestedPolicy to
see what is going on.
I don't see a SupportingTokens class in wss4j 1.6.13, and the
SupportingToken class in cxf 2.7.8 does not have a parseNestedPolicy method.
What am I missing?
Thanks
Dirk
--
View this message in context: http://cxf.547215.n5.nabble.com/Custom-SecurityPolicy-Assertions-and-the-Symmetric-binding-tp5754879p5755272.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Custom SecurityPolicy Assertions and the Symmetric binding
Posted by Colm O hEigeartaigh <co...@apache.org>.
> I can't see where this policy is asserted anywhere in the
TransportBindingHandler/TransportBinding/TransportToken.
It's asserted via "policyAsserted(transportToken);" in the
TransportBindingHandler.
> Finally, the neethi Assertion#serialize method. It is never called for my
> Token subclass. I almost feel like it would be called to get the xml
> representation of an effective policy from a 'top-level' Policy object
like
> TransportBinding. Can you tell me under what circumstances it is called?
Are you implementing a AssertionBuilder implementation for your custom
token + registering it with the AssertionBuilderRegistry on the CXF bus? I
would put a breakpoint in WSS4J's SupportingTokens.parseNestedPolicy to see
what is going on.
Colm.
On Wed, Mar 18, 2015 at 8:03 PM, dhogan <di...@forgerock.com> wrote:
> Thanks for your patience Colm.
>
> I began asserting the TRANSPORT_TOKEN in my interceptor as I got the
> following message in the logs, on both the client and server-side:
> An exception was thrown when verifying that the effective policy for this
> request was satisfied. However, this exception will not result in a fault.
> The exception raised is: org.apache.cxf.ws.policy.PolicyException: These
> policy alternatives can not be satisfied:
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
>
> I can't see where this policy is asserted anywhere in the
> TransportBindingHandler/TransportBinding/TransportToken. Can that warning
> be
> ignored?
>
> Finally, the neethi Assertion#serialize method. It is never called for my
> Token subclass. I almost feel like it would be called to get the xml
> representation of an effective policy from a 'top-level' Policy object like
> TransportBinding. Can you tell me under what circumstances it is called?
>
> Thanks
>
> Dirk
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Custom-SecurityPolicy-Assertions-and-the-Symmetric-binding-tp5754879p5755233.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Custom SecurityPolicy Assertions and the Symmetric binding
Posted by dhogan <di...@forgerock.com>.
Thanks for your patience Colm.
I began asserting the TRANSPORT_TOKEN in my interceptor as I got the
following message in the logs, on both the client and server-side:
An exception was thrown when verifying that the effective policy for this
request was satisfied. However, this exception will not result in a fault.
The exception raised is: org.apache.cxf.ws.policy.PolicyException: These
policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
I can't see where this policy is asserted anywhere in the
TransportBindingHandler/TransportBinding/TransportToken. Can that warning be
ignored?
Finally, the neethi Assertion#serialize method. It is never called for my
Token subclass. I almost feel like it would be called to get the xml
representation of an effective policy from a 'top-level' Policy object like
TransportBinding. Can you tell me under what circumstances it is called?
Thanks
Dirk
--
View this message in context: http://cxf.547215.n5.nabble.com/Custom-SecurityPolicy-Assertions-and-the-Symmetric-binding-tp5754879p5755233.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Custom SecurityPolicy Assertions and the Symmetric binding
Posted by Colm O hEigeartaigh <co...@apache.org>.
> I noted how the UsernameTokenInterceptor asserts the SUPPORTING_TOKEN and
> SIGNED_SUPPORTING_TOKEN, and I do the same in my AbstractTokenInterceptor
> subclass, but assert SUPPORTING_TOKEN and TRANSPORT_TOKEN (when
isTLSInUse).
The TransportToken assertion should be handled by the
TransportBindingHandler. Or do you have a use-case where the TransportToken
appears independently of the TransportBinding?
> Do you suggest subclassing a different class when handling non-bare
> SupportingTokens? So the logic in the UsernameTokenInterceptor (and in the
> AbstractTokenInterceptor) asserting the SIGNED_SUPPORTING_TOKEN would
never
> really be engaged in an outbound request (addToken case) when a
> symmetric/asymmetric/transport binding were in the policy?
I don't really understand the question. For the case that you are using the
Transport Binding, then you can just assert the SignedSupportingTokens
policy as the request is signed by the Transport layer. For the other
bindings, your token interceptors would require some work to first add the
token to the security header of the request, and then pass the
WSEncryptionParts that reference the token to the binding handlers for
signing, the latter would need to be updated to handle this scenario.
Colm.
On Mon, Mar 16, 2015 at 10:55 PM, dhogan <di...@forgerock.com> wrote:
> Hi Colm-
> I am back on CXF 2.7.8 - I ran into
> https://issues.apache.org/jira/browse/CXF-5894, and did not have the
> option
> of updating my jaxb dependencies.
>
> I have things working with the older cxf/wss4j library set, but I have a
> few
> questions:
> Regarding subclassing AbstractTokenInterceptor, much of my implementation
> was modeled after the
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor. I noted how the
> UsernameTokenInterceptor asserts the SUPPORTING_TOKEN and
> SIGNED_SUPPORTING_TOKEN, and I do the same in my AbstractTokenInterceptor
> subclass, but assert SUPPORTING_TOKEN and TRANSPORT_TOKEN (when
> isTLSInUse).
> I have not had the time to go after the symmetric/asymmetric binding with
> custom tokens - I’m hoping that the transport binding will be sufficient.
> Do
> you suggest subclassing a different class when handling non-bare
> SupportingTokens? So the logic in the UsernameTokenInterceptor (and in the
> AbstractTokenInterceptor) asserting the SIGNED_SUPPORTING_TOKEN would never
> really be engaged in an outbound request (addToken case) when a
> symmetric/asymmetric/transport binding were in the policy?
>
> Finally, one change in the cxf-3.04->cxf-2.7.8 change perplexes me: the
> org.apache.cxf.ws.security.policy.model.Token#serialize method (inherited
> via the org.apache.neethi.Assertion interface). It is never called for my
> Token subclass. Searching the source, I see it called from ‘higher-level’
> SecurityPolicy abstractions - e.g. the TransportBinding, TransportToken, or
> RecipientSignatureToken, etc. Perhaps this is part of the answer to my
> question at the end of the previous paragraph: the functionality of
> AbstractTokenInterceptor#addToken is handled by the Token#serialize methods
> when standard tokens are presented as part of the
> symmetric/asymmetric/transport binding? And my subclassing of the
> AbstractTokenInterceptor and commenting-out of the
> WSS4JInInterceptor.SECURITY_PROCESSED (server-side interceptor) and
> PolicyBasedWSS4JOutInterceptor.SECURITY_PROCESSED (client-side interceptor)
> is not a dirty hack because custom token types are more difficult to
> integrate into the standard bindings, and thus are best handled as
> AbstractTokenInterceptor subclasses? So it would be OK to e.g. throw an
> IllegalStateException in the serialize method of my custom assertion,
> pending the more profound integration necessary to support e.g. a
> SignedSupportingToken in a symmetric/asymmetric binding?
>
> Apologies for the cascade of questions, but getting things working is one
> thing - actually understanding (somewhat) is another thing altogether.
>
> Thanks
>
> Dirk
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Custom-SecurityPolicy-Assertions-and-the-Symmetric-binding-tp5754879p5755146.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Custom SecurityPolicy Assertions and the Symmetric binding
Posted by dhogan <di...@forgerock.com>.
Hi Colm-
I am back on CXF 2.7.8 - I ran into
https://issues.apache.org/jira/browse/CXF-5894, and did not have the option
of updating my jaxb dependencies.
I have things working with the older cxf/wss4j library set, but I have a few
questions:
Regarding subclassing AbstractTokenInterceptor, much of my implementation
was modeled after the
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor. I noted how the
UsernameTokenInterceptor asserts the SUPPORTING_TOKEN and
SIGNED_SUPPORTING_TOKEN, and I do the same in my AbstractTokenInterceptor
subclass, but assert SUPPORTING_TOKEN and TRANSPORT_TOKEN (when isTLSInUse).
I have not had the time to go after the symmetric/asymmetric binding with
custom tokens - I’m hoping that the transport binding will be sufficient. Do
you suggest subclassing a different class when handling non-bare
SupportingTokens? So the logic in the UsernameTokenInterceptor (and in the
AbstractTokenInterceptor) asserting the SIGNED_SUPPORTING_TOKEN would never
really be engaged in an outbound request (addToken case) when a
symmetric/asymmetric/transport binding were in the policy?
Finally, one change in the cxf-3.04->cxf-2.7.8 change perplexes me: the
org.apache.cxf.ws.security.policy.model.Token#serialize method (inherited
via the org.apache.neethi.Assertion interface). It is never called for my
Token subclass. Searching the source, I see it called from ‘higher-level’
SecurityPolicy abstractions - e.g. the TransportBinding, TransportToken, or
RecipientSignatureToken, etc. Perhaps this is part of the answer to my
question at the end of the previous paragraph: the functionality of
AbstractTokenInterceptor#addToken is handled by the Token#serialize methods
when standard tokens are presented as part of the
symmetric/asymmetric/transport binding? And my subclassing of the
AbstractTokenInterceptor and commenting-out of the
WSS4JInInterceptor.SECURITY_PROCESSED (server-side interceptor) and
PolicyBasedWSS4JOutInterceptor.SECURITY_PROCESSED (client-side interceptor)
is not a dirty hack because custom token types are more difficult to
integrate into the standard bindings, and thus are best handled as
AbstractTokenInterceptor subclasses? So it would be OK to e.g. throw an
IllegalStateException in the serialize method of my custom assertion,
pending the more profound integration necessary to support e.g. a
SignedSupportingToken in a symmetric/asymmetric binding?
Apologies for the cascade of questions, but getting things working is one
thing - actually understanding (somewhat) is another thing altogether.
Thanks
Dirk
--
View this message in context: http://cxf.547215.n5.nabble.com/Custom-SecurityPolicy-Assertions-and-the-Symmetric-binding-tp5754879p5755146.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Custom SecurityPolicy Assertions and the Symmetric binding
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <di...@forgerock.com> 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