+3.8 RP Subscriber Accounts
---+3.8.1 Account Linking
---+3.8.2 Account Resolution
---+3.8.3 Alternative Authentication Processes
|
3.8 RP Subscriber Accounts
An RP typically keeps a record known as the RP subscriber account to locally represent a subscriber. The RP subscriber account can contain things like access rights at the RP as well as a cache of identity attributes for the subscriber. The RP subscriber account has a separate life cycle from any subscriber account on which it might be based (e.g., the subscriber accounts maintained by a CSP or IdP). An RP subscriber account is provisioned when the RP has associated a set of attributes about the subscriber with a data record that represents the subscriber account at the RP. The provisioning can happen prior to authentication or as a result of the federated authentication process, depending on the deployment patterns (see Sec. 4.6.3). The RP subscriber account MAY be associated with one or more federated identifiers at the time of provisioning or MAY be later linked to federated identifiers through account resolution, as discussed in Sec. 3.8.2. An RP subscriber account is available for federated authentication when it is bound to one or more federated identifiers from the RP’s trusted IdPs, or an account resolution process is established. The successful authentication of a subscriber through a federation protocol allows the subscriber to access the information and functionality of the RP protected by the RP subscriber account. An RP subscriber account is terminated when the RP removes all access to the account at the RP. Termination SHALL include the removal of all federated identifiers, bound authenticators, attributes, and identity information associated with the account, in accordance with Sec. 3.11.3. An RP MAY terminate an RP subscriber account independently from the IdP, regardless of the current validity of the subscriber account from which it is derived. An RP subscriber account is disabled when the subscriber cannot access the RP using the account, such as when all federated identifiers and alternate authenticators are removed from the RP subscriber account, but the information in the account is retained. An RP could choose to disable an RP subscriber account rather than terminate it in order to facilitate records retention or investigate suspicious behavior associated with the account. An RP MAY offer a means of recovery of an RP subscriber account with no current means of access. An RP subscriber account can be provisioned at the RP without an authenticated session, but an authenticated session can only be created based on a provisioned account. See Sec. 3.9 for more information on sessions. The RP SHALL document the practices and policies that it enacts when an RP subscriber account reaches a state of having zero associated federated identifiers; no means of access, including alternative authenticators (see Sec. 3.8.3); and no means of recovery, including account linking (see Sec. 3.8.1) and account resolution (see Sec. 3.8.2). In such cases, the RP subscriber account SHOULD be disabled or terminated. The RP SHALL provide a notice to the subscriber when:
A new federated identifier is added to an existing RP subscriber account, or
A federated identifier is removed from an RP subscriber account, but the account is not terminated.
The RP SHOULD provide a notice to the subscriber when the RP subscriber account is disabled or terminated. The RP SHALL consider the reason for termination when determining whether to send a notice to the subscriber, as discussed in Sec. 5.4 of [SP800-63A]. For additional considerations on providing a notice to a subscriber about account management events, see Sec. 4.6 of [SP800-63B].
1. Přehled
| Název |
Standard |
|
3.8.1 Account Linking
|
A single RP subscriber account MAY be associated with more than one federated identifier. This practice is sometimes known as account linking. If the RP allows a subscriber to link multiple subscriber accounts in this way, the RP SHALL require an authenticated session with the subscriber account for all linking functions. This authenticated session SHOULD require authentication using one existing federated identifier before linking the new federated identifier to the RP subscriber account. When a federated identifier is removed from an RP subscriber account, the RP SHALL disallow access to the RP subscriber account from the removed federated identifier. The RP MAY associate different access rights with the same account, depending on which federated account is used to access the RP. The means by which an RP determines authorization and access is out of scope for these guidelines.
|
|
3.8.2 Account Resolution
|
If the RP has access to existing information about a set of subscribers, and this information is not associated with a federated identifier, the RP performs a process known as account resolution to determine which set of subscriber information to associate with a new RP subscriber account. An RP that performs account resolution SHALL ensure that the attributes requested from the IdP are sufficient to uniquely resolve the subscriber within the RP’s system before linking the federated identifier with the RP subscriber account and granting access. The intended use of each attribute by the RP is detailed in the trust agreement, including whether the attribute is used for account resolution in this manner. An RP that performs account resolution SHALL design the process such that it does not associate an RP subscriber account’s information with a federated identifier that does not belong to the subscriber. For example, a subscriber-controlled wallet might not provide an RP with a federated identifier but could allow the RP to conduct account resolution by providing the RP an attribute bundle from the CSP that allows the RP to uniquely resolve the subscriber to an RP subscriber account. Alternatively, an RP using a pre-provisioning model could uniquely associate an incoming assertion to an RP subscriber account based on an agreed-upon set of attributes. A similar account resolution process is also used when the RP verifies an authenticator used in a holder-of-key assertion for the first time. In this case, the RP SHALL ensure that the attributes carried with the authenticator uniquely resolve to the RP subscriber account before accepting the authenticator.
|
|
3.8.3 Alternative Authentication Processes
|
The RP MAY allow a subscriber to access their RP subscriber account using direct authentication processes by allowing the subscriber to add and remove authenticators in the RP subscriber account. The RP SHALL follow the requirements in [SP800-63B] to manage all alternative authenticators. Since the RP is using the direct authentication model discussed in [SP800-63], there is no federation transaction and therefore no FAL assigned. If the RP allows this kind of access, the RP SHOULD disclose the following in the trust agreement to allow IdPs to make decisions regarding information shared with the RP:
The process for adding and removing alternative authenticators in the RP subscriber account
Any restrictions on authenticators that the subscriber can use to access the RP
The AAL required for access to the subscriber account without a federation transaction
The circumstances under which the RP will require the subscriber to authenticate with their IdP, such as the period of time since the last federation transaction
For additional considerations on providing notice to a subscriber about authenticator management events, see Sec. 4.6 of [SP800-63B]. While it is possible for bound authenticators (see Sec. 3.16) to be used as an alternative authenticator for direct access to the RP, these uses are distinct from each other and an RP SHALL determine whether a given authenticator can be used in one or both scenarios.
|
1.1 Odkazy
1.2 Identifikované požadavky
1.3 Související regulace
2. Identifikované požadavky
Požadavky
| Zdroj |
Požadavek |
3. Související regulace
- NIST -
EN: Publications of the National Institute of Standards and Technology (NIST), U.S. Department of Commerce, https://www.nist.gov/, from their electronic versions (OSCAL; SP 800-63-4 from its HTML version, https://pages.nist.gov/800-63-4/). Works of NIST employees are not subject to copyright protection in the United States (17 U.S.C. § 105); the OSCAL content is dedicated to the public domain worldwide (CC0 1.0); outside the United States NIST grants the right to reprint its technical series publications in all formats (NIST copyright statement). Republished courtesy of the National Institute of Standards and Technology; each document names its citation. Divided into sections and converted into the GRCA format, the wording unchanged. Only the versions published by NIST are authoritative.
DE: Veröffentlichungen des National Institute of Standards and Technology (NIST), U.S. Department of Commerce, https://www.nist.gov/, aus ihren elektronischen Fassungen (OSCAL; SP 800-63-4 aus ihrer HTML-Fassung, https://pages.nist.gov/800-63-4/). Werke von NIST-Beschäftigten sind in den USA urheberrechtlich nicht geschützt (17 U.S.C. § 105); die OSCAL-Inhalte sind weltweit gemeinfrei gestellt (CC0 1.0); außerhalb der USA räumt das NIST das Recht ein, seine Technical-Series-Publikationen in allen Formaten neu zu veröffentlichen (Copyright-Hinweis des NIST). „Republished courtesy of the National Institute of Standards and Technology“; jedes Dokument nennt seine Zitierangabe. In Abschnitte aufgeteilt und in das GRCA-Format umgewandelt, der Wortlaut unverändert. Maßgeblich sind allein die vom NIST veröffentlichten Fassungen.
|