You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "David Morris (JIRA)" <ji...@apache.org> on 2011/02/15 17:36:57 UTC
[jira] Created: (CXF-3337) Timestamp in WS-Security validation
Timestamp in WS-Security validation
-----------------------------------
Key: CXF-3337
URL: https://issues.apache.org/jira/browse/CXF-3337
Project: CXF
Issue Type: Improvement
Components: WS-* Components
Affects Versions: 2.3.2
Environment: Windows XP/Java 1.6.0_21
Reporter: David Morris
Fix For: 2.3.2
Couple issues discovered during testing of the timestamp:
1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
org.apache.ws.security.handler.WSHandler
protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
...
// Calculate the time that is allowed for the message to travel
Calendar validCreation = Calendar.getInstance();
//added the following line
validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
throws WSSecurityException {
/*
* Perform further checks on the timestamp that was transmitted in
* the header. In the following implementation the timestamp is
* valid if it was created after (now-ttl), where ttl is set on
* server side, not by the client. Note: the method
* verifyTimestamp(Timestamp) allows custom implementations with
* other validation algorithms for subclasses.
*/
// Extract the timestamp action result from the action vector
Vector timestampResults = new Vector();
timestampResults =
WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
if (!timestampResults.isEmpty()) {
for (int i = 0; i < timestampResults.size(); i++) {
WSSecurityEngineResult result =
(WSSecurityEngineResult) timestampResults.get(i);
Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
if (timestamp != null) {
//message expired
if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
LOG.warning("The timestamp could not be validated");
throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
}
//createdDate future dated
Calendar validCreation = Calendar.getInstance();
validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
Calendar createdDate = timestamp.getCreated();
if (createdDate.after(validCreation)) {
LOG.warning("The timestamp createdDate is future dated");
throw new WSSecurityException("The timestamp createdDate cannot be future dated");
}
}
msg.put(TIMESTAMP_RESULT, result);
}
}
}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CXF-3337) Timestamp in WS-Security validation
Posted by "David Morris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Morris updated CXF-3337:
------------------------------
Attachment: screenshot-1.jpg
The time was future dated. The current system time was 8:47 EST
> Timestamp in WS-Security validation
> -----------------------------------
>
> Key: CXF-3337
> URL: https://issues.apache.org/jira/browse/CXF-3337
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3.2
> Environment: Windows XP/Java 1.6.0_21
> Reporter: David Morris
> Fix For: 2.3.2
>
> Attachments: screenshot-1.jpg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Couple issues discovered during testing of the timestamp:
> 1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
> org.apache.ws.security.handler.WSHandler
> protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
> ...
> // Calculate the time that is allowed for the message to travel
> Calendar validCreation = Calendar.getInstance();
> //added the following line
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> 2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
> protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
> throws WSSecurityException {
> /*
> * Perform further checks on the timestamp that was transmitted in
> * the header. In the following implementation the timestamp is
> * valid if it was created after (now-ttl), where ttl is set on
> * server side, not by the client. Note: the method
> * verifyTimestamp(Timestamp) allows custom implementations with
> * other validation algorithms for subclasses.
> */
> // Extract the timestamp action result from the action vector
> Vector timestampResults = new Vector();
> timestampResults =
> WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
> if (!timestampResults.isEmpty()) {
> for (int i = 0; i < timestampResults.size(); i++) {
> WSSecurityEngineResult result =
> (WSSecurityEngineResult) timestampResults.get(i);
> Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
> if (timestamp != null) {
>
> //message expired
> if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
> LOG.warning("The timestamp could not be validated");
> throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
> }
>
> //createdDate future dated
> Calendar validCreation = Calendar.getInstance();
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> Calendar createdDate = timestamp.getCreated();
> if (createdDate.after(validCreation)) {
> LOG.warning("The timestamp createdDate is future dated");
> throw new WSSecurityException("The timestamp createdDate cannot be future dated");
> }
> }
> msg.put(TIMESTAMP_RESULT, result);
> }
> }
> }
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (CXF-3337) Timestamp in WS-Security validation
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-3337.
------------------------------
Resolution: Fixed
Fix Version/s: (was: 2.3.2)
2.3.3
Assignee: Colm O hEigeartaigh
With WSS4J 1.5.11, it's been confirmed fixed. Marking resolved.
> Timestamp in WS-Security validation
> -----------------------------------
>
> Key: CXF-3337
> URL: https://issues.apache.org/jira/browse/CXF-3337
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3.2
> Environment: Windows XP/Java 1.6.0_21
> Reporter: David Morris
> Assignee: Colm O hEigeartaigh
> Fix For: 2.3.3
>
> Attachments: screenshot-1.jpg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Couple issues discovered during testing of the timestamp:
> 1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
> org.apache.ws.security.handler.WSHandler
> protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
> ...
> // Calculate the time that is allowed for the message to travel
> Calendar validCreation = Calendar.getInstance();
> //added the following line
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> 2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
> protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
> throws WSSecurityException {
> /*
> * Perform further checks on the timestamp that was transmitted in
> * the header. In the following implementation the timestamp is
> * valid if it was created after (now-ttl), where ttl is set on
> * server side, not by the client. Note: the method
> * verifyTimestamp(Timestamp) allows custom implementations with
> * other validation algorithms for subclasses.
> */
> // Extract the timestamp action result from the action vector
> Vector timestampResults = new Vector();
> timestampResults =
> WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
> if (!timestampResults.isEmpty()) {
> for (int i = 0; i < timestampResults.size(); i++) {
> WSSecurityEngineResult result =
> (WSSecurityEngineResult) timestampResults.get(i);
> Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
> if (timestamp != null) {
>
> //message expired
> if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
> LOG.warning("The timestamp could not be validated");
> throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
> }
>
> //createdDate future dated
> Calendar validCreation = Calendar.getInstance();
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> Calendar createdDate = timestamp.getCreated();
> if (createdDate.after(validCreation)) {
> LOG.warning("The timestamp createdDate is future dated");
> throw new WSSecurityException("The timestamp createdDate cannot be future dated");
> }
> }
> msg.put(TIMESTAMP_RESULT, result);
> }
> }
> }
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3337) Timestamp in WS-Security validation
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995818#comment-12995818 ]
Colm O hEigeartaigh commented on CXF-3337:
------------------------------------------
Can you confirm the version of the WSS4J jar on the classpath?
Colm.
> Timestamp in WS-Security validation
> -----------------------------------
>
> Key: CXF-3337
> URL: https://issues.apache.org/jira/browse/CXF-3337
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3.2
> Environment: Windows XP/Java 1.6.0_21
> Reporter: David Morris
> Fix For: 2.3.2
>
> Attachments: screenshot-1.jpg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Couple issues discovered during testing of the timestamp:
> 1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
> org.apache.ws.security.handler.WSHandler
> protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
> ...
> // Calculate the time that is allowed for the message to travel
> Calendar validCreation = Calendar.getInstance();
> //added the following line
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> 2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
> protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
> throws WSSecurityException {
> /*
> * Perform further checks on the timestamp that was transmitted in
> * the header. In the following implementation the timestamp is
> * valid if it was created after (now-ttl), where ttl is set on
> * server side, not by the client. Note: the method
> * verifyTimestamp(Timestamp) allows custom implementations with
> * other validation algorithms for subclasses.
> */
> // Extract the timestamp action result from the action vector
> Vector timestampResults = new Vector();
> timestampResults =
> WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
> if (!timestampResults.isEmpty()) {
> for (int i = 0; i < timestampResults.size(); i++) {
> WSSecurityEngineResult result =
> (WSSecurityEngineResult) timestampResults.get(i);
> Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
> if (timestamp != null) {
>
> //message expired
> if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
> LOG.warning("The timestamp could not be validated");
> throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
> }
>
> //createdDate future dated
> Calendar validCreation = Calendar.getInstance();
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> Calendar createdDate = timestamp.getCreated();
> if (createdDate.after(validCreation)) {
> LOG.warning("The timestamp createdDate is future dated");
> throw new WSSecurityException("The timestamp createdDate cannot be future dated");
> }
> }
> msg.put(TIMESTAMP_RESULT, result);
> }
> }
> }
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3337) Timestamp in WS-Security validation
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995858#comment-12995858 ]
Colm O hEigeartaigh commented on CXF-3337:
------------------------------------------
It's available here:
http://repo2.maven.org/maven2/org/apache/ws/security/wss4j/1.5.11/
Colm.
> Timestamp in WS-Security validation
> -----------------------------------
>
> Key: CXF-3337
> URL: https://issues.apache.org/jira/browse/CXF-3337
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3.2
> Environment: Windows XP/Java 1.6.0_21
> Reporter: David Morris
> Fix For: 2.3.2
>
> Attachments: screenshot-1.jpg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Couple issues discovered during testing of the timestamp:
> 1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
> org.apache.ws.security.handler.WSHandler
> protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
> ...
> // Calculate the time that is allowed for the message to travel
> Calendar validCreation = Calendar.getInstance();
> //added the following line
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> 2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
> protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
> throws WSSecurityException {
> /*
> * Perform further checks on the timestamp that was transmitted in
> * the header. In the following implementation the timestamp is
> * valid if it was created after (now-ttl), where ttl is set on
> * server side, not by the client. Note: the method
> * verifyTimestamp(Timestamp) allows custom implementations with
> * other validation algorithms for subclasses.
> */
> // Extract the timestamp action result from the action vector
> Vector timestampResults = new Vector();
> timestampResults =
> WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
> if (!timestampResults.isEmpty()) {
> for (int i = 0; i < timestampResults.size(); i++) {
> WSSecurityEngineResult result =
> (WSSecurityEngineResult) timestampResults.get(i);
> Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
> if (timestamp != null) {
>
> //message expired
> if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
> LOG.warning("The timestamp could not be validated");
> throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
> }
>
> //createdDate future dated
> Calendar validCreation = Calendar.getInstance();
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> Calendar createdDate = timestamp.getCreated();
> if (createdDate.after(validCreation)) {
> LOG.warning("The timestamp createdDate is future dated");
> throw new WSSecurityException("The timestamp createdDate cannot be future dated");
> }
> }
> msg.put(TIMESTAMP_RESULT, result);
> }
> }
> }
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CXF-3337) Timestamp in WS-Security
validation
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995818#comment-12995818 ]
Colm O hEigeartaigh edited comment on CXF-3337 at 2/17/11 2:20 PM:
-------------------------------------------------------------------
Can you confirm the version of the WSS4J jar on the classpath (on the server side?
Colm.
was (Author: coheigea):
Can you confirm the version of the WSS4J jar on the classpath?
Colm.
> Timestamp in WS-Security validation
> -----------------------------------
>
> Key: CXF-3337
> URL: https://issues.apache.org/jira/browse/CXF-3337
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3.2
> Environment: Windows XP/Java 1.6.0_21
> Reporter: David Morris
> Fix For: 2.3.2
>
> Attachments: screenshot-1.jpg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Couple issues discovered during testing of the timestamp:
> 1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
> org.apache.ws.security.handler.WSHandler
> protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
> ...
> // Calculate the time that is allowed for the message to travel
> Calendar validCreation = Calendar.getInstance();
> //added the following line
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> 2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
> protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
> throws WSSecurityException {
> /*
> * Perform further checks on the timestamp that was transmitted in
> * the header. In the following implementation the timestamp is
> * valid if it was created after (now-ttl), where ttl is set on
> * server side, not by the client. Note: the method
> * verifyTimestamp(Timestamp) allows custom implementations with
> * other validation algorithms for subclasses.
> */
> // Extract the timestamp action result from the action vector
> Vector timestampResults = new Vector();
> timestampResults =
> WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
> if (!timestampResults.isEmpty()) {
> for (int i = 0; i < timestampResults.size(); i++) {
> WSSecurityEngineResult result =
> (WSSecurityEngineResult) timestampResults.get(i);
> Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
> if (timestamp != null) {
>
> //message expired
> if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
> LOG.warning("The timestamp could not be validated");
> throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
> }
>
> //createdDate future dated
> Calendar validCreation = Calendar.getInstance();
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> Calendar createdDate = timestamp.getCreated();
> if (createdDate.after(validCreation)) {
> LOG.warning("The timestamp createdDate is future dated");
> throw new WSSecurityException("The timestamp createdDate cannot be future dated");
> }
> }
> msg.put(TIMESTAMP_RESULT, result);
> }
> }
> }
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3337) Timestamp in WS-Security validation
Posted by "David Morris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995821#comment-12995821 ]
David Morris commented on CXF-3337:
-----------------------------------
Sure. We using Maven for the builds. In the pom.xml the version of wss4j is 1.5.10.
> Timestamp in WS-Security validation
> -----------------------------------
>
> Key: CXF-3337
> URL: https://issues.apache.org/jira/browse/CXF-3337
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3.2
> Environment: Windows XP/Java 1.6.0_21
> Reporter: David Morris
> Fix For: 2.3.2
>
> Attachments: screenshot-1.jpg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Couple issues discovered during testing of the timestamp:
> 1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
> org.apache.ws.security.handler.WSHandler
> protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
> ...
> // Calculate the time that is allowed for the message to travel
> Calendar validCreation = Calendar.getInstance();
> //added the following line
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> 2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
> protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
> throws WSSecurityException {
> /*
> * Perform further checks on the timestamp that was transmitted in
> * the header. In the following implementation the timestamp is
> * valid if it was created after (now-ttl), where ttl is set on
> * server side, not by the client. Note: the method
> * verifyTimestamp(Timestamp) allows custom implementations with
> * other validation algorithms for subclasses.
> */
> // Extract the timestamp action result from the action vector
> Vector timestampResults = new Vector();
> timestampResults =
> WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
> if (!timestampResults.isEmpty()) {
> for (int i = 0; i < timestampResults.size(); i++) {
> WSSecurityEngineResult result =
> (WSSecurityEngineResult) timestampResults.get(i);
> Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
> if (timestamp != null) {
>
> //message expired
> if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
> LOG.warning("The timestamp could not be validated");
> throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
> }
>
> //createdDate future dated
> Calendar validCreation = Calendar.getInstance();
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> Calendar createdDate = timestamp.getCreated();
> if (createdDate.after(validCreation)) {
> LOG.warning("The timestamp createdDate is future dated");
> throw new WSSecurityException("The timestamp createdDate cannot be future dated");
> }
> }
> msg.put(TIMESTAMP_RESULT, result);
> }
> }
> }
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3337) Timestamp in WS-Security validation
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995839#comment-12995839 ]
Colm O hEigeartaigh commented on CXF-3337:
------------------------------------------
The issue https://issues.apache.org/jira/browse/WSS-262 was fixed in WSS4J 1.5.11. Could you try the testcase with that jar?
Colm.
> Timestamp in WS-Security validation
> -----------------------------------
>
> Key: CXF-3337
> URL: https://issues.apache.org/jira/browse/CXF-3337
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3.2
> Environment: Windows XP/Java 1.6.0_21
> Reporter: David Morris
> Fix For: 2.3.2
>
> Attachments: screenshot-1.jpg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Couple issues discovered during testing of the timestamp:
> 1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
> org.apache.ws.security.handler.WSHandler
> protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
> ...
> // Calculate the time that is allowed for the message to travel
> Calendar validCreation = Calendar.getInstance();
> //added the following line
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> 2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
> protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
> throws WSSecurityException {
> /*
> * Perform further checks on the timestamp that was transmitted in
> * the header. In the following implementation the timestamp is
> * valid if it was created after (now-ttl), where ttl is set on
> * server side, not by the client. Note: the method
> * verifyTimestamp(Timestamp) allows custom implementations with
> * other validation algorithms for subclasses.
> */
> // Extract the timestamp action result from the action vector
> Vector timestampResults = new Vector();
> timestampResults =
> WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
> if (!timestampResults.isEmpty()) {
> for (int i = 0; i < timestampResults.size(); i++) {
> WSSecurityEngineResult result =
> (WSSecurityEngineResult) timestampResults.get(i);
> Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
> if (timestamp != null) {
>
> //message expired
> if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
> LOG.warning("The timestamp could not be validated");
> throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
> }
>
> //createdDate future dated
> Calendar validCreation = Calendar.getInstance();
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> Calendar createdDate = timestamp.getCreated();
> if (createdDate.after(validCreation)) {
> LOG.warning("The timestamp createdDate is future dated");
> throw new WSSecurityException("The timestamp createdDate cannot be future dated");
> }
> }
> msg.put(TIMESTAMP_RESULT, result);
> }
> }
> }
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3337) Timestamp in WS-Security validation
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995907#comment-12995907 ]
Colm O hEigeartaigh commented on CXF-3337:
------------------------------------------
No, the errors that are sent back to the client are deliberately uninformative, to prevent a malicious client from gaining too much information about the authentication process.
Colm.
> Timestamp in WS-Security validation
> -----------------------------------
>
> Key: CXF-3337
> URL: https://issues.apache.org/jira/browse/CXF-3337
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3.2
> Environment: Windows XP/Java 1.6.0_21
> Reporter: David Morris
> Fix For: 2.3.2
>
> Attachments: screenshot-1.jpg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Couple issues discovered during testing of the timestamp:
> 1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
> org.apache.ws.security.handler.WSHandler
> protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
> ...
> // Calculate the time that is allowed for the message to travel
> Calendar validCreation = Calendar.getInstance();
> //added the following line
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> 2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
> protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
> throws WSSecurityException {
> /*
> * Perform further checks on the timestamp that was transmitted in
> * the header. In the following implementation the timestamp is
> * valid if it was created after (now-ttl), where ttl is set on
> * server side, not by the client. Note: the method
> * verifyTimestamp(Timestamp) allows custom implementations with
> * other validation algorithms for subclasses.
> */
> // Extract the timestamp action result from the action vector
> Vector timestampResults = new Vector();
> timestampResults =
> WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
> if (!timestampResults.isEmpty()) {
> for (int i = 0; i < timestampResults.size(); i++) {
> WSSecurityEngineResult result =
> (WSSecurityEngineResult) timestampResults.get(i);
> Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
> if (timestamp != null) {
>
> //message expired
> if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
> LOG.warning("The timestamp could not be validated");
> throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
> }
>
> //createdDate future dated
> Calendar validCreation = Calendar.getInstance();
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> Calendar createdDate = timestamp.getCreated();
> if (createdDate.after(validCreation)) {
> LOG.warning("The timestamp createdDate is future dated");
> throw new WSSecurityException("The timestamp createdDate cannot be future dated");
> }
> }
> msg.put(TIMESTAMP_RESULT, result);
> }
> }
> }
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3337) Timestamp in WS-Security validation
Posted by "David Morris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995901#comment-12995901 ]
David Morris commented on CXF-3337:
-----------------------------------
Thanks Colm. Validated that future timestamps are rejected in wss4j1.5.11. However org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor (using cxf version 2.3.2) throws a 'The message has expired' soap fault (after the call to WSHandler). Should this be more descriptive for future dated timestamps? (i.e. 'The timestamp cannot be future dated') The WSHandler verifies that it is a valid timestamp and within the valid time range(boolean).
> Timestamp in WS-Security validation
> -----------------------------------
>
> Key: CXF-3337
> URL: https://issues.apache.org/jira/browse/CXF-3337
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3.2
> Environment: Windows XP/Java 1.6.0_21
> Reporter: David Morris
> Fix For: 2.3.2
>
> Attachments: screenshot-1.jpg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Couple issues discovered during testing of the timestamp:
> 1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
> org.apache.ws.security.handler.WSHandler
> protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
> ...
> // Calculate the time that is allowed for the message to travel
> Calendar validCreation = Calendar.getInstance();
> //added the following line
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> 2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
> protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
> throws WSSecurityException {
> /*
> * Perform further checks on the timestamp that was transmitted in
> * the header. In the following implementation the timestamp is
> * valid if it was created after (now-ttl), where ttl is set on
> * server side, not by the client. Note: the method
> * verifyTimestamp(Timestamp) allows custom implementations with
> * other validation algorithms for subclasses.
> */
> // Extract the timestamp action result from the action vector
> Vector timestampResults = new Vector();
> timestampResults =
> WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
> if (!timestampResults.isEmpty()) {
> for (int i = 0; i < timestampResults.size(); i++) {
> WSSecurityEngineResult result =
> (WSSecurityEngineResult) timestampResults.get(i);
> Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
> if (timestamp != null) {
>
> //message expired
> if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
> LOG.warning("The timestamp could not be validated");
> throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
> }
>
> //createdDate future dated
> Calendar validCreation = Calendar.getInstance();
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> Calendar createdDate = timestamp.getCreated();
> if (createdDate.after(validCreation)) {
> LOG.warning("The timestamp createdDate is future dated");
> throw new WSSecurityException("The timestamp createdDate cannot be future dated");
> }
> }
> msg.put(TIMESTAMP_RESULT, result);
> }
> }
> }
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3337) Timestamp in WS-Security validation
Posted by "David Morris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995809#comment-12995809 ]
David Morris commented on CXF-3337:
-----------------------------------
Issue #2. still occurs after changing the TimeZone to UTC. The time is still future dated. The WebService client can be generated from the WSDL, use another webservice stack and be customized. Therefore the future date timestamp is something that needs to be checked on the server side. We use SOAPUI to test the 'not so happy path'. Thanks!
> Timestamp in WS-Security validation
> -----------------------------------
>
> Key: CXF-3337
> URL: https://issues.apache.org/jira/browse/CXF-3337
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3.2
> Environment: Windows XP/Java 1.6.0_21
> Reporter: David Morris
> Fix For: 2.3.2
>
> Attachments: screenshot-1.jpg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Couple issues discovered during testing of the timestamp:
> 1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
> org.apache.ws.security.handler.WSHandler
> protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
> ...
> // Calculate the time that is allowed for the message to travel
> Calendar validCreation = Calendar.getInstance();
> //added the following line
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> 2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
> protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
> throws WSSecurityException {
> /*
> * Perform further checks on the timestamp that was transmitted in
> * the header. In the following implementation the timestamp is
> * valid if it was created after (now-ttl), where ttl is set on
> * server side, not by the client. Note: the method
> * verifyTimestamp(Timestamp) allows custom implementations with
> * other validation algorithms for subclasses.
> */
> // Extract the timestamp action result from the action vector
> Vector timestampResults = new Vector();
> timestampResults =
> WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
> if (!timestampResults.isEmpty()) {
> for (int i = 0; i < timestampResults.size(); i++) {
> WSSecurityEngineResult result =
> (WSSecurityEngineResult) timestampResults.get(i);
> Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
> if (timestamp != null) {
>
> //message expired
> if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
> LOG.warning("The timestamp could not be validated");
> throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
> }
>
> //createdDate future dated
> Calendar validCreation = Calendar.getInstance();
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> Calendar createdDate = timestamp.getCreated();
> if (createdDate.after(validCreation)) {
> LOG.warning("The timestamp createdDate is future dated");
> throw new WSSecurityException("The timestamp createdDate cannot be future dated");
> }
> }
> msg.put(TIMESTAMP_RESULT, result);
> }
> }
> }
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3337) Timestamp in WS-Security validation
Posted by "David Morris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995918#comment-12995918 ]
David Morris commented on CXF-3337:
-----------------------------------
Makes sense to me. Ok, I will let our validation team know that this soap fault message is a works as designed (WAD). Working on another competitors web services stack, we did get the 'The timestamp cannot be future dated'. ;)
> Timestamp in WS-Security validation
> -----------------------------------
>
> Key: CXF-3337
> URL: https://issues.apache.org/jira/browse/CXF-3337
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3.2
> Environment: Windows XP/Java 1.6.0_21
> Reporter: David Morris
> Fix For: 2.3.2
>
> Attachments: screenshot-1.jpg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Couple issues discovered during testing of the timestamp:
> 1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
> org.apache.ws.security.handler.WSHandler
> protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
> ...
> // Calculate the time that is allowed for the message to travel
> Calendar validCreation = Calendar.getInstance();
> //added the following line
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> 2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
> protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
> throws WSSecurityException {
> /*
> * Perform further checks on the timestamp that was transmitted in
> * the header. In the following implementation the timestamp is
> * valid if it was created after (now-ttl), where ttl is set on
> * server side, not by the client. Note: the method
> * verifyTimestamp(Timestamp) allows custom implementations with
> * other validation algorithms for subclasses.
> */
> // Extract the timestamp action result from the action vector
> Vector timestampResults = new Vector();
> timestampResults =
> WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
> if (!timestampResults.isEmpty()) {
> for (int i = 0; i < timestampResults.size(); i++) {
> WSSecurityEngineResult result =
> (WSSecurityEngineResult) timestampResults.get(i);
> Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
> if (timestamp != null) {
>
> //message expired
> if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
> LOG.warning("The timestamp could not be validated");
> throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
> }
>
> //createdDate future dated
> Calendar validCreation = Calendar.getInstance();
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> Calendar createdDate = timestamp.getCreated();
> if (createdDate.after(validCreation)) {
> LOG.warning("The timestamp createdDate is future dated");
> throw new WSSecurityException("The timestamp createdDate cannot be future dated");
> }
> }
> msg.put(TIMESTAMP_RESULT, result);
> }
> }
> }
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3337) Timestamp in WS-Security validation
Posted by "David Morris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995834#comment-12995834 ]
David Morris commented on CXF-3337:
-----------------------------------
Revisited pom.xml file:
I had wss4j version 1.5.10 and cxf-rt-ws-security.2.3.1. Removed wss4j 1.5.10. re-packaged war file and deployed on tomcat 7.0. Still getting same issue.
Verified the server is now running cxf-rt-ws-security.2.3.1 and not wss4j 1.5.10.
> Timestamp in WS-Security validation
> -----------------------------------
>
> Key: CXF-3337
> URL: https://issues.apache.org/jira/browse/CXF-3337
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3.2
> Environment: Windows XP/Java 1.6.0_21
> Reporter: David Morris
> Fix For: 2.3.2
>
> Attachments: screenshot-1.jpg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Couple issues discovered during testing of the timestamp:
> 1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
> org.apache.ws.security.handler.WSHandler
> protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
> ...
> // Calculate the time that is allowed for the message to travel
> Calendar validCreation = Calendar.getInstance();
> //added the following line
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> 2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
> protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
> throws WSSecurityException {
> /*
> * Perform further checks on the timestamp that was transmitted in
> * the header. In the following implementation the timestamp is
> * valid if it was created after (now-ttl), where ttl is set on
> * server side, not by the client. Note: the method
> * verifyTimestamp(Timestamp) allows custom implementations with
> * other validation algorithms for subclasses.
> */
> // Extract the timestamp action result from the action vector
> Vector timestampResults = new Vector();
> timestampResults =
> WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
> if (!timestampResults.isEmpty()) {
> for (int i = 0; i < timestampResults.size(); i++) {
> WSSecurityEngineResult result =
> (WSSecurityEngineResult) timestampResults.get(i);
> Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
> if (timestamp != null) {
>
> //message expired
> if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
> LOG.warning("The timestamp could not be validated");
> throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
> }
>
> //createdDate future dated
> Calendar validCreation = Calendar.getInstance();
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> Calendar createdDate = timestamp.getCreated();
> if (createdDate.after(validCreation)) {
> LOG.warning("The timestamp createdDate is future dated");
> throw new WSSecurityException("The timestamp createdDate cannot be future dated");
> }
> }
> msg.put(TIMESTAMP_RESULT, result);
> }
> }
> }
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3337) Timestamp in WS-Security validation
Posted by "David Morris (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995851#comment-12995851 ]
David Morris commented on CXF-3337:
-----------------------------------
Thanks. I will check this locally in my pom file. Any idea when the Maven public repository will be updated to include wss4j.1.5.11?
> Timestamp in WS-Security validation
> -----------------------------------
>
> Key: CXF-3337
> URL: https://issues.apache.org/jira/browse/CXF-3337
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3.2
> Environment: Windows XP/Java 1.6.0_21
> Reporter: David Morris
> Fix For: 2.3.2
>
> Attachments: screenshot-1.jpg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Couple issues discovered during testing of the timestamp:
> 1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
> org.apache.ws.security.handler.WSHandler
> protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
> ...
> // Calculate the time that is allowed for the message to travel
> Calendar validCreation = Calendar.getInstance();
> //added the following line
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> 2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
> protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
> throws WSSecurityException {
> /*
> * Perform further checks on the timestamp that was transmitted in
> * the header. In the following implementation the timestamp is
> * valid if it was created after (now-ttl), where ttl is set on
> * server side, not by the client. Note: the method
> * verifyTimestamp(Timestamp) allows custom implementations with
> * other validation algorithms for subclasses.
> */
> // Extract the timestamp action result from the action vector
> Vector timestampResults = new Vector();
> timestampResults =
> WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
> if (!timestampResults.isEmpty()) {
> for (int i = 0; i < timestampResults.size(); i++) {
> WSSecurityEngineResult result =
> (WSSecurityEngineResult) timestampResults.get(i);
> Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
> if (timestamp != null) {
>
> //message expired
> if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
> LOG.warning("The timestamp could not be validated");
> throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
> }
>
> //createdDate future dated
> Calendar validCreation = Calendar.getInstance();
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> Calendar createdDate = timestamp.getCreated();
> if (createdDate.after(validCreation)) {
> LOG.warning("The timestamp createdDate is future dated");
> throw new WSSecurityException("The timestamp createdDate cannot be future dated");
> }
> }
> msg.put(TIMESTAMP_RESULT, result);
> }
> }
> }
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3337) Timestamp in WS-Security validation
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995749#comment-12995749 ]
Colm O hEigeartaigh commented on CXF-3337:
------------------------------------------
> 1.) ZULU time must be used for timestamp comparisions.
I merged a fix to WSS4J to set the TimeZone to be UTC (not GMT) for validation.
> 2.) Need to check for future dated timestamps.
The code is already there in WSHandler...possibly your testcase was not working because the timezone was not being set to UTC?
Calendar validCreation = Calendar.getInstance();
validCreation.setTimeZone(TimeZone.getTimeZone("UTC"));
Calendar cre = timestamp.getCreated();
if (cre != null && cre.after(validCreation)) {
....
}
Colm.
> Timestamp in WS-Security validation
> -----------------------------------
>
> Key: CXF-3337
> URL: https://issues.apache.org/jira/browse/CXF-3337
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3.2
> Environment: Windows XP/Java 1.6.0_21
> Reporter: David Morris
> Fix For: 2.3.2
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Couple issues discovered during testing of the timestamp:
> 1.) ZULU time must be used for timestamp comparisions. Cannot make the assumption that the web services client is in the same time zone as the server. Changed the following code:
> org.apache.ws.security.handler.WSHandler
> protected boolean verifyTimestamp(Timestamp timestamp, int timeToLive) method
> ...
> // Calculate the time that is allowed for the message to travel
> Calendar validCreation = Calendar.getInstance();
> //added the following line
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> 2.) Need to check for future dated timestamps. During our validation using SOAPUI, the timestamps in the request can future dated by the validation team. Changed the following code in org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.java:
> protected void checkTimestamps(SoapMessage msg, RequestData reqData, Vector wsResult)
> throws WSSecurityException {
> /*
> * Perform further checks on the timestamp that was transmitted in
> * the header. In the following implementation the timestamp is
> * valid if it was created after (now-ttl), where ttl is set on
> * server side, not by the client. Note: the method
> * verifyTimestamp(Timestamp) allows custom implementations with
> * other validation algorithms for subclasses.
> */
> // Extract the timestamp action result from the action vector
> Vector timestampResults = new Vector();
> timestampResults =
> WSSecurityUtil.fetchAllActionResults(wsResult, WSConstants.TS, timestampResults);
> if (!timestampResults.isEmpty()) {
> for (int i = 0; i < timestampResults.size(); i++) {
> WSSecurityEngineResult result =
> (WSSecurityEngineResult) timestampResults.get(i);
> Timestamp timestamp = (Timestamp)result.get(WSSecurityEngineResult.TAG_TIMESTAMP);
> if (timestamp != null) {
>
> //message expired
> if(!verifyTimestamp(timestamp, decodeTimeToLive(reqData))) {
> LOG.warning("The timestamp could not be validated");
> throw new WSSecurityException(WSSecurityException.MESSAGE_EXPIRED);
> }
>
> //createdDate future dated
> Calendar validCreation = Calendar.getInstance();
> validCreation.setTimeZone(TimeZone.getTimeZone("GMT")); //ZULU Time
> Calendar createdDate = timestamp.getCreated();
> if (createdDate.after(validCreation)) {
> LOG.warning("The timestamp createdDate is future dated");
> throw new WSSecurityException("The timestamp createdDate cannot be future dated");
> }
> }
> msg.put(TIMESTAMP_RESULT, result);
> }
> }
> }
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira