|
+4.1 IdP Account Provisioning |
4.1 IdP Account ProvisioningIn order to make subscriber accounts available through an IdP, the subscriber accounts need to be provisioned at the IdP. The means by which the subscriber account is provisioned to the IdP SHALL be disclosed in the trust agreement. Due to the requirement for the IdP to be able to authenticate the subscriber, the IdP is often a service of the CSP and has some level of access to the attributes and authenticators in the subscriber account. Such IdPs are generally in the same security domain as the identity and access management system that houses the subscriber account. In other cases, one or more authenticators in the subscriber account can be verified outside of the security domain, such as authenticators tied to a common PKI. In these cases, the IdP can pull subscriber attributes and account information from the authenticator to provide a federated login to RPs. The IdP augments the subscriber account with federation-specific attributes, such as a federated identifier. The IdP can collect additional attributes for federation purposes subject to the privacy and storage requirements enumerated by the trust agreement. The CSP can provide attributes from the subscriber account to the IdP as attribute values, derived attribute values, or attribute bundles. The CSP SHALL sign attribute bundles issued to the IdP. After the subscriber account is provisioned to the IdP, the CSP is party to the trust agreement but is not directly involved in the federation transaction. Consequently, even if the RP fetches attributes through an identity API that is hosted by the CSP, the identity API is considered a function of the IdP and not the CSP for the purposes of these guidelines. 1. Przegląd
1.1 Odwołania1.2 Zidentyfikowane wymagania1.3 Powiązane regulacje2. Zidentyfikowane wymagania
3. Powiązane regulacje
|