Web Services Security Internal Architecture

The architectural strategy behind the Web Services Security framework is to model security agents on authentication and authorization SPI provided by the web container and to use a WSIT infrastructure for WS-Trust, WS-Policy and WS-I BSP security token implementations. Security agents secure web service requests and validate web service responses by inserting (or extracting) security tokens into (or out of) SOAP messages at the WSC and the WSP. This abstracts security from the application and allows customers to standardize security across multiple containers. Figure 14–3 illustrates this.

Figure 14–3 Architecture of Web Services Security Components

The Web Services Security framework supports the following tokens.

• Tokens that can be authenticated:

  1. UserName

  2. X509

  3. SAML 1.1

  4. SAML 2.0

  5. Kerberos

• Tokens that can be issued:

  • UserName (generated with the Security Token Service or locally at the WSC)

  • X509 (generated with the Security Token Service or locally at the WSC)

  • SAML 1.1 (generated with the Security Token Service or locally at the WSC)

  • SAML 2.0 (generated with the Security Token Service or locally at the WSC)

  • Kerberos (generated locally at the WSC)

In general, securing web services involves establishing trust between a WSC and a WSP. Towards this end, OpenSSO Enterprise provides security agents to verify (and extract data from) security tokens on incoming requests and to add security information (tokens and signatures) to outgoing responses. It also provides a Security Token Service to handle security tokens, and a number of Java interfaces. The following sections contain more information on these components.

• Security Token Service

• Security Agents

• Web Services Security and Security Token Service Interfaces