|
+2.4 Federation and Assertions |
2.4 Federation and AssertionsNormative requirements can be found in [SP800-63C], Federation and Assertions. Section III of OMB [M-19-17], Enabling Mission Delivery through Improved Identity, Credential, and Access Management, directs agencies to support cross-government identity federation and interoperability. The term federation can be applied to several different approaches that involve the sharing of information between different trust domains, and may differ based on the kind of information that is being shared between the domains. These guidelines address the federation processes that allow for the conveyance of identity and authentication information based on trust agreements across a set of networked systems through federation assertions. There are many benefits to using federated architectures including, but not limited to: Enhancing user experience (e.g., a subject can be identity-proofed once but their subscriber account used at multiple RPs)
Reducing costs for both the subscriber (e.g., reduction in authenticators) and the organization (e.g., reduction in information technology infrastructure and a streamlined architecture)
Minimizing data exposed to RPs by using pseudonymous identifiers and derived attribute values instead of copying account values to each application
Supporting mission success, since organizations will need to focus fewer resources on complex identity management processes
While the federation process is generally the preferred approach to authentication when the RP and IdP are not administered together under a common security domain, federation can also be applied within a single security domain for a variety of benefits, including centralized account management and technical integration. These guidelines are agnostic to the identity proofing, authentication, and federation architectures that an organization selects, and they allow organizations to deploy a digital identity scheme according to their own requirements. However, there are scenarios in which federation could be more efficient and effective than establishing identity services that are local to the organization or individual applications, such as: Potential users already have an authenticator at or above the required AAL.
Multiple types of authenticators are required to cover all possible user communities.
An organization does not have the necessary infrastructure to support the management of subscriber accounts (e.g., account recovery, authenticator issuance, help desk).
There is a desire to allow primary authenticators to be added and upgraded over time without changing the RP’s implementation.
There are different environments to be supported, since federation protocols are network-based and allow for implementation on a wide variety of platforms and languages.
Potential users come from multiple communities, each with its own existing identity infrastructure.
The organization needs the ability to centrally manage account life cycles, including account revocation and the binding of new authenticators.
An organization might want to consider accepting federated identity attributes if any of the following apply: Pseudonymity is required, necessary, feasible, or important to stakeholders accessing the service.
Access to the service requires a defined list of attributes.
Access to the service requires at least one derived attribute value.
The organization is not the authoritative or issuing source for required attributes.
Attributes are required temporarily during use (e.g., to make an access decision), and the organization does not need to retain the data.
1. Oversigt
1.1 Referencer1.2 Identificerede krav1.3 Relaterede reguleringer2. Identificerede krav
3. Relaterede reguleringer
|