The WSIT Tutorial

How Security Works

The following sections describe how the WSIT security technologies, security policy, trust, and secure conversation work.

How Security Policy Works

The WSIT Web Service Security Policy implementation builds on the features provided by the Web Service Policy implementation in WSIT. It enables users to use XML elements to specify the security requirements of a web service endpoint, that is, how messages are secured on the communication path between the client and the web service. The web service endpoint specifies the security requirements to the client as assertions (see Figure 2–9).

Figure 2–9 Security Policy Exchange

Diagram of security policy exchange

The security policy model uses the policy specified in the WSDL file for associating policy assertions with web service communication. As a result, whenever possible, the security policy assertions do not use parameters or attributes. This enables first-level, QName-based assertion matching to be done at the framework level without security domain-specific knowledge. The first-level matching provides a narrowed set of policy alternatives that are shared by the client and web service endpoint when they attempt to establish a secure communication path.

Note –

A QName is a qualified name, as specified by the XML Schema Part2: Datatypes specification, Namespaces in XML, and Namespaces in XML Errata. A qualified name is made up of a namespace URI, a local part, and a prefix.

The benefit of representing security requirements as assertions is that QName matching is sufficient to find common security alternatives and that many aspects of security can be factored out and reused. For example, it may be common that the security mechanism is constant for a web service endpoint, but that the message parts that are protected, or secured, may vary by message action.

The following types of assertions are supported:

How Trust Works

Figure 2–10 shows how the Web Services Trust technology establishes trust.

Figure 2–10 Trust and Secure Conversation

Diagram of trust and secure conversation

    To establish trust between a client, a Security Token Service, and a web service:

  1. The client establishes an HTTPS connection with the Secure Token Service using one of the following methods:

    • Username Authentication and Transport Security: The client authenticates to the Security Token Service using a username token. The Security Token Service uses a certificate to authenticate to the Client. Transport security is used for message protection.

    • Mutual Authentication: Both the client-side and server-side use X509 certificates to authenticate to each other. The client request is signed using Client’s X509 certificate, then signed using ephemeral key. The web service signs the response using keys derived from the client’s key.

  2. The client sends a RequestSecurityToken message to the Security Token Service.

  3. The Security Token Service sends a Security Assertion Markup Language (SAML) token to the Client.

  4. The client uses the SAML token to authenticate itself to the web service and trust is established.

All communication uses SOAP messages.

How Secure Conversation Works

Figure 2–11 shows how the Web Services Secure Conversation technology establishes a secure conversation when the Trust technology is not used.

Figure 2–11 Secure Conversation

Diagram of secure conversation

    To establish a secure conversation between a Client and a web service:

  1. The client sends a X509 Certificate to authenticate itself to the web service.

  2. The web service sends a X509 Certificate to authenticate itself to the client.

All communication uses SOAP messages.