Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption

Identity is the basis for security: A system is secure if the identities of all users (good identities) are known and intruders (bad identities) are blocked. Information is secure if the sender is known to the receiver, the information is provably intact and unaltered, and all secret information is constantly kept confidential from all non- participants . The identity of valid users must move around when information moves from one trust domain to another. The fact that Web services will be used to cross trust domains makes portable trust an early requirement for Web Services Security.

SAML pre-dates Web services, but because SAML addressed precisely the Web services need for portable identity, the OASIS Web Services Security technical committee working on WS-Security applied SAML to Web services, and it became part of WS-Security. Later, we describe how SAML tokens are incorporated into the WS-Security SOAP extensions.

SAML 1.1 is an OASIS-approved standard. It is also the foundation for Project Liberty, which is an important manifestation of Web Services Security, based on a concept called federated identity . We discuss Project Liberty in some detail later in this chapter.

The Problems SAML Addresses

In the past, each organization acted as its own identification authority for its users. The organization knew who its users were, established identity information about them, issued them credentials ”maybe just in the form of usernames and passwords ”and managed the life cycle of those credentials up to the time the individuals left the organization and ceased to have valid identities with the organization. Rights and permissions for each individual were maintained within the organization's information infrastructure. Each organization had a well-defined set of policies and procedures for how users were identified, what information was retained, how credentials were created and maintained , and how permissions for information access were administered and enforced. In other words, each organization formed its own trust domain. There was very little need for these credentials to cross out of the organization's own trust domain to interact with another trust domain, and doing so would have been nearly impossible .

The first indication that this model was too restrictive came from the larger, more complex organizations with large numbers of users and large collections of applications, each requiring secured access by users. The default mode of operation was that each application required an authenticated login for each user each time access to a new application was required. This led to a strong desire for single sign-on capability because users, at best, were inconvenienced by multiple logins and, at worst, became a large, expensive help desk burden due to lost, expired , or compromised passwords.

The second indication that a single trust domain model of identity would not work ” especially for Web services ”is the strong push for federated identity. Suppose Web services are used to integrate ChosenRentals.com as the preferred rental car provider, ChosenAirline.com as the preferred air carrier, and ChosenHotels.com as the preferred hotel chain for Company.com so that employees of Company.com can directly book their travel and obtain the best rates from the chosen providers. A Company.com employee asserts his identity and his ability to make travel arrangements. Before Web services, this employee would have had to visit the Web sites of all these suppliers and deal with multiple logins and passwords. The sites would administer all the passwords for the Company.com employees and their other corporate customers. With Web services, SAML messages assert the identity and authorizations of this employee at all the supplier systems without his having to make multiple manual site visits or use multiple passwords.

This scenario is illustrated in Figure 6.1. Users are authenticated into Company.com. Company.com communicates via Web services to ChosenAirline.com, ChosenHotels.com, and ChosenRentals.com for travel arrangements the user wants to make through Company.com's employee full-service portal. The user's identity must be passed through to each of the suppliers, so ChosenAirline.com, ChosenHotels.com, and ChosenRentals.com know this user is authorized to make travel arrangements charged to Company.com.

It is impractical , if not impossible, for one organization to take on the responsibility for authenticating all incoming foreign individuals. A possible alternative is to have a central authentication registry for every partnership. This would be prohibitively costly. A better alternative is to provide a way to continue to allow individual organizations to retain their own authentication systems and still retain the loose coupling inherent in Web services that allows organizations to establish B2B integrations. The solution is cross-domain trust enabled by SAML and contractual agreements about how one entity will trust or not trust another entity whose members present their SAML assertions.

Web services are one expression of the growth of interorganizational distributed computing. Web services move messages with attached identities between organizations that do not utilize the same permissions structures. As Web services grow and more and more interorganizational services go online, the need for one organization to accept identities established by another organization will grow without bound. In a nutshell , Web services have all the problems that SAML was developed to solve, even though Web services came after SAML. This is the reason SAML has become so important to Web services security and WS-Security in particular.

Transporting Identity or "Portable Trust"

Chapter 7, "Building Security into SOAP," introduces WS-Security, which is essentially extensions to the SOAP envelope for transporting security assertions. SAML is now a major, standards-based method for describing those assertions. After you can specify identity information in XML, as SAML is designed to do, you can attach this to other XML messages, including SOAP. This kind of "portable trust" is critical for cross-domain trust and therefore for cross-domain (for example, B2B) Web services. These XML security encapsulations are what SAML calls assertions. Supporting these assertions is SAML's protocol for requesting authentication and authorization information to attach to identities. SAML's model is loosely coupled like Web services themselves and so has been easily adopted into the Web Services Security model.

The Concept of Trust Assertions

SAML defines three types of assertions: authentications, authorizations, and attributes. A trust assertion is defined in SAML as a claim, statement, or declaration of fact according to some assertion issuer (SAML authority), specifying

• Authentication ” States that a particular authentication authority has authenticated the subject of the assertion, using a particular process at a particular time with a validity for a specific period of time.

• Authorization ” States that a particular authority has granted or denied permission for the subject of the assertion to act on a particular resource within a specific period of time. An entity can be authorized to read, forward, delete, as well as perform other actions.

• Attributes ” Provides qualifying information about either an authentication or authorization assertion.

The idea is to be able to pass these assertions around and have them mean something. So, for example, if you make an assertion that says you represent Entity A and that assertion is passed to another application that accepts it, you can see why repeated authentications can be avoided.