You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by "Dave Ortman (JIRA)" <ji...@apache.org> on 2009/06/08 20:46:07 UTC
[jira] Created: (WSS-197) Order of security actions may result in
validation failing
Order of security actions may result in validation failing
----------------------------------------------------------
Key: WSS-197
URL: https://issues.apache.org/jira/browse/WSS-197
Project: WSS4J
Issue Type: Bug
Components: WSS4J Handlers
Affects Versions: 1.5.7
Environment: Tomcat (5.5, 6.0), Spring WS Security 1.5.7
Reporter: Dave Ortman
Assignee: Ruchith Udayanga Fernando
I have found that the order of security actions is particularly relevant when they are processed. That is, the XSD which defines the security header seems to imply no necessary order. However, swapping the order of two elements (in this case, UsernameToken and Signature) will result in the a failure.
I have attached a sample application with a working service and a client that calls that service. It works as expected. It is using Spring Web Security 1.5.7. It is setup to use both a Signature and a UsernameToken.
The problem occurred when a client was calling a service and sending a message in which the UsernameToken element was put *after* the BinarySecurityToken element. I tracked the problem down to the org.apache.ws.security.handler.WSHandler.checkReceiverResults(Vector wsResult, Vector actions) method. This class is being extended by Spring in the Wss4jHandler class - but the checkReceiverResults simply calls super.checkReceiverResults().
This method assumes that the actions and the results are in the same order. However, by altering the order of these elements (either on the client or on the server), this assumption becomes incorrect. What I am not clear on is whether the issue is with the underlying Apache class, or with the Spring class. When checkReceiverResults() is called, should the results and the actions be in the same order?
protected boolean checkReceiverResults(Vector wsResult, Vector actions) {
int resultActions = wsResult.size();
int size = actions.size();
int ai = 0;
for (int i = 0; i < resultActions; i++) {
final Integer actInt = (Integer) ((WSSecurityEngineResult) wsResult
.get(i)).get(WSSecurityEngineResult.TAG_ACTION);
int act = actInt.intValue();
if (act == WSConstants.SC || act == WSConstants.BST) {
continue;
}
if (ai >= size || ((Integer) actions.get(ai++)).intValue() != act) {
return false;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-197) Order of security actions may result in
validation failing
Posted by "Dave Ortman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717721#action_12717721 ]
Dave Ortman commented on WSS-197:
---------------------------------
Ah, thanks Colm. My apologies - I looked, and for some reason I completely overlooked the fact that it had already been addressed.
> Order of security actions may result in validation failing
> ----------------------------------------------------------
>
> Key: WSS-197
> URL: https://issues.apache.org/jira/browse/WSS-197
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Handlers
> Affects Versions: 1.5.7
> Environment: Tomcat (5.5, 6.0), Spring WS Security 1.5.7
> Reporter: Dave Ortman
> Assignee: Colm O hEigeartaigh
> Attachments: book-wss.zip
>
>
> I have found that the order of security actions is particularly relevant when they are processed. That is, the XSD which defines the security header seems to imply no necessary order. However, swapping the order of two elements (in this case, UsernameToken and Signature) will result in the a failure.
> I have attached a sample application with a working service and a client that calls that service. It works as expected. It is using Spring Web Security 1.5.7. It is setup to use both a Signature and a UsernameToken.
> The problem occurred when a client was calling a service and sending a message in which the UsernameToken element was put *after* the BinarySecurityToken element. I tracked the problem down to the org.apache.ws.security.handler.WSHandler.checkReceiverResults(Vector wsResult, Vector actions) method. This class is being extended by Spring in the Wss4jHandler class - but the checkReceiverResults simply calls super.checkReceiverResults().
> This method assumes that the actions and the results are in the same order. However, by altering the order of these elements (either on the client or on the server), this assumption becomes incorrect. What I am not clear on is whether the issue is with the underlying Apache class, or with the Spring class. When checkReceiverResults() is called, should the results and the actions be in the same order?
> protected boolean checkReceiverResults(Vector wsResult, Vector actions) {
> int resultActions = wsResult.size();
> int size = actions.size();
> int ai = 0;
> for (int i = 0; i < resultActions; i++) {
> final Integer actInt = (Integer) ((WSSecurityEngineResult) wsResult
> .get(i)).get(WSSecurityEngineResult.TAG_ACTION);
> int act = actInt.intValue();
> if (act == WSConstants.SC || act == WSConstants.BST) {
> continue;
> }
> if (ai >= size || ((Integer) actions.get(ai++)).intValue() != act) {
> return false;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Resolved: (WSS-197) Order of security actions may result in
validation failing
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh resolved WSS-197.
-------------------------------------
Resolution: Duplicate
Assignee: Colm O hEigeartaigh (was: Ruchith Udayanga Fernando)
Hi Dave,
This has already been fixed and will be in the next release(s), 1.5.8 and 1.6. See WSS-147:
https://issues.apache.org/jira/browse/WSS-147
I added a checkReceiverResultsAnyOrder method to WSHandler to support this behaviour.
Colm.
> Order of security actions may result in validation failing
> ----------------------------------------------------------
>
> Key: WSS-197
> URL: https://issues.apache.org/jira/browse/WSS-197
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Handlers
> Affects Versions: 1.5.7
> Environment: Tomcat (5.5, 6.0), Spring WS Security 1.5.7
> Reporter: Dave Ortman
> Assignee: Colm O hEigeartaigh
> Attachments: book-wss.zip
>
>
> I have found that the order of security actions is particularly relevant when they are processed. That is, the XSD which defines the security header seems to imply no necessary order. However, swapping the order of two elements (in this case, UsernameToken and Signature) will result in the a failure.
> I have attached a sample application with a working service and a client that calls that service. It works as expected. It is using Spring Web Security 1.5.7. It is setup to use both a Signature and a UsernameToken.
> The problem occurred when a client was calling a service and sending a message in which the UsernameToken element was put *after* the BinarySecurityToken element. I tracked the problem down to the org.apache.ws.security.handler.WSHandler.checkReceiverResults(Vector wsResult, Vector actions) method. This class is being extended by Spring in the Wss4jHandler class - but the checkReceiverResults simply calls super.checkReceiverResults().
> This method assumes that the actions and the results are in the same order. However, by altering the order of these elements (either on the client or on the server), this assumption becomes incorrect. What I am not clear on is whether the issue is with the underlying Apache class, or with the Spring class. When checkReceiverResults() is called, should the results and the actions be in the same order?
> protected boolean checkReceiverResults(Vector wsResult, Vector actions) {
> int resultActions = wsResult.size();
> int size = actions.size();
> int ai = 0;
> for (int i = 0; i < resultActions; i++) {
> final Integer actInt = (Integer) ((WSSecurityEngineResult) wsResult
> .get(i)).get(WSSecurityEngineResult.TAG_ACTION);
> int act = actInt.intValue();
> if (act == WSConstants.SC || act == WSConstants.BST) {
> continue;
> }
> if (ai >= size || ((Integer) actions.get(ai++)).intValue() != act) {
> return false;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-197) Order of security actions may result in
validation failing
Posted by "Dave Ortman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Ortman updated WSS-197:
----------------------------
Attachment: book-wss.zip
Within this sample, there is a client process which is performing two actions on outgoing messages : an x509 signature and a UsernameToken. This is being driven by the following Spring interceptors:
<bean id="securityInterceptor"
class="org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor">
<property name="securementActions" value="Signature" />
<property name="securementUsername" value="dortman" />
<property name="securementPassword" value="password" />
<property name="securementSignatureCrypto">
<bean
class="org.springframework.ws.soap.security.wss4j.support.CryptoFactoryBean">
<property name="keyStorePassword" value="password" />
<property name="keyStoreLocation" value="classpath:dortman.jks" />
</bean>
</property>
<property name="securementSignatureKeyIdentifier" value="DirectReference" />
</bean>
<bean id="wss4jWithCorrectUsernameAndPassword"
class="org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor">
<property name="securementActions" value="UsernameToken" />
<property name="securementUsername" value="Ernie" />
<property name="securementPassword" value="Bert" />
</bean>
On the server, the following configuration is verifying these same actions:
<bean id="wsDigCerSecurityInterceptor"
class="org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor">
<property name="validationActions" value="Signature UsernameToken" />
<property name="validationSignatureCrypto">
<bean
class="org.springframework.ws.soap.security.wss4j.support.CryptoFactoryBean">
<property name="keyStorePassword" value="password" />
<property name="keyStoreLocation" value="classpath:dortman.jks" />
</bean>
</property>
<property name="validationCallbackHandler">
<bean
class="org.springframework.ws.soap.security.wss4j.callback.SimplePasswordValidationCallbackHandler">
<property name="users">
<props>
<prop key="Ernie">Bert</prop>
</props>
</property>
</bean>
</property>
</bean>
This works fine. The problem comes when I alter the order of the actions to:
<property name="validationActions" value="UsernameToken Signature" />
This leads to the following error, issued from Spring:
Exception in thread "main" org.springframework.ws.soap.client.SoapFaultClientException: Security processing failed (actions mismatch)
at org.springframework.ws.soap.client.core.SoapFaultMessageResolver.resolveFault(SoapFaultMessageResolver.java:37)
at org.springframework.ws.client.core.WebServiceTemplate.handleFault(WebServiceTemplate.java:738)
at org.springframework.ws.client.core.WebServiceTemplate.doSendAndReceive(WebServiceTemplate.java:564)
Spring is relying on the WSHandler class; here is the order of operations (Spring WS 1.5.7 and WSS4J 1.5.7):
Wss4jHandler(WSHandler).checkReceiverResults(Vector, Vector) line: 280
Wss4jHandler.checkReceiverResults(Vector, Vector) line: 64
Wss4jSecurityInterceptor.validateMessage(SoapMessage, MessageContext) line: 508
Wss4jSecurityInterceptor(AbstractWsSecurityInterceptor).handleRequest(MessageContext, Object) line: 101
SoapMessageDispatcher(MessageDispatcher).dispatch(MessageContext) line: 213
SoapMessageDispatcher(MessageDispatcher).receive(MessageContext) line: 168
Spring is passing in two vectors (results and actions), but the order of them do not match. If I manually reorder them, the validation succeeds.
This problem was noticed when an external process was calling a service, and was appending a UsernameToken element at the end of the security header.
I see that the latest version of the method takes two lists instead of two vectors; but the logic appears the same. Again, I am under the assumption that order should not be relevant in this method, but I am not entirely sure that is the case.
Thanks.
> Order of security actions may result in validation failing
> ----------------------------------------------------------
>
> Key: WSS-197
> URL: https://issues.apache.org/jira/browse/WSS-197
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Handlers
> Affects Versions: 1.5.7
> Environment: Tomcat (5.5, 6.0), Spring WS Security 1.5.7
> Reporter: Dave Ortman
> Assignee: Ruchith Udayanga Fernando
> Attachments: book-wss.zip
>
>
> I have found that the order of security actions is particularly relevant when they are processed. That is, the XSD which defines the security header seems to imply no necessary order. However, swapping the order of two elements (in this case, UsernameToken and Signature) will result in the a failure.
> I have attached a sample application with a working service and a client that calls that service. It works as expected. It is using Spring Web Security 1.5.7. It is setup to use both a Signature and a UsernameToken.
> The problem occurred when a client was calling a service and sending a message in which the UsernameToken element was put *after* the BinarySecurityToken element. I tracked the problem down to the org.apache.ws.security.handler.WSHandler.checkReceiverResults(Vector wsResult, Vector actions) method. This class is being extended by Spring in the Wss4jHandler class - but the checkReceiverResults simply calls super.checkReceiverResults().
> This method assumes that the actions and the results are in the same order. However, by altering the order of these elements (either on the client or on the server), this assumption becomes incorrect. What I am not clear on is whether the issue is with the underlying Apache class, or with the Spring class. When checkReceiverResults() is called, should the results and the actions be in the same order?
> protected boolean checkReceiverResults(Vector wsResult, Vector actions) {
> int resultActions = wsResult.size();
> int size = actions.size();
> int ai = 0;
> for (int i = 0; i < resultActions; i++) {
> final Integer actInt = (Integer) ((WSSecurityEngineResult) wsResult
> .get(i)).get(WSSecurityEngineResult.TAG_ACTION);
> int act = actInt.intValue();
> if (act == WSConstants.SC || act == WSConstants.BST) {
> continue;
> }
> if (ai >= size || ((Integer) actions.get(ai++)).intValue() != act) {
> return false;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Closed: (WSS-197) Order of security actions may result in
validation failing
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh closed WSS-197.
-----------------------------------
> Order of security actions may result in validation failing
> ----------------------------------------------------------
>
> Key: WSS-197
> URL: https://issues.apache.org/jira/browse/WSS-197
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Handlers
> Affects Versions: 1.5.7
> Environment: Tomcat (5.5, 6.0), Spring WS Security 1.5.7
> Reporter: Dave Ortman
> Assignee: Colm O hEigeartaigh
> Attachments: book-wss.zip
>
>
> I have found that the order of security actions is particularly relevant when they are processed. That is, the XSD which defines the security header seems to imply no necessary order. However, swapping the order of two elements (in this case, UsernameToken and Signature) will result in the a failure.
> I have attached a sample application with a working service and a client that calls that service. It works as expected. It is using Spring Web Security 1.5.7. It is setup to use both a Signature and a UsernameToken.
> The problem occurred when a client was calling a service and sending a message in which the UsernameToken element was put *after* the BinarySecurityToken element. I tracked the problem down to the org.apache.ws.security.handler.WSHandler.checkReceiverResults(Vector wsResult, Vector actions) method. This class is being extended by Spring in the Wss4jHandler class - but the checkReceiverResults simply calls super.checkReceiverResults().
> This method assumes that the actions and the results are in the same order. However, by altering the order of these elements (either on the client or on the server), this assumption becomes incorrect. What I am not clear on is whether the issue is with the underlying Apache class, or with the Spring class. When checkReceiverResults() is called, should the results and the actions be in the same order?
> protected boolean checkReceiverResults(Vector wsResult, Vector actions) {
> int resultActions = wsResult.size();
> int size = actions.size();
> int ai = 0;
> for (int i = 0; i < resultActions; i++) {
> final Integer actInt = (Integer) ((WSSecurityEngineResult) wsResult
> .get(i)).get(WSSecurityEngineResult.TAG_ACTION);
> int act = actInt.intValue();
> if (act == WSConstants.SC || act == WSConstants.BST) {
> continue;
> }
> if (ai >= size || ((Integer) actions.get(ai++)).intValue() != act) {
> return false;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org