OpenSSO Under Replay Attacks
By docteger on Jul 07, 2009
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
SOAPRequestHandlerinterface 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.
MessageIDheader can be optionally included in a SOAP message. The value of the
MessageIDfrom a first request is cached. The
messageIDMapcache uses the
MessageIDvalue to index the local time stamp (stamped when the message is received). Any message requests that use the same
MessageIDand are found to be within a configured time interval will be treated as a duplicate and will be rejected. (If a
MessageIDis not found in the incoming SOAP request, the authenticated subject identifier is used to index the time stamp.)
If implementing the Username Token profile for web services security, you can cache the cryptographically random value of the
nonceelement from each initial request. The
messageIDMapcache uses the
noncevalue to index the creation time stamp (time at which the token was generated). Any message requests that use the same
nonceand are found to be within a configured time interval will be treated as a duplicate and will be rejected.
com.sun.identity.wss.security.handler.WSSCacheRepositoryinterface 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.pluginattribute in the
AMClient.propertiesfile. 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.
- Click the name of the realm in which the agent profile was created.
- Click the Agents tab.
- Click the Web Service Provider tab.
- Click the name of the appropriate web service provider profile.
- Enable Detect Message Replay if applicable.
This enables the MessageID option.
- Enable Detect User Token Replay if applicable.
This enables the nonce option.
- Save the configuration.