[
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
