Section 12.5. Federating Multiple Security Domains

12.5. Federating Multiple Security Domains

Web services technology is often used to integrate several existing applications available on the network. These applications might be extremely diverse in terms of hardware, operating systems, middleware, and in their configurations. In addition, they might reside in different security domains that have different security policies and are dependent on different security infrastructure, such as PKI and Kerberos. This example assumes that each "site" has its own security infrastructure. The infrastructure might be very rigorous, such as Kerberos, or ad hoc, using simple user ID and password databases. It is also assumed that a well-known, in-network security provider, such as a trusted certificate authority, is available in the network.

To date, translating security information from one system in one security domain to another system in another security domain has not been easy. To solve this problem, standard syntax and semantics to express the security information, and rules to translate it, are required. Although WS-Security as it is defined today does not solve all these issues, it is certainly a firm step in that direction, thanks to its flexibility and extensibility.

WS-Security helps solve these problems by defining the following:

• A standard interoperable format (schema) for transporting security information (identity tokens, signature elements, and encryption elements and claims).

• A standard Web services interface (WS-Trust) that Web services can use to create, exchange, and validate security tokens issued by other domains, and that requesters can use to translate credentials from one domain into tokens accepted by another domain. In this example, AirlineXYZ calls back to CompanyABC's security infrastructure, through the WS-Trust's WSDL interface, to validate tokens in a message.

• A set of concrete security policy documents (extensions of WS-Policy) that allow sites and Web services to document their support for WS-Security and their requirements on callers. For example, a site might use WS-Policy to document which messages (or parts of messages) must be signed and which certificate authorities the site trusts.