Explanation/Reference:
In order to avoid man-in-the-middle attacks a security framework must have capabilities such as:
* Logging in users without the need to type passwords or PINs (not D)
* Dynamically challenging the user for different information, e.g., asking a random question for which only the user will know the answer
* Encrypting and signing transmissions from the client to the back end server (not A)
* Detecting replays using embedded transaction ids or timestamps (not E)
* Presenting proof to the user that the site they are visiting is authentic Propagating a single proof object, or assertion, can be susceptible to man-in-the-middle attacks and replay attacks. If a rogue entity observes an assertion, it could reuse that assertion for illegitimate requests.
Possible solutions include:
* (not B) Invalidate the assertion after every request. In the case of chained SOA Services, service providers must verify each assertion they receives with the authority. The authority can invalidate assertions in its internal cache. Any future verifications with the same assertion would fail. SOA Service providers would need to obtain a new assertion in order to make subsequent service requests. This solves both types of problems mentioned above.
* (not E) Reduce and enforce the assertion's time to live attribute. This would narrow the window of opportunity to reuse an assertion. The assertion would have to be captured and reused in a short period of time (programmatically vs. manually).
While this limits the potential for man-in-the-middle attacks, it's not as effective for replay attacks
* Require the signature of a trusted service consumer (client application) in addition to the signed assertion. The caller's signature should cover the assertion to bind it to the message. If all service consumers are required to sign their request messages, then service providers can be shielded from rogue clients, thereby preventing man-in-the-middle attacks.
This solution would need to be enhanced to solve replay attacks. One option is to include a unique request id, timestamp, or sequence number in the request. The target resource could maintain a cache of ids and refuse duplicate requests. A common request id service could be created to issue unique request ids and validate all requests that are received within the security domain Reference: Oracle Reference Architecture, Security , Release 3.1