« Previous day (Jul 7, 2009) | Main | Next day (Jul 9, 2009) »
Wednesday Jul 08, 2009

OpenSSO Under Replay Attacks

A replay attack occurs when a valid data transmission is maliciously intercepted and retransmitted. Digital signatures alone do not provide protection against replay attacks in web services communications as a signed message can still be recorded and resent. The WS-Security specification recommends a number of options to protect against replay attacks; from those options, the OpenSSO web services framework has implemented the use of the time stamp. That said, here is some preliminary information about preventing replay attacks using OpenSSO.

More to come. Below is subject to tweak. But you got it first.
The OpenSSO web services security framework is driven primarily by security agents that install on deployed web containers remote to OpenSSO. The security agent accesses the web services security framework using the SOAPRequestHandler interface in the Client SDK to validate SOAP messages and authenticate against OpenSSO. As part of the process, digital signatures and encryptions are validated and, following that, the message's time stamp is processed to check for replay attacks. The time stamp can be processed using either of the following options.
  • MessageID
    The WS-Addressing MessageID header can be optionally included in a SOAP message. The value of the MessageID from a first request is cached. The messageIDMap cache uses the MessageID value to index the local time stamp (stamped when the message is received). Any message requests that use the same MessageID and are found to be within a configured time interval will be treated as a duplicate and will be rejected. (If a MessageID is not found in the incoming SOAP request, the authenticated subject identifier is used to index the time stamp.)

  • nonce
    If implementing the Username Token profile for web services security, you can cache the cryptographically random value of the nonce element from each initial request. The messageIDMap cache uses the nonce value to index the creation time stamp (time at which the token was generated). Any message requests that use the same nonce and are found to be within a configured time interval will be treated as a duplicate and will be rejected.

The Client SDK can not use the high availability and failover features of OpenSSO. Thus, the solution is to provide an interface to use for persistent storage of the state of the cache on the web services provider side. The com.sun.identity.wss.security.handler.WSSCacheRepository interface assumes a repository has already been configured and the cache can be persistently stored in it. There is no out of the box implementation for this interface but the name of the implementation class, if developed, needs to be entered as the value of the com.sun.identity.wss.security.cacherepository.plugin attribute in the AMClient.properties file. To enable the replay attack prevention feature, you create a web services provider agent profile under the appropriate realm. Once the profile has been created, follow this procedure.
  1. Click the name of the realm in which the agent profile was created.
  2. Click the Agents tab.
  3. Click the Web Service Provider tab.
  4. Click the name of the appropriate web service provider profile.
  5. Enable Detect Message Replay if applicable.
    This enables the MessageID option.
  6. Enable Detect User Token Replay if applicable.
    This enables the nonce option.
  7. Save the configuration.
You also need to add the web service client instance of OpenSSO and the Security Token Service instance of OpenSSO as a value in the Trusted Server listing. The cache is cleaned up using a periodic cleanup thread with a configurable time interval.

And now ABBA, a group that knows something about being Under Attack.

Posted at 12:00AM Jul 08, 2009 by Michael Teger in Sun  |  Comments[0]