Section 12.7. Architectural Concepts

12.7. Architectural Concepts

Web services can be accessed by sending SOAP messages to service endpoints identified as WS-Addressing endpoint references; these messages request specific actions from the service provider, and often trigger SOAP-message responses (including fault indications). Within this context, the broad goal of securing Web services breaks into two subsidiary goals: providing facilities for securing the integrity and confidentiality of the messages, and ensuring that the service acts only on message requests that express the claims required by the security policies. The challenge for WS-Security is to enable secure integration of extremely diverse systems and infrastructures. Figure 12-5 shows the model WS-Security uses for coping with this challenge.

Figure 12-5. WS-Security model.

In this example, suppose someone wants to send a request to Fabrikam456. The requester might have claims regarding the message's security properties, such as identity and authorization claims. For example, the requester might have "logged on to" Kerberos and received a Ticket Granting Ticket that identifies the requester and specifies access privileges.

WS-Security provides a way to represent the set of claims. This is represented as a security token, and WS-Security defines a standard XML format for transporting security tokens. Some tokens might be issued by a trusted third party. For example, an X.509 certificate is usually issued by a certification authority (CA). In the WS-Security model, a trusted third party is called a Security Token Service (STS) because one of its tasks is to issue security tokens. The Security Token Service (STS) might be well-known in a public network, such as an Internet CA, or it might be an infrastructure service within an enterprise's network.

In this example, CompanyABC wraps an ad hoc user name/password logon service with an STS interface that issues security tokens. CompanyABC's STS issues the tokens in a format that WS-Security specifies, and it encrypts the token with a key known to CompanyABC and the requester (that is, CompanyABC's certificate).

The implementing Web service, on the other hand, has a set of requirements for a request to be accepted, such as "X.509-based authentication is required" and "Message must be encrypted by an AES key and have a key length of 128 bits." These requirements are described as the service's policy, and in particular security policy, which is made known to the requester through UDDI or WS-MetadataExchange. Based on the service's security policy, the requester decides which claims it must use (that is, which security tokens to propagate with the message) and what kind of protection is necessary for the request.

If the requester expects a reply (as is generally the case), it can also state its requirement of protecting the reply through a security policy associated with the requester. Similarly, the STS itself is a Web service. The STS has its own policy that states the security requirements on its communications.

WS-Security defines the standard format for transporting security tokens and their mapping to SOAP headers; the specification includes an XML Schema for this purpose. WS-Security also recognizes specific types of security tokens, which support common security infrastructure. Currently, WS-Security has five types of security tokens recognized as profiles in WS-Security:

• A username token (<wsse:UsernameToken>) is a claim on identity. It can have a password, in which case the token also represents a claim that the requester knows the password.

• An X.509 certificate (<wsse:BinarySecurityToken>) is a claim regarding a binding between a public key and its subject, endorsed by a trusted third party.

• A Kerberos ticket (<wsse:BinarySecurityToken>) is a claim that states: "I, the owner of the session key contained in this ticket, am authorized to make a request to the specified services."

• A Security Assertion Markup Language (SAML) assertion uses the generic SAML language syntax for representing security-related assertions, such as identity, attribute, and authorization-decision assertions.

• A Rights Expression Language (REL) license represents ISO/IEC 21000-5 Rights Expressions with respect to the WS-Security specification.

WS-Security also defines a processing model for signing and encrypting security tokens in SOAP messages. This supports the integrity of the tokens, prevents their forgery, and precludes unauthorized access to their information.

For example, CompanyABC might sign and encrypt user security tokens that it issues. Fabrikam456 and AirlineXYZ are assured that CompanyABC issued the token because the signature is verified, but they cannot examine its contents (username, password) because the token is encrypted (opaque). Fabrikam456 and AirlineXYZ might call back to CompanyABC through WS-Trust, passing the encrypted token to determine if it is still valid, or to request authorization decisions (such as, do CompanyABC's policies authorize international travel based on a request with this particular token?).

WS-Trust defines the interfaces to a Security Token Server. In this example, the security infrastructure systems of CompanyABC, Fabrikam456, the well-known security service, the airline and the hotel might provide WS-Trust interfaces for other sites and for network users. For example, AirlineXYZ might use CompanyABC's STS WS-Trust interface to validate a token that it receives through Fabrikam456.