4.6.3 Provisioning Models for RP Subscriber Accounts

The life cycle of the provisioning process for an RP subscriber account varies based on factors including the trust agreement discussed in Sec. 3.5 and the deployment pattern of the IdP and RP. However, in all cases, the RP subscriber account SHALL be provisioned at the RP prior to the establishment of an authenticated session at the RP in one of the following ways:

Just-In-Time Provisioning

An RP subscriber account is created the first time that the RP receives an assertion with an unknown federated identifier from an IdP, an RP subscriber account does not exist, or an existing RP subscriber account can be resolved using an account resolution process, as described in Sec. 3.8.2. Any identity attributes learned during the federation process, either within the assertion or through an identity API as discussed in Sec. 3.12.3, MAY be associated with the RP subscriber account. Accounts that are provisioned in this way are bound to the federated identifier in the assertion used to provision them. This is the most common form of provisioning in federation systems, as it requires the least coordination between the RP and IdP. However, in such systems, the RP SHALL be responsible for managing any cached attributes it might have. See Fig. 7.

Fig. 7. Just-in-time provisioning

Pre-Provisioning

An RP subscriber account is created or linked to an existing RP subscriber account by the IdP pushing the attributes to the RP or the RP pulling attributes from the IdP. Pre-provisioning of accounts generally occurs in bulk through a provisioning API (see Sec. 4.6.5), as the provisioning occurs prior to the represented subscribers authenticating through a federation transaction. Pre-provisioned accounts SHALL be bound to a federated identifier at the time of provisioning, unless an alternative means of access is defined by the trust agreement, such as an account linking policy (see Sec. 3.8.1), an account resolution policy (see Sec. 3.8.2), or alternative authentication mechanisms (see Sec. 3.8.3). This form of provisioning requires infrastructure and planning on the part of the IdP and RP, but these processes can be facilitated by automated protocols. Additionally, the IdP and RP must keep the set of provisioned accounts synchronized over time, as discussed in Sec. 4.6.4. See Fig. 8.

In this model, the RP also receives attributes about subscribers who have not yet interacted with the RP and who may never do so. This is in contrast to other models in which the RP only receives information about the subset of subscribers that use the RP, and then only after the subscriber uses the RP for the first time. The privacy considerations of the RP having access to this information prior to a federation transaction SHALL be accounted for in the trust agreement.

Fig. 8. Pre-provisioning

Ephemeral Provisioning

When processing an assertion, the RP establishes a link between that assertion and a new or existing RP subscriber account but removes that link when the authenticated session ends. This process is similar to just-in-time provisioning, but the RP keeps no long-term record of the subscriber when the session is complete, in accordance with Sec. 3.11.3. This form of provisioning is useful for RPs that fully externalize access rights to the IdP, allowing the RP to be more simplified with less internal state. If this form of provisioning is used, the federated identifier is not required in the assertion. If a federation identifier is supplied in the assertion, the RP SHALL remove any linkage of the federated identifier from an RP subscriber account. See Fig. 9.

Fig. 9. Ephemeral provisioning

Other Provisioning Methods

While other RP subscriber account provisioning models are possible, the details of such models are outside of the scope of these guidelines. However, the details of any alternative provisioning model SHALL be included in the privacy risk assessments of the IdP and RP.

All organizations SHALL document their provisioning models as part of their trust agreement.

1. Pārskats

1.1 Atsauces

1.2 Identificētās prasības

1.3 Saistītie tiesību akti

2. Identificētās prasības

3. Saistītie tiesību akti

• 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.