|
+4.2 Federation Transaction |
4.2 Federation TransactionA federation transaction that involves a general-purpose IdP establishes the subscriber account at the IdP and culminates in an authenticated session for the subscriber at the RP. This process is shown in Fig. 6.
A federation transaction is a multi-stage process: Before federation can occur, the subscriber account is established by the CSP. This account binds the identity attributes collected by the CSP to a set of authenticators used by the subscriber. The subscriber account is provisioned at the IdP. The IdP augments the subscriber account with federation-specific attributes, such as a federated identifier. The IdP and RP begin a federated authentication transaction to authenticate a subscriber to the RP. The subscriber authenticates to the IdP using an authenticator that is bound to the subscriber account. If mandated by the trust agreement, the authorized party (often the subscriber) is prompted to approve the release of identity information at runtime. The IdP creates an assertion to represent the results of the authentication event. The assertion is based on the terms established by the trust agreement, the request from the RP, the capabilities of the IdP, the subscriber account known to the IdP, and the attributes permitted by the authorized party. The assertion is passed to the RP across the network. The RP processes this assertion from the IdP and establishes an authenticated session with the subscriber. Optionally, the RP receives identity attributes from the IdP that represents the subscriber account, either in the assertion or through an identity API. Federated transactions are enabled by trust agreements, as described in Sec. 3.5. These trust agreements define which parties are fulfilling which roles, the terms under which the parties operate with each other, permission for the systems in question to connect, and the terms under which the parties interact with each other. A single trust agreement often covers multiple federation transactions. The list of available subscriber identity attributes, derived attributes, and attribute bundles is established in the trust agreement, though the decision of which attributes are released to a given RP for a given transaction is finalized during the federation transaction itself. The final set of attributes, derived attribute values, and attribute bundles to be passed to the RP is selected by processing the following: What is allowed by the trust agreement,
What is requested by the RP, and
What is permitted by the authorized party.
The IdP and RP also need to perform discovery and registration to establish the cryptographic keys and identifiers that are needed for information to be securely exchanged between the parties in the federation protocol (see Sec. 4.4). While there may be an existing policy decision that represents a permission to connect (through a pre-established trust agreement), this step entails a connection and integration at the technical level. At any FAL, this stage can occur before subscribers try to access the RP. At FAL1 or FAL2, this stage could alternatively occur in response to a subscriber’s attempt to use an IdP at an RP. In a federated identity transaction, the IdP is the source of identity and authentication attributes for the RP. The normal flow of information for a federation transaction is from the IdP to the RP. Due to the directional nature of this information flow, the IdP is considered to be upstream of the RP and the RP is considered to be downstream of the IdP. It is also possible for additional information to flow back up from the RP, particularly through the use of shared signals, as discussed in Sec. 4.8. 1. Apžvalga
1.1 Nuorodos1.2 Nustatyti reikalavimai1.3 Susiję teisės aktai2. Nustatyti reikalavimai
3. Susiję teisės aktai
|
