Web Services Architecture and Its Specifications: Essentials for Understanding WS-*

30 Part I: The Web Services Architecture

Security Policies

WS-SecurityPolicy [WS-SecurityPolicy] complements WS-Security by specifying security pol-

icy assertions in a language conformant to WS-Policy. Its six assertions relate to security

tokens, message integrity, message confidentiality, message visibility to SOAP intermediaries,

constraints on the security header, and the age of a message. For example, a policy assertion

might require that all messages be signed using public keys from a given authority or require

that authentication be based on Kerberos tickets.

System Federations

Application security requires additional mechanisms beyond what we have presented so far.

Identities, for example, are valid within a trust domain but most likely meaningless in other

trust domains. Federation starts with a notion of identity—that is, the requestor or the

requestor’s delegate asserts an identity and the Identity Provider verifies this assertion. For

services in different trust domains to be able to validate identities, appropriate mechanisms

are needed. WS-Federation defines mechanisms to enable identity, account, attribute, authen-

tication, and authorization information sharing across trust domains. By using these mecha-

nisms, multiple security domains can federate by allowing and brokering trust of identities,

attributes, and authentication among participating Web services. The specification extends

the WS-Trust model to allow attributes and pseudonyms to be integrated into the token issu-

ance mechanism, resulting in a multidomain identity-mapping mechanism. These mecha-

nisms support single sign on, sign out, and pseudonyms and describe the role of specialized

services for attributes and pseudonyms.

In Figure 4-2, a requestor (1) obtains an identity security token from its identity provider and then

(2) presents/proves this to the security token services for the desired resource. If successful and if

trust exists and authorization is approved, the security token services (2) returns an access token

to the requestor. The requestor (3) then uses the access token on requests to the Web service.

Figure 4-2 Roles of identity providers and security token services. WS-Federation allows for a vari-

ety of topologies, for which the one described in Figure 4-2 is just one.

Identity

Provider

Requestor

Web Service

with Resources

Identity Provider/

Security Token

Service

Trust

Obtain identity

security token

2

3

1

Present/prove identity

and obtain access token

Present/prove

access in messages

Chapter 4: Security 31

A large variety of requirements can be addressed through identity federation. One example is

associating an employee with its employer. In this case, Jane, from Company A, makes a pur-

chase from alpineskihouse.com. Company A and alpineskihouse.com have a purchasing con-

tract. Since Jane’s identity is associated with Company A, she can be authorized to make a

purchase under the contract.

A second example is mapping a single person to multiple pseudonyms. Joe may be known at

work as [e-mail]. He may also have other identities, such as

[e-mail] and [e-mail]. Through identity federation, systems

can determine that each of these identities is the same Joe. WS-Federation defines explicit

operations to get, set, and delete pseudonyms.

A sign-out operation is provided in order to enable cached state and security tokens to be

removed from a federation. The sign-out operation serves as a hint that it is appropriate to

flush cached data or state information for a specific principal. The exact mechanisms used for

sign out varies depending on the kind of resource and the security policies in place.

Two broad classes of requestors (message senders) are defined in the Web services federated

security architecture: passive and smart (active). A passive requestor [WS-FedPassive] is a ser-

vice that uses only HTTP and never issues security tokens. A smart requestor is a service capa-

ble of issuing messages containing security tokens, such as those described in WS-Security

and WS-Trust. A traditional HTTP-based Web browser is an example of a passive requestor.

Profile specifications have been developed to define the behaviors of these two kinds of

requestors.

For smart requestors, the active requestor profile [WS-FedActive] specifies how single sign on,

sign out, and pseudonyms are integrated into the Web services security model using SOAP

messages. In effect, the profile describes how to implement the model described in WS-Feder-

ation in the context of smart requestors. It specifies requirements on various kinds of security

tokens. An example of one of these security token requirements is as follows: when not using

a secure channel, tokens for X.509 certificates must contain the authority’s name and a signa-

ture over the whole token. The profile also requires that X.509 tokens contain the subject

identifier uniquely identifying the subject for whom the token was granted.