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 joe_andreshak@adatum.com. He may also have other identities, such as
joe@alpineskihouse.com and josepha@contoso.com. 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.

Get Web Services Architecture and Its Specifications: Essentials for Understanding WS-* now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.