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.
Using SAML for Federated Identity Management
Security Assertion Markup Language (SAML) is an XML-based way of tagging identities and assertions about identities to provide federated identity management and use. SAML, as a modern open standard defined by the Organization for the Advancement of Structured Information Systems (OASIS), consists of four main components: assertions, protocols, bindings, and profiles. It also establishes three main roles as part of the identity and access management process.
In its simplest application within Identity and Access Management, SAML provides a formal mechanism and format for one entity to assure a second entity about the identity of a third, usually a human being. These three SAML roles include the following:
Identity provider (IdP): This is the first entity. It makes an assertion about another identity, based on information it has. This information might have just been obtained, say by querying the user for a username/password pair.
Service provider (SP): This entity is the relying party that is being asked to provide its service or resource, based on the assurance provided by the IdP.
Subject or principal: This entity is the subject of the assertion, usually a person, who is in some sense being vouched for.
The four primary components of SAML are as follows:
Assertions: In a SAML assertion, an identity provider makes one or more statements about a subject (also known as the principal—usually, a user) that the relying party can use to make access control decisions. The statement vouches for the authentication of the subject (perhaps providing details in an authentication statement) and may provide one or more attribute statements, describing the subject by means of name-value pairs. The assertion may also specify, in an authorization decision statement, conditions under which the principal is permitted to perform certain actions on a given resource.
Protocols: SAML protocols describe how information is to be exchanged between, or consumed by, SAML entities. These rules specify the format and content of several types of SAML exchanges, especially queries between entities. For example, SAML version 1.1 provides for queries concerning the kind of authentication, attribute, and authorization information contained in assertions. Additional protocols, added in SAML 2.0, include the Artifact Resolution Protocol, a Name Identifier Management Protocol, and Single Logout Protocol.
Bindings: SAML bindings specify how to encapsulate the various SAML protocols in various types of messages. Since SAML 2.0, these bindings have described how to include queries, for example, not only in SOAP envelopes but also in HTTP POST and GET exchanges (among others).
Profiles: SAML bindings, protocols, and assertions can be pulled together to make a profile, a set of definitions and instructions for a specified use case. SAML 2.0, for instance, makes available five different profiles for single sign-on use cases: Enhanced Client or Proxy (ECP), Identity Provider Discovery, Name Identifier Management, Single Logout, and Web Browser SSO. Several other profiles are available in SAML 2.0. There are third-party profiles, too, such as the OASIS WS-Security SAML Token Profile.
SAML assertions themselves do not provide authentication of the user or principal. Your choice of access controls to implement, and how rigorously to apply those controls, establishes how your system authenticates subjects (be they users, processes, or hardware devices) in real time. This is covered in more detail in the “Implement Access Controls” section later in this chapter.
NOTE For more information about SAML, its roles and components, and their formats, see “Security Assertion Markup Language (SAML) V2.0 Technical Overview, OASIS Committee Draft 02,” at https://wiki.oasis-open.org/security/Saml2TechOverview.
SUPPORT INTERNETWORK TRUST ARCHITECTURES
In general terms, trust between two or more parties requires agreement as to what set of ideas, subjects, or actions the trust will involve (the trust domain), the obligations each party promises to fulfill with respect to that trust domain, and the protocols by which the parties interact with each other to establish trust, confer trust upon other parties, or withdraw or revoke trust as circumstances may dictate. Trust architectures, therefore, consist of trust relationships, the elements or systems in the trust domain, and the protocols for conferring, confirming, managing, and revoking trust between parties.
In internetworking terms, a trust framework is the set of protocols and standards that provide automated ways to create, manage, and use trust relationships between servers and clients. Trust architectures are the design concepts and ideas by which organizations identify their needs for technical and administrative implementation of trust frameworks as part of their broader organizational information security posture.
Trust Relationships (One-Way, Two-Way, Transitive)
One of the key considerations in federating access between or across systems is the way that trust relationships do or do not transfer. One example might be a humanitarian relief operation that involves a number of nonprofit, nongovernmental organizations (NGOs) from different countries, sharing a consolidated planning, coordination, and information system platform operated by a major aid agency. Some of the NGOs might trust aid agency employees with shared access to their information systems; others might not. There might also be local organizations, working with some of the NGOs, who are not known to the international aid agency; even host nation government agencies might be part of this puzzle. The aid agency might want to grant only a limited set of accesses to some of the NGOs and their staff and maybe no access
