|
+9.2 Direct Connection to an Agency’s IdP |
9.2 Direct Connection to an Agency’s IdPAgency A, which issues and manages subscriber accounts, sets up and operates an OpenID Connect IdP to make these subscriber accounts available online through a federation process. The RP enters into a pairwise trust agreement with the IdP to accept assertions for subscribers from Agency A. The RP declares the set of attributes that it needs from the IdP as part of this agreement. The trust agreement stipulates that the subscriber is the authorized party for determining the release of attributes in the federation transaction. The IdP generates a federated identifier for the subscriber account by taking the employee number and passing it through a one-way cryptographic function to create a unique identifier for the subscriber account. Such an identifier does not allow an RP to calculate the internal identifier but will be stable across changes to other attributes, such as name and email address. Per the terms of the trust agreement, the subscriber is prompted by the IdP the first time they log on to the RP. The IdP asks for the subscriber’s consent at runtime to share their attributes with the RP and displays the RP’s requested uses for these attributes on the subscriber’s consent screen. The IdP also prompts the subscriber to allow the IdP to remember this consent decision. This stored decision causes the IdP to act on the stored consent in a future request and not prompt the subscriber if the same RP requests the same attributes. The assertion is formatted as an OpenID Connect ID Token and contains the minimum set of attributes to facilitate the federated log in. Apart from the federated identifier, the assertion contains no identifying information about the subscriber. In addition to the assertion, the RP is given an OAuth 2.0 access token that allows the RP to access the OpenID Connect UserInfo Endpoint hosted by the IdP. The RP can choose to call this API to obtain additional attributes as needed, such as the first time the subscriber uses the RP. Since this RP follows a just-in-time provisioning model, when the RP sees the subscriber’s federated identifier for the first time, the RP creates an RP subscriber account for that federated identifier and calls the identity API to populate the RP subscriber account with the subscriber’s attributes. For future authentications with this subscriber, the IdP includes a timestamp of when the subscriber’s attributes were last updated. The RP calls the identity API when the updated time is more recent than the last time the RP has called the API. Additionally, the RP proactively refreshes through the identity API twice a year based on their business needs and account management expectations. 1. Přehled
1.1 Odkazy1.2 Identifikované požadavky1.3 Související regulace2. Identifikované požadavky
3. Související regulace
|