|
+4.9 Assertion Contents |
4.9 Assertion ContentsAn assertion is a statement from the IdP to the RP that contains information about an authentication event for an authenticated subscriber as well as a set of attribute values, derived attribute values, or attribute bundles about or associated with that subscriber. In addition to attribute information, assertions comprise a variety of data, including assertion metadata, information about the subscriber’s authentication at the IdP, and other information that the RP can leverage (e.g., restrictions, validity time window). While the assertion’s primary function is to authenticate the user to an RP, the information conveyed in the assertion can be used by the RP for a number of use cases (e.g., identity proofing, authorization, personalization of a website). These guidelines do not restrict RP use cases nor the type of protocol or data payload used to federate an identity, provided that the chosen solution meets all mandatory requirements contained herein. Assertions SHALL represent a discrete authentication event of the subscriber at the IdP and SHALL be processed as a discrete authentication event at the RP. All assertions SHALL include the following attributes: Issuer identifier: An identifier for the issuer of the assertion (i.e., the IdP).
Audience identifier: An identifier for the party intended to consume the assertion (i.e., the RP). An assertion can contain more than one audience identifier at FAL1.
Issuance time: A timestamp that indicates when the IdP issued the assertion.
Validity time window: A period of time outside of which the assertion SHALL NOT be accepted as valid by the RP for the purposes of authenticating the subscriber and starting an authenticated session at the RP. This is usually communicated by means of an expiration timestamp for the assertion in addition to the issuance timestamp.
Assertion identifier: A value that uniquely identifies this assertion and is used to prevent attackers from replaying prior assertions.
Authentication time: A timestamp that indicates when the IdP last verified the presence of the subscriber at the IdP through a primary authentication event.
Signature: Digital signature or MAC, including verification key identifier, that covers the entire assertion.
If the RP subscriber account does not use an ephemeral provisioning process, the subscriber SHALL be identified in the assertion using a federated identifier (see Sec. 3.4) or through an account resolution process (see Sec. 3.8.2). If the subscriber is identified using a federated identifier, the assertion SHALL include: Subject Identifier: An identifier for the party to which the assertion applies (i.e., the subscriber)
The following aspects of the federation transaction SHALL be provided through information contained in the assertion contents or the applicable trust agreement: The IAL as well as the type of verification used during the identity proofing process (e.g., biometric, address verification), an indication of the identity proofing processes used to establish the subscriber account, or an indication that no IAL is asserted
The AAL used when the subscriber authenticated to the IdP or an indication that no AAL is asserted
The IdP’s intended FAL of the federation process represented by the assertion
The assertion SHOULD contain additional information about the authentication method used at the IdP, if available (e.g., whether the authenticator used is phishing-resistant). Some technologies that can carry information include Vectors of Trust [RFC8485] or authentication class references in [OIDC] and [SAML]. At FAL2 and above, the assertion SHALL include: Nonce: A cryptographic nonce from the RP’s federation request
At FAL3, the assertion SHALL include one of the following: The public key, key identifier, or other identifier for a holder-of-key assertion or
An indicator that the verification of a bound authenticator is required to process this assertion.
Assertions SHALL NOT contain subscriber authentication secrets (e.g., passwords). Assertions MAY also include additional items, including: Attribute values and derived attribute values: Information about the subscriber
Attribute bundles: Collections of attributes in a signed bundle from the CSP
Subscriber account: Additional details about the subscriber account, such as the set of controls used to obtain the IAL
Attribute metadata: Additional information about one or more subscriber attributes, such as those described in [NISTIR8112]
Authentication event: Additional details about the authentication event, such as the class of authenticators used
The RP SHALL validate the assertion by checking that all of the following are true: Signature validation: Ensure that the signature of the assertion is valid and corresponds to a verification key that belongs to the IdP sending the assertion.
Issuer verification: Ensure that the assertion was issued by the expected IdP.
Time validation: Ensure that the validity time window is within acceptable limits of the current timestamp.
Audience restriction: Ensure that this RP is the intended recipient of the assertion.
Nonce: Ensure that the cryptographic nonce included in the RP’s request (if applicable) is included in the presentation.
Transaction terms: Ensure that the IAL, AAL, and FAL represented by the assertion are allowable under the applicable trust agreement and are suitable for the RP’s needs.
Assertion identifier: Ensure that the assertion has not been replayed within its validity time window at this RP.
An RP that uses the federated identifier to identify the subscriber SHALL NOT treat subject identifiers as inherently globally unique across IdPs. Instead, the value of the assertion’s subject identifier is processed in a namespace under the assertion issuer’s control, as discussed in Sec. 3.4. This allows an RP to talk to multiple IdPs without incorrectly conflating subjects from different IdPs. Any release of identity attributes to the RP is subject to the terms of the trust agreement. Section 3.10 contains privacy requirements for presenting attributes in assertions. The RP MAY be given limited access to an identity API (see Sec. 3.12.3), either in the same response as the assertion is received or through some other mechanism. The RP can use this API to fetch additional identity attributes for the subscriber that are not included in the assertion itself. These attributes are also subject to the terms of the trust agreement. The assertion’s validity time window is the time between its issuance and its expiration. This window needs to be large enough to allow the RP to process the assertion and create a local application session for the subscriber but should not be longer than necessary for such establishment, including reasonable clock drift between the IdP and RP. Long-lived assertions have a greater risk of being stolen or replayed; a short assertion validity time window mitigates this risk. Assertion validity time windows SHALL NOT be used to limit the session at the RP. See Sec. 4.7 for more information. 1. Przegląd
1.1 Odwołania1.2 Zidentyfikowane wymagania1.3 Powiązane regulacje2. Zidentyfikowane wymagania
3. Powiązane regulacje
|