This section is informative.
Since the federated authentication process involves coordination between multiple components, including the CSP, IdP, and RP, there are additional opportunities for attackers to compromise federated identity transactions and additional ramifications for successful attacks. This section summarizes many of the attacks and mitigations that are 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. Furthermore, two or more entities may attempt to subvert federation protocols by directly compromising the integrity or confidentiality of the assertion data. For these types of threats, any authorized parties who attempt to exceed their privileges are considered attackers.
In federated systems, successful attacks on the IdP can propagate through to the RPs that rely on that IdP for identity and security information. Consequently, an attack against the IdP that targets one agency’s RP could potentially move laterally to another agency’s RP. To mitigate these attacks, RPs need to maintain independent monitoring and threat evaluation capabilities to identify malicious or compromised accounts. Additionally, maintaining information or shared signaling capabilities with appropriate privacy controls can facilitate investigation and remediation at the IdP or CSP and other potentially impacted RPs.
Deviations in identity proofing practices between CSPs and between subscriber accounts within a single CSP are inevitable. CSPs and IdPs need to maintain capabilities to convey information regarding the controls applied to each account to support RP decision-making and investigation when appropriate.
| Federation Threats/Attacks | Description | Examples |
|---|---|---|
| Assertion Manufacture or Modification | The attacker generates a false assertion | Compromised IdP asserts the identity of a claimant who has not properly authenticated |
| The attacker modifies an existing assertion | Compromised proxy that changes the AAL of an authentication assertion | |
| Assertion Disclosure | The assertion is visible to a third party | Network monitoring reveals a subscriber address of record to an outside party |
| Assertion Repudiation by the IdP | The IdP later claims not to have signed the transaction | User engages in a fraudulent credit card transaction at the RP, and the IdP claims not to have logged them in |
| Assertion Repudiation by the Subscriber | The subscriber claims not to have performed the transaction | The user agreement (e.g., contract) cannot be enforced |
| Assertion Redirect | The assertion can be used in unintended context | A compromised user agent passes the assertion to an attacker who uses it elsewhere |
| Assertion Reuse | The assertion can be used more than once with same RP | An intercepted assertion is used by an attacker to authenticate their own session |
| Assertion Substitution | The attacker uses an assertion that is intended for a different subscriber | There is a session hijack attack between the IdP and RP |
| Revoked or Stale Attributes | The attacker exploits an RP’s usage of attributes | An attribute bundle with a revoked email address is presented to an RP to allow an attacker to use that email address with the RP |
\clearpage
In addition to the security controls discussed in Sec. 3.11, mechanisms that assist in mitigating the above threats are identified in Table 4.
Table 4. Mitigating federation threats
| Federation Threat/Attack | Threat Mitigation Mechanisms | Normative Reference(s) |
|---|---|---|
| Assertion Manufacture or Modification | Cryptographically sign the assertion at the IdP and verify at the RP | 3.5, 3.12.2 |
| Send the assertion over an authenticated protected channel that authenticates the IdP | 4.11 | |
| Include a non-guessable random identifier in the assertion | 3.12.1 | |
| Assertion Disclosure | Send the assertion over an authenticated protected channel that authenticates the RP | 4.9, 5.8 |
| Encrypt the assertion for a specific RP (may be accomplished using a mutually authenticated protected channel) | 3.12.3 | |
| Assertion Repudiation by the IdP | Cryptographically sign the assertion at the IdP with a signing key that supports non-repudiation, and verify the signature at the RP | 3.12.2 |
| Assertion Repudiation by the Subscriber | Issue holder-of-key assertions or assertions with bound authenticators; proof of possession of the authenticator verifies the subscriber’s participation to the RP | 3.14 3.15 |
| Assertion Redirect | Include the identity of the RP for which the assertion is issued in its signed content; the RP verifies that they are the intended recipient | 3.12.4 |
| Assertion Reuse | Include an issuance timestamp with a short validity period in the signed content of the assertion; the RP verifies the time period | 4.9, 5.8 |
| The RP keeps track of assertions that are consumed within a configurable time window to ensure that a given assertion is not used more than once | 3.12.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 | 4.9, 5.8 |
| Send assertions in the same authenticated protected channel as the request (e.g., back-channel presentation) | 4.11.1 | |
| Revoked or Stale Attributes | Ensure fresh assertions with valid time windows | 4.9, 5.8 |
| Enable checking validity of attribute bundles independently of assertions | 5.1.1 |