You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by sram <sr...@hotmail.com> on 2012/04/14 01:27:25 UTC
WS Policy Execution order
My policy looks like,
<wsp:All>
<sp:AsymmetricBinding
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssX509V3Token10 />
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
</sp:UsernameToken>
</wsp:Policy>
</sp:SignedSupportingTokens>
<bnysp:AcceptsDisclosureStatement/>
</wsp:All>
As a client, I supply only usernametoken and I expect CXF to complain about
other missing policies. This does happen but only after *successfully*
authenticating my user. My expectation is to see an outright rejection from
CXF, when policy alternatives cannot be satisfied, w/out even authenticating
my user.
If I substitute a bad user, i see
<soap:Fault>
<faultcode>soap:Client</faultcode>
<faultstring>User Authentication Failure</faultstring>
</soap:Fault>
Is my expectation incorrect? OR Am I missing any here?
--
View this message in context: http://cxf.547215.n5.nabble.com/WS-Policy-Execution-order-tp5639774p5639774.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS Policy Execution order
Posted by Colm O hEigeartaigh <co...@apache.org>.
A future version of CXF (possibly CXF 2.7 or 3.0) will pick up WSS4J
2.0, which will evaluate security policies dynamically, rather than
after the security processing has completed.
Colm.
On Mon, Apr 16, 2012 at 1:18 PM, sram <sr...@hotmail.com> wrote:
> The only issue in this approach is, it exposes the system from rogue requests
> trying to guess passwords and when defended with max re-tries, will lock
> users. Not just that, it also has potential to open server sessions and
> max-out, when other parts of the contract are not satisfied. Can this be
> classified as a bug for future improvement?
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/WS-Policy-Execution-order-tp5639774p5643639.html
> Sent from the cxf-user mailing list archive at Nabble.com.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: WS Policy Execution order
Posted by sram <sr...@hotmail.com>.
The only issue in this approach is, it exposes the system from rogue requests
trying to guess passwords and when defended with max re-tries, will lock
users. Not just that, it also has potential to open server sessions and
max-out, when other parts of the contract are not satisfied. Can this be
classified as a bug for future improvement?
--
View this message in context: http://cxf.547215.n5.nabble.com/WS-Policy-Execution-order-tp5639774p5643639.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS Policy Execution order
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi,
> My expectation is to see an outright rejection from
> CXF, when policy alternatives cannot be satisfied, w/out even authenticating
> my user.
That is not how CXF currently works. It walks the security header of
the incoming request, and processes and validates each token it finds.
Only after the security header has been successfully processed does it
verify the results against the WS-SecurityPolicy requirement.
Colm.
On Sat, Apr 14, 2012 at 12:27 AM, sram <sr...@hotmail.com> wrote:
> My policy looks like,
> <wsp:All>
> <sp:AsymmetricBinding
> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <wsp:Policy>
> <sp:InitiatorToken>
> <wsp:Policy>
> <sp:X509Token
>
> sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
> <wsp:Policy>
> <sp:WssX509V3Token10 />
> </wsp:Policy>
> </sp:X509Token>
> </wsp:Policy>
> </sp:InitiatorToken>
> <sp:AlgorithmSuite>
> <wsp:Policy>
> <sp:Basic256 />
> </wsp:Policy>
> </sp:AlgorithmSuite>
> <sp:Layout>
> <wsp:Policy>
> <sp:Strict />
> </wsp:Policy>
> </sp:Layout>
> <sp:IncludeTimestamp />
> </wsp:Policy>
> </sp:AsymmetricBinding>
> <sp:SignedSupportingTokens>
> <wsp:Policy>
> <sp:UsernameToken
>
> sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
> </sp:UsernameToken>
> </wsp:Policy>
> </sp:SignedSupportingTokens>
> <bnysp:AcceptsDisclosureStatement/>
> </wsp:All>
>
> As a client, I supply only usernametoken and I expect CXF to complain about
> other missing policies. This does happen but only after *successfully*
> authenticating my user. My expectation is to see an outright rejection from
> CXF, when policy alternatives cannot be satisfied, w/out even authenticating
> my user.
>
> If I substitute a bad user, i see
>
> <soap:Fault>
> <faultcode>soap:Client</faultcode>
> <faultstring>User Authentication Failure</faultstring>
> </soap:Fault>
>
>
> Is my expectation incorrect? OR Am I missing any here?
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/WS-Policy-Execution-order-tp5639774p5639774.html
> Sent from the cxf-user mailing list archive at Nabble.com.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com