This section is informative.
Since the federated authentication process involves coordination between multiple components, including the CSP which now acts as an IdP, there are additional opportunities for attackers to compromise federated identity transactions. This section summarizes many of the attacks and mitigations applicable to federation.
As in non-federated authentication, attackers’ motivations are typically to gain access (or a greater level of access) to a resource or service provided by an RP. Attackers may also attempt to impersonate a subscriber. Rogue or compromised IdPs, RPs, user agents (e.g., browsers), and parties outside of a typical federation transaction are potential attackers. To accomplish their attack, they might intercept or modify assertions and assertion references. Further, two or more entities may attempt to subvert federation protocols by directly compromising the integrity or confidentiality of the assertion data. For the purpose of these types of threats, any authorized parties who attempt to exceed their privileges are considered attackers.
| Federation Threats/Attacks | Description | Examples |
|---|---|---|
| Assertion Manufacture or Modification | The attacker generates a false assertion | Compromised IdP asserts identity of a claimant who has not properly authenticated |
| The attacker modifies an existing assertion | Compromised proxy that changes AAL of an authentication assertion | |
| Assertion Disclosure | Assertion visible to third party | Network monitoring reveals subscriber address of record to an outside party |
| Assertion Repudiation by the IdP | IdP later claims not to have signed transaction | User engages in fraudulent credit card transaction at RP, IdP claims not to have logged them in |
| Assertion Repudiation by the Subscriber | Subscriber claims not to have performed transaction | User agreement (e.g., contract) cannot be enforced |
| Assertion Redirect | Assertion can be used in unintended context | Compromised user agent passes assertion to attacker who uses it elsewhere |
| Assertion Reuse | Assertion can be used more than once with same RP | Intercepted assertion used by attacker to authenticate their own session |
| Assertion Substitution | Attacker uses an assertion intended for a different subscriber | Session hijacking attack between IdP and RP |
Mechanisms that assist in mitigating the above threats are identified in Table 3.
Table 3 Mitigating Federation Threats
| Federation Threat/Attack | Threat Mitigation Mechanisms | Normative Reference(s) |
|---|---|---|
| Assertion Manufacture or Modification | Cryptographically sign the assertion at IdP and verify at RP | 4.1, 6 |
| Send assertion over an authenticated protected channel authenticating the IdP | 7.1, 7.2 | |
| Include a non-guessable random identifier in the assertion | 6.2.1 | |
| Assertion Disclosure | Send assertion over an authenticated protected channel authenticating the RP | 7.1, 7.2 |
| Encrypt assertion for a specific RP (may be accomplished by use of a mutually authenticated protected channel) | 6.2.3 | |
| Assertion Repudiation by the IdP | Cryptographically sign the assertion at the IdP with a key that supports non-repudiation; verify signature at RP | 6.2.2 |
| Assertion Repudiation by the Subscriber | Issue assertions with bound authenticators; proof of possession of bound authenticator verifies subscriber’s participation to the RP | 6.1.2 |
| Assertion Redirect | Include identity of the RP (“audience”) for which the assertion is issued in its signed content; RP verifies that they are intended recipient | 6, 7.1, 7.2 |
| Assertion Reuse | Include an issuance timestamp with short validity period in the signed content of the assertion; RP verifies validity | 6, 7.1, 7.2 |
| RP keeps track of assertions consumed within a configurable time window to ensure that a given assertion is not used more than once. | 6.2.1 | |
| Assertion Substitution | Ensure that assertions contain a reference to the assertion request or some other nonce that was cryptographically bound to the request by the RP | 6 |
| Send assertions in the same authenticated protected channel as the request, such as in the back-channel model | 7.1 |