Читать книгу The Official (ISC)2 SSCP CBK Reference - Mike Wills - Страница 151

Federated Access

Оглавление

Federated identity management systems provide mechanisms for sharing identity and access information, which makes identity and access portable, allowing properly authorized subjects to access otherwise separate and distinct security domains. Federated access uses open standards, such as the OASIS Security Assertion Markup Language (SAML), and technologies such as OAuth, OpenID, various security token approaches, web service specifications, Windows Identity Foundation, and others. Federated access systems typically use web-based SSO for user access (which is not to be confused with SSO within an organization's systems). Just as individual platform or system access is logically a subset of SSO, SSO is a subset of federated access. SSO, properly implemented, eases the administrative burden for systems administrators, makes end users' lives simpler, and significantly enhances systems security (and its auditability).

One outgrowth of federated identity and access management (IAM) approaches has been to emphasize the need for better, more reliable ways for entities to be able to assert their identity as a part of an e-business transaction or operation. Work to develop an identity assurance framework is ongoing, and there are efforts in the United States, United Kingdom, and a few other nations to develop standards and reference models to support this.

There are two related, but different, approaches to SSO, which are federated identity management (FIM) and delegated identity management (DIM). Federated identity management provides ways for users to supply any credentials they choose that are compatible with the particular website and the authentication services behind it. For example, an OpenID account can be used with any service that implements the OpenID service. Delegated identity management, on the other hand, transfers responsibility for authentication to a third party. Facebook Connect is an example. If you have ever been offered a chance to “authenticate through Facebook,” you have seen delegated authentication in action. Both approaches allow you to authenticate once and then conduct a session using applications across several cooperating enterprises. A user can log into one enterprise and then be able to employ resources in a second, affiliated network without additional authentication or applying a second credential.

These two approaches offer a good way to enforce multifactor authentication across many applications. Both methods scale well and extend cleanly into cloud environments.

One important design element is that each of these two authentication schemes rely on mutual trust. The user's credentials are stored with an “identity provider” accessible on the connected networks or the cloud. When the user logs into a service (for example, a security as a service or identity as a service [IDaaS] application), the service provider puts its trust in the identity provider. These trust relationships mean effectively that the compromise of one significant element of the service chain can lead to the compromise of all connected systems that trust that identity.

One facet of this arrangement that amplifies operational security considerably is that it is no longer necessary to de-authorize a compromised account or persona non grata user on every individual system or application for which they are authorized. A user can be de-authorized once with immediate effect everywhere on all of the systems using this distributed method.

An implementer of federated identity management has plenty of technical choices. They can use Security Assertion Markup Language (SAML) or even plain XML to transmit authorization messages among partners. Other options include using OAuth, OpenID, and even security tokens or PKI. Various combinations are possible; for example, WS-Federation is an Identity Federation specification developed by a group of companies, part of the Web Services Security framework. WS-Federation has mechanisms for brokering information on identities, identity attributes, and authentication itself.

The Official (ISC)2 SSCP CBK Reference

Подняться наверх