This isn't worth a patch but there is a comment in the PolicyBasedResultsValidator that suggests the method verifyTimestamp allows customer implementations by subclasses. Unfortunately the method 'verifyTimestamp' is private.
The flow for checking security headers seems a little odd to me at the moment, though maybe I'm missing something. In RampartEngine, a WSSecurityEngine is spun up to process the security headers. That in turn will go through each security header and as long as there is an entry in the wssConfig then the header will be verified via the processor. In the case of a timestamp, the processor simply checks for an expired header and throws a WSSecurityException. What happens if I decide that in my policy I have no requirement for a timestamp? The request would still get rejected regardless if an invalid timestamp is present. It feels like the policy implementation is bolted onto the end of the process rather than \driving\ the processing of security headers. Can anyone clarify? Cheers, James. ----------------------------------------- Egg is a trading name of the Egg group of companies which includes: Egg plc (reg no 2448340), Egg Financial Intermediation Ltd (reg no 3828289), and Egg Banking plc (reg no 2999842). Egg Banking plc and Egg Financial Intermediation Ltd are authorised and regulated by the Financial Services Authority (FSA) and are entered in the FSA register under numbers 205621 and 309551 respectively. These members of the Egg group are registered in England and Wales. Registered office: Citigroup Centre, Canada Square, London E14 5LB. This e-mail is confidential and for use by the addressee only. If you are not the intended recipient of this e-mail and have received it in error, please return the message to the sender by replying to it and then delete it from your mailbox. Internet e-mails are not necessarily secure. The Egg group of companies do not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by the Egg group of companies in this regard and the recipient should carry out such virus and other checks as it considers appropriate. This communication does not create or modify any contract.
