Chapter 6. Portable Identity, Authentication, and Authorization

Web services increasingly cross organizational boundaries. Yet previously there was no standard way to convey security attributes about individuals from one organization to another. How subjects (individuals or entities) are identified, how their digital credentials are created and maintained , and how permissions for access to resources are specified were not standardized, so sharing identity or security attributes outside one organization was extremely difficult. Increasingly, as inter-organizational integrations become commonplace, the need for federation of security attributes becomes more and more important. It is this desire to establish identity in one organization with one set of policies and procedures ”a trust domain ”to be able to assert rights to do things in a separate and distinct trust domain ”be portable ”that motivates this chapter about portable identity, authentication, and authorization. First, we need to establish common vocabulary covering all the security aspects of identity we will be considering.

Digital security has always revolved around identity. Many questions focus on identity. For example, who is accessing my network or my information? Who is this request from? Who vouches for this information being correct? Who sent me this confidential information? How do I know it is really the sender? All these security questions revolve around identity.

Identity refers to an individual or an entity ”such as a machine ”that might represent itself to an organization. We use the term subject to refer to an entity that is asserting its identity. Establishing identity is a critical prerequisite in determining the legitimate actions that a subject may perform. A subject's identity is initially established and verified in some trust domain by a third party, which results in the creation of credentials . When a subject identity established and verified in one trust domain wants to assert its identity and rights in another trust domain, this identity is said to be portable. Credentials are presented as assertions when the subject identity who possesses them wants to initiate some action such as a transaction. An assertion is a claim that may be challenged and proven before being believed. Authentication is an assertion that a subject is who she claims to be, and it is proven by verifying that the presented credentials are legitimately in the possession of the subject. Authorization is an assertion that the subject identity is allowed to perform a specific action, and it must be proven before the requested actions are allowed.

Web services use SOAP to connect machines and applications by moving messages between them and causing remote actions to be performed on a machine that may be part of a different organization, as in business-to-business (B2B) integrations. SOAP defines how software should interact for collaborative commerce. But these types of B2B interactions may involve numerous companies that are aggregating their services. Just as all participants must be authenticated in a closed system for any participants to establish trust, a collaborative commerce environment needs all participants authenticated in a compatible way across the entire virtual system spanning multiple trust domains.

When two entities with different trust models want to interact, SOAP has no standardized and interoperable way to communicate their security properties to establish trust. Because SOAP messages are sent from one trust domain to another, the identity of the requesting subject and its assertions must travel with the message (that is, be portable). In this way, the receiving trust domain can apply its trust model to the message and the identity on whose behalf the message was sent. Security Assertion Markup Language (SAML) is the XML standard created to enable portable identities and the assertions these identities want to make.

SAML's addition to the Web Services Security constellation is important for four key reasons:

1. SAML is a standard XML format suitable for but not tied to any transport. No particular API is mandated ; all the normal XML tools apply to SAML.

2. SAML includes a standard message exchange protocol, so it clearly defines how you ask for the information needed.

3. SAML specifies the rules for how it is transported, making interoperability explicit at the specification level.

4. SAML is unlike other security approaches because of its expression of security in the form of assertions about subjects. Most other approaches depend on a central certificate authority to issue certificates used to guarantee secure communications. This is especially important for Web services in which secured data flows through several systems for a transaction to be completed.