Downloads  |  Product Documentation  |  Support

   All Blogs Corporate Site CRM On Demand Discussion Forums Documentation Education PartnerNetwork (Public Only) Technology Network Video and Multimedia  

OTN Home      Oracle Forums      Community     

Securing WebLogic Web Services

Configuring Message-Level Security

In this release of WebLogic Server, message-level security features are supported in both the JAX-RPC and JAX-WS stacks.

The following sections describe how to configure security for your Web Service:

Overview of Message-Level Security

Message-level security specifies whether the SOAP messages between a client application and the Web Service invoked by the client should be digitally signed or encrypted, or both. It also can specify a shared security context between the Web Service and client in the event that they exchange multiple SOAP messages. You can use message-level security to assure:

See Configuring Simple Message-Level Security: Main Steps for the basic steps you must perform to configure simple message-level security. This section discusses configuration of the Web Services runtime environment, as well as configuration of message-level security for a particular Web Service and how to code a client application to invoke the service.

You can also configure message-level security for a Web Service at runtime, after a Web Service has been deployed. See Associating Policy Files at Runtime Using the Administration Console for details.

Web Services Security Supported Standards

WebLogic Web Services implement the following OASIS Standard 1.1 Web Services Security (WS-Security 1.1) specifications, dated February 1, 2006:

These specifications provide security token propagation, message integrity, and message confidentiality. These mechanisms can be used independently (such as passing a username token for user authentication) or together (such as digitally signing and encrypting a SOAP message and specifying that a user must use X.509 certificates for authentication).

Web Services Trust and Secure Conversation

WebLogic Web Services implement the Web Services Trust (WS-Trust 1.3) and Web Services Secure Conversation (WS-SecureConversation 1.3) specifications, which together provide secure communication between Web Services and their clients (either other Web Services or standalone Java client applications).

The WS-Trust specification defines extensions that provide a framework for requesting and issuing security tokens, and to broker trust relationships.

The WS-SecureConversation specification defines mechanisms for establishing and sharing security contexts, and deriving keys from security contexts, to enable the exchange of multiple messages. Together, the security context and derived keys potentially increase the overall performance and security of the subsequent exchanges.

Web Services SecurityPolicy 1.2

The WS-Policy specification defines a framework for allowing Web Services to express their constraints and requirements. Such constraints and requirements are expressed as policy assertions.

WS-SecurityPolicy defines a set of security policy assertions for use with the WS-Policy framework to describe how messages are to be secured in the context of WSS: SOAP Message Security, WS-Trust and WS-SecureConversation.

You configure message-level security for a Web Service by attaching one or more policy files that contain security policy statements, as specified by the WS-SecurityPolicy specification. See Using Policy Files for Message-Level Security Configuration for detailed information about how the Web Services runtime environment uses security policy files.

For information about the elements of the Web Services SecurityPolicy 1.2 that are not supported in this release of WebLogic Server, see Unsupported WS-SecurityPolicy 1.2 Assertions.

Main Use Cases of Message-Level Security

The implementation of the Web Services Security: SOAP Message Security specification supports the following use cases:

Using Policy Files for Message-Level Security Configuration

You specify the details of message-level security for a WebLogic Web Service with one or more security policy files. The WS-SecurityPolicy specification provides a general purpose model and XML syntax to describe and communicate the security policies of a Web Service.

The security policy files used for message-level security are XML files that describe whether and how the SOAP messages resulting from an invoke of an operation should be digitally signed or encrypted. They can also specify that a client application authenticate itself using a username, SAML, or X.509 token.

You use the @Policy and @Policies JWS annotations in your JWS file to associate policy files with your Web Service. You can associate any number of policy files with a Web Service, although it is up to you to ensure that the assertions do not contradict each other. You can specify a policy file at both the class- and method level of your JWS file.

Using Policy Files With JAX-WS

For maximum portability, Oracle recommends that you use WS-Policy 1.2 and OASIS WS-SecurityPolicy 1.2 with JAX-WS.

WS-Policy Namespace

WebLogic Server supports WS-Policy 1.2 with the following namespace:

http://schemas.xmlsoap.org/ws/2004/09/policy

WS-SecurityPolicy Namespace

In this release, the following OASIS WS-SX TC Web Services SecurityPolicy namespace is now supported:

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702

In addition to this new version of the namespace, WebLogic Server continues to support the following Web Services SecurityPolicy namespace:

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512

In most of the cases, the policy assertions are identical for either namespaces, with the following exceptions.

Version-Independent Policy Supported

This version of WebLogic Server supports version-independent policy. You can combine protocol-specific policies such as WS-SecurityPolicy and WS-ReliableMessaging policy that are based on different versions of the WS-Policy specification. At runtime, the merged policy file then contains two or more different namespaces.

There are three versions of WS-SecurityPolicy in this release of WebLogic Server:

You can mix and match any version of WS-Policy with (1), (2), or a combination of (1) and (2). However, you cannot mix and match (3) with (1) or (2) and with different versions of WS-Policy.

The version match possibilities are shown in Table 2-1.

If the client program wants to know what version of the policy or security policy is used, use the versioning API to return the namespace and versioning information.

Configuring Simple Message-Level Security: Main Steps

The following procedure describes how to configure simple message-level security for the Web Services security runtime, a particular WebLogic Web Service, and a client application that invokes an operation of the Web Service. In this document, simple message-level security is defined as follows:

Later sections describe some of the preceding scenarios in more detail, as well as additional Web Services security uses cases that build on the simple message-level security use case.

It is assumed in the following procedure that you have already created a JWS file that implements a WebLogic Web Service and you want to update it so that the SOAP messages are digitally signed and encrypted. It is also assumed that you use Ant build scripts to iteratively develop your Web Service and that you have a working build.xml file that you can update with new information. Finally, it is assumed that you have a client application that invokes the non-secured Web Service. If these assumptions are not true, see:

To configure simple message-level security for a WebLogic Web Service:

See the following sections for information about additional Web Service security uses cases that build on the basic message-level security use case:

See Using System Properties to Debug Message-Level Security for information on debugging problems with your message-secured Web Service.

Ensuring That WebLogic Server Can Validate the Client’s Certificate

You must ensure that WebLogic Server is able to validate the X.509 certificate that the client uses to digitally sign its SOAP request, and that WebLogic Server in turn uses to encrypt its SOAP responses to the client. Do one of the following:

For more information, see “SSL Certificate Validation” in Securing WebLogic Server.

Updating the JWS File with @Policy and @Policies Annotations

Use the @Policy and @Policies annotations in your JWS file to specify that the Web Service has one or more policy files attached to it. You can use these annotations at either the class or method level.

See Loading a Policy From the CLASSPATH for an additional policy option.

The @Policies annotation simply groups two or more @Policy annotations together. Use the @Policies annotation if you want to attach two or more policy files to the class or method. If you want to attach just one policy file, you can use @Policy on its own.

The @Policy annotation specifies a single policy file, where it is located, whether the policy applies to the request or response SOAP message (or both), and whether to attach the policy file to the public WSDL of the service.

Use the uri attribute to specify the location of the policy file, as described below:

You can also set the following attributes of the @Policy annotation:

The following example shows how to use the @Policy and @Policies JWS annotations, with the relevant sections shown in bold:

package wssp12.wss10;

import weblogic.jws.WLHttpTransport;
import weblogic.jws.Policy;
import weblogic.jws.Policies;

import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.Oneway;

/**
 * This Web Service demonstrates how to use WS-SecurityPolicy 1.2
 * to enable message-level security specified in WS-Security 1.0.
 * 
 * The service authenticates the client with a username token. 
 * Both the request and response messages are signed and encrypted with X509
 certificates.
 *  
*/
@WebService(name="Simple", targetNamespace="http://example.org")
@WLHttpTransport(contextPath="/wssp12/wss10",
 serviceUri="UsernameTokenPlainX509SignAndEncrypt")
@Policy(uri="policy:Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml")
public class UsernameTokenPlainX509SignAndEncrypt {

  @WebMethod
  @Policies({
      @Policy(uri="policy:Wssp1.2-2007-SignBody.xml"),
      @Policy(uri="policy:Wssp1.2-2007-EncryptBody.xml")})
  public String echo(String s) {

    return s;
  }

  @WebMethod
  @Policies({
      @Policy(uri="policy:Wssp1.2-2007-SignBody.xml"),
      @Policy(uri="policy:Wssp1.2-2007-Sign-Wsa-Headers.xml")})
  public String echoWithWsa(String s) {
    return s;
  }

  @WebMethod
  @Policy(uri="policy:Wssp1.2-2007-SignBody.xml",
 direction=Policy.Direction.inbound)
  @Oneway
  public void echoOneway(String s) {
    System.out.println("s = " + s);
  }

  @WebMethod
  @Policies({
      @Policy(uri="policy:Wssp1.2-2007-Wss1.0-X509-Basic256.xml",
direction=Policy.Direction.inbound),
      @Policy(uri="policy:Wssp1.2-2007-SignBody.xml",
direction=Policy.Direction.inbound)
  })
  @Oneway
  public void echoOnewayX509(String s) {
    System.out.println("X509SignEncrypt.echoOneway: " + s);
  }
}

The following section of the example is the binding policy for the Web Service, specifying the policy:

@WebService(name="Simple", targetNamespace="http://example.org")
@WLHttpTransport(contextPath="/wssp12/wss10",
 serviceUri="UsernameTokenPlainX509SignAndEncrypt")
@Policy(uri="policy:Wssp1.2-2007-Wss1.0-UsernameToken-Plain-X509-Basic256.xml")

In the example, security policy files are attached to the Web Service at the method level. The specified policy files are those pre-packaged with WebLogic Server, which means that the developers do not need to create their own files or package them in the corresponding archive.

The Wssp1.2-2007-SignBody.xml policy file specifies that the body and WebLogic system headers of both the request and response SOAP message be digitally signed. The Wssp1.2-2007-EncryptBody.xml policy file specifies that the body of both the request and response SOAP messages be encrypted.

Loading a Policy From the CLASSPATH

This release of WebLogic Server includes a 'load policy as resource from CLASSPATH' feature. This feature allows you to copy a policy file to the root directory of your Web application and then reference it directly by its name (for example, mypolicy.xml') from an @POLICY annotation in your JWS file.

To enable this feature, start WebLogic Server with

-Dweblogic.wsee.policy.LoadFromClassPathEnabled=true.

If you enable this feature, be aware of the following caveat: If you were to then move the policy file to the WEB-INF/policies directory, the same 'mypolicy.xml' reference in the @POLICY annotation will no longer work. You would need to add the policy prefix to the @POLICY annotation; for example, 'policy:mypolicy.xml'.

Using Key Pairs Other Than the Out-Of-The-Box SSL Pair

In the simple message-level configuration procedure, documented in Configuring Simple Message-Level Security: Main Steps, it is assumed that the Web Services runtime uses the private key and X.509 certificate pair that is provided out-of-the-box with WebLogic Server; this same key pair is also used by the core security subsystem for SSL and is provided mostly for demonstration and testing purposes. In production environments, the Web Services runtime typically uses its own two private key and digital certificate pairs, one for signing and one for encrypting SOAP messages.

The following procedure describes the additional steps you must take to enable this use case.

Updating a Client Application to Invoke a Message-Secured Web Service

When you update your Java code to invoke a message-secured Web Service, you must load a private key and digital certificate pair from the client’s keystore and pass this information, along with a username and password for user authentication if so required by the security policy, to the secure WebLogic Web Service being invoked.

If the security policy file of the Web Service specifies that the SOAP request must be encrypted, then the Web Services client runtime automatically gets the server’s certificate from the policy file that is attached to the WSDL of the service, and uses it for the encryption. If, however, the policy file is not attached to the WSDL, or the entire WSDL itself is not available, then the client application must use a client-side copy of the policy file; for details, see Using a Client-Side Security Policy File.

Listing 2-2 shows a Java client application that invokes the message-secured WebLogic Web Service described by the JWS file in Updating the JWS File With the Security-Related Annotations. The client application takes five arguments:

The security-specific code in the sample client application is shown in bold (and described after the example):

package examples.webservices.security_jws.client;

import weblogic.security.SSL.TrustManager;

import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;

import javax.xml.rpc.Stub;
import java.util.List;
import java.util.ArrayList;

import java.security.cert.X509Certificate;

/**
 *  Copyright © 1996, 2008, Oracle and/or its affiliates. 
 *  All rights reserved.
 */
public class SecureHelloWorldClient {
  public static void main(String[] args) throws Throwable {

    //username or password for the UsernameToken
    String username = args[0];
    String password = args[1];

    //client private key file
    String keyFile = args[2];

    //client certificate
    String clientCertFile = args[3];

    String wsdl = args[4];

    SecureHelloWorldService service = new SecureHelloWorldService_Impl(wsdl + "?WSDL" );

    SecureHelloWorldPortType port = service.getSecureHelloWorldServicePort();

    //create credential provider and set it to the Stub
    List credProviders = new ArrayList();

    //client side BinarySecurityToken credential provider -- x509
    CredentialProvider cp = new ClientBSTCredentialProvider(clientCertFile, keyFile);
    credProviders.add(cp);

    //client side UsernameToken credential provider
    cp = new ClientUNTCredentialProvider(username, password);
    credProviders.add(cp);

    Stub stub = (Stub)port;
    stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);

    stub._setProperty(WSSecurityContext.TRUST_MANAGER,
      new TrustManager(){
         public boolean certificateCallback(X509Certificate[] chain, int validateErr){
           return true;
         }
       } );

    String response = port.sayHello("World");
    System.out.println("response = " + response);
  }
}

The main points to note about the preceding code are:

Invoking a Message-Secured Web Service From a Client Running in a WebLogic Server Instance

In the simple Web Services configuration procedure, described in Configuring Simple Message-Level Security: Main Steps, it is assumed that a stand-alone client application invokes the message-secured Web Service. Sometimes, however, the client is itself running in a WebLogic Server instance, as part of an EJB, a servlet, or another Web Service. In this case, you can use the core WebLogic Server security framework to configure the credential providers and trust manager so that your EJB, servlet, or JWS code contains only the simple invoke of the secured operation and no other security-related API usage.

The following procedure describes the high level steps you must perform to make use of the core WebLogic Server security framework in this use case.

You are not required to configure the core WebLogic Server security framework, as described in this procedure, if your client application does not want to use the out-of-the-box credential provider and trust manager. Rather, you can override all of this configuration by using the same APIs in your EJB, servlet, and JWS code as in the stand-alone Java code described in Using a Client-Side Security Policy File. However, using the core security framework standardizes the WebLogic Server configuration and simplifies the Java code of the client application that invokes the Web Service.

Creating and Using a Custom Policy File

Although WebLogic Server includes a number of pre-packaged Web Services security policy files that typically satisfy the security needs of most programmers, you can also create and use your own WS-SecurityPolicy file if you need additional configuration. See Using Policy Files for Message-Level Security Configuration for general information about security policy files and how they are used for message-level security configuration.

When you create a custom policy file, you can separate out the three main security categories (authentication, encryption, and signing) into three separate policy files, as do the pre-packaged files, or create a single policy file that contains all three categories. You can also create a custom policy file that changes just one category (such as authentication) and use the pre-packaged files for the other categories (Wssp1.2-2007-SignBody.xml, Wssp1.2-SignBody.xml and Wssp1.2-2007-EncryptBody, Wssp1.2-EncryptBody). In other words, you can mix and match the number and content of the policy files that you associate with a Web Service. In this case, however, you must always ensure yourself that the multiple files do not contradict each other.

Your custom policy file needs to comply with the standard format and assertions defined in WS-SecurityPolicy 1.2. Note, however, that this release of WebLogic Server does not completely implement WS-SecurityPolicy 1.2. For more information, see Unsupported WS-SecurityPolicy 1.2 Assertions . The root element of your WS-SecurityPolicy file must be <Policy> and include the following namespace declarations:

  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"

or

  http://www.w3.org/ns/ws-policy

  xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512"

or

  http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702

You can also use the pre-packaged WS-SecurityPolicy files as templates to create your own custom files. See Using WS-SecurityPolicy 1.2 Policy Files.

Configuring the WS-Trust Client

WebLogic Server implements a WS-Trust client that retrieves security tokens from a Security Token Service (STS) for use in Web Services Security. This WS-Trust client is used internally by the client side WebLogic Server Web Service runtime.

You can configure the WS-Trust client as follows:

In prior releases of WebLogic Server, the WS-Trust client could use only security tokens from an STS that was co-located with a Web Service and hosted by WebLogic Server. However, in this release, the STS need only be accessible to the WS-Trust client; it does not need to be co-located.

The WS-Trust client in prior releases supported only WS-SecureConversation tokens. It now also supports SAML tokens.

Supported Token Types

Web Service Secure Conversation Language (WS-SecureConversation) and SAML tokens are supported. The tokens have the following namespace and URI:

Configuring WS-Trust Client Properties

You set some of the configuration properties specifically for the WS-Trust client; others are determined through configuration information generally present for a Web Service client. For example, the type of token retrieved is determined by the security policy of the Web Service that the Web Service client is invoking.

The properties that you can explicitly set and the token type they apply to are as follows. Subsequent sections show how to set these properties.

Obtaining the URI of the Secure Token Service

There are three sources from which the WS-Trust client can obtain the URI of the secure token service (STS). The order of precedence is as follows:

Configuring STS URI: Standalone Client

The following code example demonstrates setting the STS URI on a client stub. The example assumes that the location of the STS URI is already known to the client.

String wsdl = "http://myserver/wsscsecuredservice?wsdl";
WsscSecuredService service = new WsscSecuredService_Impl(wsdl);
WsscSecured port = service.getWsscSecuredSoapPort(); 
Stub stub = (Stub) port; 
String sts = "https://stsserver/standaloneSTS/wssc13/STS";
stub._setProperty("weblogic.wsee.wst.sts_endpoint_uri", sts); 

Configuring STS URI Using WLST: Client Running On Server Side

Listing 2-3 demonstrates using the WebLogic Scripting Tool (WLST) to create a credential provider for the WS-Trust client and then configuring the STS URI, as indicated by bold text.

The provider class name can be one of the following:

Configuring STS URI Using Console: Client Running On Server Side

Configuring the STS URI through the WebLogic Server Administration Console allows the decision about which URI to use to be made at runtime, and not during the Web Service development cycle.

Follow these steps to configure the STS URI through the Console:

Configuring STS Security Policy: Standalone Client

The following code example demonstrates setting the STS security policy on a client stub, as indicated in bold.

String wsdl = "http://myserver/samlsecuredservice?wsdl";

SamlSecuredService service = new SamlSecuredService_Impl(wsdl);

SamlSecured port = service.getSamlSecuredSoapPort(); 

Stub stub = (Stub) port; 

InputStream policy = loadPolicy();

stub._setProperty("weblogic.wsee.security.wst_bootstrap_policy", policy); 

Configuring STS Security Policy Using WLST: Client Running On Server Side

Listing 2-4 demonstrates using WLST to create a credential provider for the default Web Services security configuration, and then configuring the STS security policy, as indicated by bold text. The value for the StsPolicy property must be either a policy included in WebLogic Server (see Using WS-SecurityPolicy 1.2 Policy Files) or a custom policy file in a J2EE library (see Creating and Using a Custom Policy File).

userName = sys.argv[1]
passWord = sys.argv[2]
host = sys.argv[3]+":"+sys.argv[4]
sslhost = sys.argv[3]+":"+sys.argv[5]
samlstsurl = sys.argv[6]
url="t3://"+ host

print "Connect to the running adminSever"
connect(userName, passWord, url)
edit()
startEdit()

defaultWss = cmo.lookupWebserviceSecurity('default_wss')

#Create credential provider for SAML Trust Client

wtm = defaultWss.createWebserviceCredentialProvider('trust_client_saml_cp')
wtm.setClassName('weblogic.wsee.security.saml.SAMLTrustCredentialProvider')
wtm.setTokenType('saml_trust')
cpm = wtm.createConfigurationProperty('StsUri')
cpm.setValue(samlstsurl) 

cpm = wtm.createConfigurationProperty('StsPolicy')
cpm.setValue("Wssp1.2-2007-Https-UsernameToken-Plain")

save()
activate(block="true")
disconnect()
exit() 

Configuring STS Security Policy: Using the Console

Perform the following steps to configure the STS security policy using the console:

Configuring the STS SOAP Version and WS-Trust Version: Standalone Client

For a SAML STS, you need to configure the WS-Trust version only if it is not the default (WS-Trust 1.3). The supported values for WSEESecurityConstants.TRUST_VERSION are as follows:

You also need to configure the SOAP version if it is different from the SOAP version of the target Web Service for which you generated the standalone client. (See Interface SOAPConstants for the definitions of the constants.) The supported values for WSEESecurityConstants.TRUST_SOAP_VERSION are as follows:

Listing 2-5 shows an example of setting the WS-Trust and SOAP versions.

// set WS-Trust version

stub._setProperty(WSEESecurityConstants.TRUST_VERSION, "http://docs.oasis-open.org/ws-sx/ws-trust/200512");

// set SOAP version

stub._setProperty(WSEESecurityConstants.TRUST_SOAP_VERSION, SOAPConstants.URI_NS_SOAP_1_1_ENVELOPE);

Configuring and Using Security Contexts and Derived Keys (WS-SecureConversation)

Oracle provides the following pre-packaged WS-SecurityPolicy files to configure security contexts and derived keys:

It is recommended that you use the pre-packaged files if you want to configure security contexts, because these security policy files provide most of the required functionality and typical default values. See WS-SecureConversation Policies for more information about these files.

Code or configure your application to use the policy through policy annotations, policy attached to the application’s WSDL, or runtime policy configuration.

Specification Backward Compatibility

WebLogic Web Services implement the Web Services Trust (WS-Trust 1.3) and Web Services Secure Conversation (WS-SecureConversation 1.3) specifications. Take note of the following differences from the WS-SecureConversation version of 02/2005:

WS-SecureConversation and Clusters

WS-SecureConversation is pinned to a particular WebLogic Server instance in the cluster. If a SecureConversation request lands in the wrong server, it is automatically rerouted to the correct server. If the server instance hosting the WS-SecureConversation fails, the SecureConversation will not be available until the server instance is brought up again.

Updating a Client Application to Negotiate Security Contexts

A client application that negotiates security contexts when invoking a Web Service is similar to a standard client application that invokes a message-secured Web Service, as described in Using a Client-Side Security Policy File. The only real difference is that you can use the weblogic.wsee.security.wssc.utils.WSSCClientUtil API to explicitly cancel the secure context token.

Listing 2-6 shows a simple example of a client application invoking a Web Service that is associated with a pre-packaged security policy file that enables secure conversations; the sections in bold which are relevant to security contexts are discussed after the example:

package examples.webservices.wssc.client;
import weblogic.security.SSL.TrustManager;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.bst.StubPropertyBSTCredProv;
import weblogic.wsee.security.wssc.utils.WSSCClientUtil;
import weblogic.wsee.security.util.CertUtils;

import javax.xml.rpc.Stub;
import java.util.List;
import java.util.ArrayList;
import java.security.cert.X509Certificate;

/**
 * Copyright © 1996, 2008, Oracle and/or its affiliates. 
 * All rights reserved.
 */
public class WSSecureConvClient {
  public static void main(String[] args) throws Throwable {

    String clientKeyStore = args[0];
    String clientKeyStorePass = args[1];
    String clientKeyAlias = args[2];
    String clientKeyPass = args[3];
    String serverCert = args[4];
    String wsdl = args[5];

    WSSecureConvService service = new WSSecureConvService_Impl(wsdl);
    WSSecureConvPortType port = service.getWSSecureConvServicePort();

    //create credential provider and set it to the Stub
    List credProviders = new ArrayList();

    //use x509 to secure wssc handshake
    credProviders.add(new ClientBSTCredentialProvider(clientKeyStore, clientKeyStorePass, clientKeyAlias, clientKeyPass));

    Stub stub = (Stub)port;

    stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);
    stub._setProperty(StubPropertyBSTCredProv.SERVER_ENCRYPT_CERT, CertUtils.getCertificate(serverCert));

    stub._setProperty(WSSecurityContext.TRUST_MANAGER,
        new TrustManager(){
          public boolean certificateCallback(X509Certificate[] chain, int validateErr){
            //need to validate if the server cert can be trusted
            return true;
          }
        }
    );

    System.out.println (port.sayHelloWithWSSC("Hello World, once"));
    System.out.println (port.sayHelloWithWSSC("Hello World, twice"));
    System.out.println (port.sayHelloWithWSSC("Hello World, thrice"));

    //cancel SecureContextToken after done with invocation
    WSSCClientUtil.terminateWssc(stub);
    System.out.println("WSSC terminated!");

  }
}

The points to notice in the preceding example are:

Associating Policy Files at Runtime Using the Administration Console

The simple message-level configuration procedure, documented in Configuring Simple Message-Level Security: Main Steps, describes how to use the @Policy and @Policies JWS annotations in the JWS file that implements your Web Service to specify one or more policy files that are associated with your service. This of course implies that you must already know, at the time you program your Web Service, which policy files you want to associate with your Web Service and its operations. This might not always be possible, which is why you can also associate policy files at runtime, after the Web Service has been deployed, using the Administration Console.

You can use no @Policy or @Policies JWS annotations at all in your JWS file and associate policy files only at runtime using the Administration Console, or you can specify some policy files using the annotations and then associate additional ones at runtime. However, once you associate a policy file using the JWS annotations, you cannot change this association at runtime using the Administration Console.

At runtime, the Administration Console allows you to associate as many policy files as you want with a Web Service and its operations, even if the policy assertions in the files contradict each other or contradict the assertions in policy files associated with the JWS annotations. It is up to you to ensure that multiple associated policy files work together. If any contradictions do exist, WebLogic Server returns a runtime error when a client application invokes the Web Service operation.

To use the Console to associate one or more WS-Policy files to a Web Service, the WS-Policy XML files must be located in either the META-INF/policies or WEB-INF/policies directory of the EJB JAR file (for EJB implemented Web Services) or WAR file (for Java class implemented Web Services), respectively.

See “Associate a WS-Policy file with a Web Service” in the Administration Console Online Help for detailed instructions on using the Administration Console to associate a policy file at runtime.

Using Security Assertion Markup Language (SAML) Tokens For Identity

The SAML Token Profile 1.1 is part of the core set of WS-Security standards, and specifies how SAML assertions can be used for Web Services security. WebLogic Server 10.3 supports SAML Token Profile 1.1, including support for SAML 2.0 and SAML 1.1 assertions. SAML Token Profile 1.1 is backwards compatible with SAML Token Profile 1.0.

In the simple Web Services configuration procedure, described in Configuring Simple Message-Level Security: Main Steps, it is assumed that users use username tokens to authenticate themselves. Because WebLogic Server implements the SAML Token Profile 1.1 of the Web Services Security specification, users can also use SAML tokens in the SOAP messages to authenticate themselves when invoking a Web Service operation, as described in this section.

Use of SAML tokens works server-to-server. This means that the client application is running inside of a WebLogic Server instance and then invokes a Web Service running in another WebLogic Server instance using SAML for identity. Because the client application is itself a Web Service, the Web Services security runtime takes care of all the SAML processing.

In addition to this server-to-server usage, you can also use SAML tokens from a standalone client via WS-Trust, as described in Configuring the WS-Trust Client.

Using SAML Tokens for Identity: Main Steps

Specifying the SAML Confirmation Method

The WS-SecurityPolicy implies, but does not explicitly specify, the confirmation method for SAML assertions. Consider the following general guidelines:

Specifying the SAML Confirmation Method (Proprietary Policy Only)

This section describes how to specify the SAML confirmation method in a policy file that uses the proprietary schema for security policy.

When you configure a Web Service to require SAML tokens for identity, you can specify one of the following confirmation methods:

See SAML Token Profile Support in WebLogic Web Services, as well as the Web Services Security: SAML Token Profile specification itself, for details about these confirmation methods.

Associating a Web Service with a Security Configuration Other Than the Default

Many use cases previously discussed require you to use the Administration Console to create the default Web Service security configuration called default_wss. After you create this configuration, it is applied to all Web Services that either do not use the @weblogic.jws.security.WssConfiguration JWS annotation or specify the annotation with no attribute.

There are some cases, however, in which you might want to associate a Web Service with a security configuration other than the default; such use cases include specifying different timestamp values for different services.

To associate a Web Service with a security configuration other than the default:

Valid Class Names and Token Types for Credential Provider

When you create a security configuration, you need to supply the class name of the credential provider for this configuration. The valid class names and token types you can use are as follows:

Using System Properties to Debug Message-Level Security

The following table lists the system properties you can set to debug problems with your message-secured Web Service.

Using a Client-Side Security Policy File

The section Using Policy Files for Message-Level Security Configuration describes how a WebLogic Web Service can be associated with one or more security policy files that describe the message-level security of the Web Service. These policy files are XML files that describe how a SOAP message should be digitally signed or encrypted and what sort of user authentication is required from a client that invokes the Web Service. Typically, the policy file associated with a Web Service is attached to its WSDL, which the Web Services client runtime reads to determine whether and how to digitally sign and encrypt the SOAP message request from an operation invoke from the client application.

Sometimes, however, a Web Service might not attach the policy file to its deployed WSDL or the Web Service might be configured to not expose its WSDL at all. In these cases, the Web Services client runtime cannot determine from the service itself the security that must be enabled for the SOAP message request. Rather, it must load a client-side copy of the policy file. This section describes how to update a client application to load a local copy of a policy file.

The client-side policy file is typically exactly the same as the one associated with a deployed Web Service. If the two files are different, and there is a conflict in the security assertions contained in the files, then the invoke of the Web Service operation returns an error.

You can specify that the client-side policy file be associated with the SOAP message request, response, or both. Additionally, you can specify that the policy file be associated with the entire Web Service, or just one of its operations.

Associating a Policy File with a Client Application: Main Steps

The following procedure describes the high-level steps to associate a security policy file with the client application that invokes a Web Service operation.

It is assumed that you have created the client application that invokes a deployed Web Service, and that you want to update it by associating a client-side policy file. It is also assumed that you have set up an Ant-based development environment and that you have a working build.xml file that includes a target for running the clientgen Ant task.

See “Invoking Web Services” in Getting Started With WebLogic Web Services Using JAX-WS and “Invoking a Web Service from a Stand-alone Client: Main Steps” in Getting Started With WebLogic Web Services Using JAX-RPC.

When you next run the client application, it will load local copies of the policy files that the Web Service client runtime uses to enable security for the SOAP request message.

Updating clientgen to Generate Methods That Load Policy Files

For JAX-RPC, set the generatePolicyMethods attribute of the clientgen Ant task to true to specify that the Ant task should generate additional getXXX() methods in the implementation of the JAX-RPC Service interface for loading client-side copies of policy files when you get a port, as shown in the following example:

    <clientgen
      wsdl="http://ariel:7001/policy/ClientPolicyService?WSDL"
      destDir="${clientclass-dir}"
      generatePolicyMethods="true"
      packageName="examples.webservices.client_policy.client"/>

See Updating a Client Application To Load Policy Files (JAX-RPC Only) for a description of the additional methods that are generated and how to use them in a client application.

For JAX-WS, you use the weblogic.jws.jaxws.ClientPolicyFeature class to override the effective policy defined for a service. weblogic.jws.jaxws.ClientPolicyFeature extends javax.xml.ws.WebServiceFeature.

Updating a Client Application To Load Policy Files (JAX-RPC Only)

When you set generatePolicyMethods="true" for clientgen, the Ant task generates additional methods in the implementation of the JAX-RPC Service interface that you can use to load policy files, where XXX refers to the name of the Web Service.

You can use either an Array or Set of policy files to associate multiple files to a Web Service. If you want to associate just a single policy file, create a single-member Array or Set.

Use these methods, rather than the normal getXXXPort() method with no parameters, for getting a Web Service port and specifying at the same time that invokes of all, or the specified, operation using that port have an associated policy file or files.

Listing 2-7 shows an example of using these policy methods in a simple client application; the code in bold is described after the example.

package examples.webservices.client_policy.client;

import java.rmi.RemoteException;

import javax.xml.rpc.ServiceException;
import javax.xml.rpc.Stub;

import java.io.FileInputStream;
import java.io.IOException;

/**
 * This is a simple standalone client application that invokes the
 * the <code>sayHello</code> operation of the ClientPolicyService Web service.
 *
 * @author Copyright © 1996, 2008, Oracle and/or its affiliates. 
 * All rights reserved.
 */

public class Main {

  public static void main(String[] args)
      throws ServiceException, RemoteException, IOException {

      FileInputStream [] inbound_policy_array = new FileInputStream[2];
      inbound_policy_array[0] = new FileInputStream(args[1]);
      inbound_policy_array[1] = new FileInputStream(args[2]);

      FileInputStream [] outbound_policy_array = new FileInputStream[2];
      outbound_policy_array[0] = new FileInputStream(args[1]);
      outbound_policy_array[1] = new FileInputStream(args[2]);

      ClientPolicyService service = new ClientPolicyService_Impl(args[0] + "?WSDL");

      // standard way to get the Web Service port
      ClientPolicyPortType normal_port = service.getClientPolicyPort();

      // specify an array of policy files for the request and response
      // of a particular operation
      ClientPolicyPortType array_of_policy_port = service.getClientPolicyPort("sayHello", inbound_policy_array, outbound_policy_array);

    try {
      String result = null;
      result = normal_port.sayHello("Hi there!");
      result = array_of_policy_port.sayHello("Hi there!");
      System.out.println( "Got result: " + result );
    } catch (RemoteException e) {
      throw e;
    }
  }
}

The second and third argument to the client application are the two policy files from which the application makes an array of FileInputStreams (inbound_policy_array and outbound_policy_array). The normal_port uses the standard parameterless method for getting a port; the array_of_policy_port, however, uses one of the policy methods to specify that an invoke of the sayHello operation using the port has multiple policy files (specified with an Array of FileInputStream) associated with both the inbound and outbound SOAP request and response:

      ClientPolicyPortType array_of_policy_port =  service.getClientPolicyPort("sayHello", inbound_policy_array, outbound_policy_array);

Using WS-SecurityPolicy 1.2 Policy Files

WebLogic Server includes a number of WS-SecurityPolicy files you can use in most Web Services applications. The policy files are located in BEA_HOME/WL_HOME/server/lib/weblogic.jar. Within weblogic.jar, the policy files are located in /weblogic/wsee/policy/runtime.

There are two sets of these policies. In most of the cases, they perform identical functions, but the policy uses different namespace.

The first set is new in this release and has a prefix of “Wssp1.2-2007-”. These security policy files conform to the OASIS WS-SecurityPolicy 1.2 specification and have the following namespace:

<wsp:Policy

xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"

xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"

>

The second set carries over from WebLogic Server version 10.0 and has the prefix “Wssp1.2-”:

<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512"
  >

Oracle recommends that you use the new policy namespace, as those are official namespaces from OASIS standards and they will perform better when interoperating with other vendors. The old policies having the prefix of “Wssp1.2-” are mainly for users who want to interoperate with existing applications that already use this version of the policies.

The following sections describe the available WS-SecurityPolicy 1.2 policy files:

In addition, see Choosing a Policy and Configuring Smart Policy Selection for information about how to choose the best security policy approach for your Web Services implementation and for information about WS-SecurityPolicy 1.2 elements that are not supported in this release of WebLogic Server.

Transport Level Policies

These policies require use of the https protocol to access WSDL and invoke Web Services operations:

Protection Assertion Policies

Protection assertions are used to identify what is being protected and the level of protection provided. Protection assertion policies cannot be used alone; they should be used only in combination with X.509 Token Policies. For example, you might use Wssp1.2-2007-Wss1.1-X509-Basic256.xml together with Wssp1.2-2007-SignBody.xml. The following policy files provide for the protection of message parts by signing or encryption:

WS-Security 1.0 Username and X509 Token Policies

The following policies support the Username Token or X.509 Token specifications of WS-Security 1.0:

WS-Security 1.1 Username and X509 Token Policies

The following policies support the Username Token or X.509 Token specifications of WS-Security 1.1:

WS-SecureConversation Policies

The following policies implement WS-SecureConversation 1.3 and WS-SecureConversation 2005/2:

SAML Token Profile Policies

The policies shown in Table 2-8 implement WS-Security SAML Token Profile 1.0 and 1.1.

Choosing a Policy

WebLogic Server's implementation of WS-SecurityPolicy 1.2 makes a wide variety of security policy alternatives available to you. When choosing a security policy for your Web Service, you should consider your requirements in these areas:

Whenever possible, Oracle recommends that you:

Unsupported WS-SecurityPolicy 1.2 Assertions

The WS-SecurityPolicy 1.2 assertions in Table 2-9 are not supported in this release of WebLogic Server.

.

Using the Optional Policy Assertion

WebLogic Server 10.3 supports the Optional WS-Policy assertion. Consider the use of Optional in the following example:

<sp:SignedEncryptedSupportingTokens>
    <wsp:Policy>
     <sp:UsernameToken
      sp:IncludeToken="…/IncludeToken/AlwaysToRecipient" wsp:Optional="true" >
      <wsp:Policy>
        <sp:WssUsernameToken10/>
      </wsp:Policy>
     </sp:UsernameToken>
    </wsp:Policy>
</sp:SignedEncryptedSupportingTokens> 

In the example, specifying the Username Token for authorization is optional. The client can continue if it cannot generate the Username Token because the user is anonymous or when there is no security context.

During the Security Policy enforcement process, the message is not rejected if the missing element has the Policy assertion with the attribute of wsp:Optional="true".

The following security policy assertions are now supported by the Optional policy assertion:

Configuring Element-Level Security

WebLogic Server supports the element-level assertions defined in WS-SecurityPolicy 1.2. These assertions allow you to apply a signature or encryption to selected elements within the SOAP request or response message, enabling you to target only the specific data in the message that requires security and thereby reduce the computational requirements.

In addition, the assertion RequiredElements allows you to ensure that the message contains a specific header element.

The following element-level assertions are available:

In order to specify an element-level assertion, you must identify the particular request element or response element to which it applies.

You use XPath expressions in policy files to identify these elements, via either XPath Version 1.0 ( http://www.w3.org/TR/xpath) or XPath Filter Version 2.0 ( http://www.w3.org/TR/xmldsig-filter2/) syntax. The examples in this section use the default syntax, XPath Version 1.0.

Because each of these assertions identifies one or more particular elements in Web Service message, you must use custom security policy files for all element-level security assertions. These custom policy files are typically combined with pre-packaged security policy files, with the pre-packaged files defining the way that signing or encryption is performed, and the custom policy files identifying the particular elements that are to be signed or encrypted.

Define and Use a Custom Element-Level Policy File

The first step is to determine the XPath expression that identifies the target element. To do this, you need to understand the format of the SOAP messages used by your web service, either through direct inspection or via analysis of the service’s WSDL and XML Schema.

How you determine the format of the SOAP message, and therefore the required XPath expression, is heavily dependent on the tools you have available and is outside the scope of this document. For example, you might do the following:

Or, you might have a software tool that allows you to produce a sample SOAP request for a given WSDL, and then use it to generate the XPath expression.

Consider the example of a Web Service that has a “submitOrderRequest” operation that will receive a SOAP request of the form shown in Listing 2-8.

The sections in bold will be later used to construct the custom element-level policy.

<env:Envelope 

        xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">

  <env:Header/>

  <env:Body>

    <ns1:submitOrderRequest

            xmlns:ns1="http://www.bea.com/OrderService">

      <ns1:OrderRequest>

        <ns1:orderNumber>4815162342</ns1:orderNumber>

        <ns1:creditCard>

          <ns1:cctype>MasterCard</ns1:cctype>

          <ns1:expires>12-01-2020</ns1:expires>

          <ns1:ccn>1234-567890-4444</ns1:ccn>

        </ns1:creditCard>

      </ns1:OrderRequest>

    </ns1:submitOrderRequest>

  </env:Body>

</env:Envelope>

Assume that you require that the <ns1:creditCard> element and its child elements be encrypted. To do this, you use the information obtained from the bold sections of Listing 2-8 to create a custom security policy file, perhaps called EncryptCreditCard.xml.

Consider the example shown in Listing 2-9.

<?xml version="1.0"?>

<wsp:Policy 
    xmlns:wsp=”http://schemas.xmlsoap.org/ws/2004/09/policy”
    xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512”>

  <sp:EncryptedElements xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/”>

    <sp:XPath xmlns:myns="http://www.bea.com/OrderService”>
/soapenv:Envelope/soapenv:Body/myns:submitOrderRequest/myns:OrderRequest/myns:creditCard

    </sp:XPath>

  </sp:EncryptedElements>

</wsp:Policy>

As described in the WS-SecurityPolicy 1.2 Specification, the /sp:EncryptedElements/sp:XPath element contains a string specifying an XPath expression that identifies the nodes to be confidentiality protected. The XPath expression is evaluated against the S:Envelope element node of the message. Multiple instances of this element may appear within this assertion and should be treated as separate references.

Note the following:

Adding the Policy Annotation to JWS File

After you have created your custom policy, add a Policy annotation to your JWS file so that the ElementEncryption policy is used for submitOrder web service requests, as shown in Listing 2-10.

@WebMethod

@Policies({

  @Policy(uri=”policy:Wssp1.2-2007-Wss1.1-UsernameToken-Plan-X509-Basic256.xml”),
  @Policy(uri=”../policies/EncryptCreditCard.xml”,
         direction=Policy.Direction.inbound)})

public String submitOrderRequest (OrderRequest orderRequest) {

    return orderService.processOrder(orderRequest);
}

Because the creditCard element is present in the SOAP request, but not the response, the code fragment configures the EncryptedElements custom policy only in the “inbound” direction.

Implementation Notes

Keep the following considerations in mind when implementing element-level security:

Smart Policy Selection

Multiple policy alternatives for any given Web Service are supported, which provides the service with significant flexibility.

Consider that a Web Service might support any of the following:

The Web Services client can also handle multiple policy alternatives. The same client can interoperate with different services that have different policy or policy alternatives.

For example, the same client can talk to one service that requires SAML 1.1 Token Profile 1.0 for authentication, while another service requires SAML 2.0 Token Profile 1.1 for authentication.

Example of Security Policy With Policy Alternatives

Listing 2-11 shows an example of a security policy that supports both WS-Security 1.0 and WS-Security 1.1.

<?xml version="1.0"?>
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512">
<wsp:ExactlyOne>
  <wsp:All>
    <sp:AsymmetricBinding>
      <wsp:Policy>
        <sp:InitiatorToken>
          <wsp:Policy>
             <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient">
               <wsp:Policy>
                 <sp:WssX509V3Token10/>
               </wsp:Policy>
             </sp:X509Token>
          </wsp:Policy>
        </sp:InitiatorToken>
        <sp:RecipientToken>
          <wsp:Policy>
             <sp:X509Token
             sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never">
               <wsp:Policy>
                 <sp:WssX509V3Token10/>
               </wsp:Policy>
             </sp:X509Token>
          </wsp:Policy>
        </sp:RecipientToken>
        <sp:AlgorithmSuite>
          <wsp:Policy>
            <sp:Basic256/>
          </wsp:Policy>
        </sp:AlgorithmSuite>
        <sp:Layout>
          <wsp:Policy>
            <sp:Lax/>
          </wsp:Policy>
        </sp:Layout>
        <sp:IncludeTimestamp/>
        <sp:ProtectTokens/>
        <sp:OnlySignEntireHeadersAndBody/>
      </wsp:Policy>
    </sp:AsymmetricBinding>
    <sp:SignedParts>
      <sp:Body/>
    </sp:SignedParts>
    <sp:Wss10>
      <wsp:Policy>
        <sp:MustSupportRefKeyIdentifier/>
        <sp:MustSupportRefIssuerSerial/>
      </wsp:Policy>
    </sp:Wss10>
  </wsp:All>
  <wsp:All>
    <sp:AsymmetricBinding>
      <wsp:Policy>
        <sp:InitiatorToken>
          <wsp:Policy>
            <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient">
              <wsp:Policy>
                <sp:RequireThumbprintReference/>
                <sp:WssX509V3Token11/>
              </wsp:Policy>
            </sp:X509Token>
          </wsp:Policy>
        </sp:InitiatorToken>
        <sp:RecipientToken>
          <wsp:Policy>
            <sp:X509Token
            sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never">
              <wsp:Policy>
                <sp:RequireThumbprintReference/>
                <sp:WssX509V3Token11/>
              </wsp:Policy>
            </sp:X509Token>
          </wsp:Policy>
        </sp:RecipientToken>
        <sp:AlgorithmSuite>
          <wsp:Policy>
            <sp:Basic256/>
          </wsp:Policy>
        </sp:AlgorithmSuite>
        <sp:Layout>
          <wsp:Policy>
            <sp:Lax/>
          </wsp:Policy>
        </sp:Layout>
        <sp:IncludeTimestamp/>
        <sp:ProtectTokens/>
          <sp:OnlySignEntireHeadersAndBody/>
        </wsp:Policy>
      </sp:AsymmetricBinding>
      <sp:SignedParts>
        <sp:Body/>
      </sp:SignedParts>
      <sp:Wss11>
        <wsp:Policy>
          <sp:MustSupportRefKeyIdentifier/>
          <sp:MustSupportRefIssuerSerial/>
          <sp:MustSupportRefThumbprint/>
          <sp:MustSupportRefEncryptedKey/>
          <sp:RequireSignatureConfirmation/>
        </wsp:Policy>
      </sp:Wss11>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

Configuring Smart Policy Selection

You can configure multiple policy alternatives for a single Web Service by creating a custom policy, as shown in Listing 2-11. You then configure the Web Service client to make a policy selection preference.

In this release of WebLogic Server, you can configure the policy selection preferences for the Web Service client by using the WebLogic Server Administration Console, and via stub properties.

The following preferences are supported:

How the Policy Preference is Determined

The Web Services runtime uses your policy selection preference to examine the policy alternatives and select the best choice.

If there are multiple policy choices, the system uses the configured preference list, the availability of the credential, and setting of the optional function to determine the best selection policy.

If multiple policy alternatives exist for a client, the following selection rules are used:

For the optional policy assertions, the following selection rules are used:

Configuring Smart Policy Selection in the Console

Perform the following steps to configure smart policy selection in the Console:

Understanding Body Encryption in Smart Policy

In smart policy selection scenarios, whether or not the Body will be encrypted (for example, <sp:EncryptedParts> <sp:Body /></sp:EncryptedParts>) depends on the following policy selection preference rules:

Consider the following two examples. In Listing 2-12, the encrypted body assertion is in the first policy alternative. Therefore, in the default preference case the body is encrypted. For policy selection preferences other than the default, the other preference rules apply.

<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"

>

<wsp:ExactlyOne>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
<sp:EncryptedParts/>
</wsp:ExactlyOne>
</wsp:Policy>

By contrast, in Listing 2-13, the encrypted body assertion is not in the first policy alternative. Therefore, in the default preference case the body is not encrypted. For policy selection preferences other than the default, the other preference rules apply.

<?xml version="1.0"?>
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"

>
<wsp:ExactlyOne>
<sp:EncryptedParts/>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
</wsp:ExactlyOne>
</wsp:Policy>

Smart Policy Selection for a Standalone Client

You can set the policy selection preference via the stub property.

The following example sets the stub property for security, compatibility, and performance preferences:

stub._setProperty(WLStub.POLICY_SELECTION_PREFERENCE,

WLStub.PREFERENCE_SECURITY_COMPATIBILITY_PERFORMANCE);

If the policy selection preference is not set, then the default preference (None) is used.

Multiple Transport Assertions

If there are multiple available transport-level assertions in your security policies, WebLogic Server uses the policy that requires https. If more than one policy alternative requires https, WebLogic Server randomly picks one of them. You should therefore avoid using multiple policy alternatives that contain mixed transport-level policy assertions.

Example of Adding Security to MTOM Web Service

As described in Optimizing Binary Data Transmission Using MTOM/XOP, SOAP Message Transmission Optimization Mechanism/XML-binary Optimized Packaging (MTOM/XOP) defines a method for optimizing the transmission of XML data of type xs:base64Binary or xs:hexBinary in SOAP messages.

This section describes a combination of two examples that are already included with WebLogic Server :

These existing examples include functional code and extensive instructions.html files that describes their use and function, how to build them, and so forth This section does not repeat that information, but instead concentrates on the changes made to these examples, and the reasons for the changes.

Files Used by This Example

The example uses the files shown in Table 2-10. The contents of the source files are shown in subsequent sections.:

SecurityMtomService.java

The SecurityMtomService.java JWS file is the same as that in WL_HOME\samples\server\examples\src\examples\webservices\mtom\MtomService.java, with the additional Policy annotations shown in bold.

package examples.webservices.security_mtom;

import weblogic.jws.Binding;

import weblogic.jws.Policy;

import weblogic.jws.Policies;

import weblogic.jws.Context;

import weblogic.jws.WLDeployment;

import weblogic.wsee.jws.JwsContext;

import weblogic.wsee.mtom.api.MtomPolicyInfo;

import weblogic.wsee.mtom.api.MtomPolicyInfoFactory;

import weblogic.wsee.policy.framework.PolicyException;

import javax.jws.WebService;

import javax.jws.WebMethod;

import java.rmi.RemoteException;

/**

 * Sample to MTOM with JAX-RPC

 *

 * @author Copyright © 1996, 2008, Oracle and/or its affiliates. 
 * All rights reserved.

 */

@WebService

@Binding(Binding.Type.SOAP12)

//enable WSS + MTOM for this web service by adding the following canned policy files

@Policies({

    @Policy(uri = "policy:Mtom.xml"),

    @Policy(uri = "policy:Wssp1.2-2007-SignBody.xml"), 

    @Policy(uri = "policy:Wssp1.2-2007-EncryptBody.xml"),

	@Policy(uri = "policy:Wssp1.2-Wss1.1-EncryptedKey.xml")

})

public class SecurityMtomService {

  public SecurityMtomService() {

  }

  /**

   * Input is sent as XOP'ed binary octet stream

   *

   * @param bytes input bytes

   * @return A simple String

   */

  @WebMethod

  public String echoBinaryAsString(byte[] bytes) {

    return new String(bytes);

  }

  /**

   * Output is sent as as XOP'ed binary octet stream

   *

   * @param s a simple String

   * @return byte[]

   */

  @WebMethod

  public byte[] echoStringAsBinary(String s) {

    return s.getBytes();

  }

  /**

   * input byte[] is sent as as XOP'ed binary octet stream

   *

   * @param array input byte[] array

   * @return String[]

   */

  @WebMethod

  public String[] echoBinaryArrayAsStringArray(byte[] array) {

    String[] strings = new String[1];

    strings[0] = new String(array);

    return strings;

  }

}

You can specify the @Policy annotation at both the class- and method- level. In this example, the annotation is used at the class-level to specify the pre-packaged WS-Policy files, which means all public operations of the Web Service are associated with the specified WS-Policy files.

You use the @Policies annotation to group together multiple @Policy annotations. You can specify this annotation at both the class- and method-level. In this example, the annotation is used at the class-level to group the four @Policy annotations that specify the pre-packaged WS-Policy files:

MtomClient.java

MtomClient.java is a standalone client application that invokes the SecurityMtomService Web Service. It uses the JAX-RPC stubs generated by clientgen, based on the WSDL of the Web Service. The MtomClient code is shown in Listing 2-15.

package examples.webservices.security_mtom.client;

import java.rmi.RemoteException;

import java.security.cert.X509Certificate;

import java.util.ArrayList;

import java.util.List;

import javax.xml.rpc.Stub;

import weblogic.security.SSL.TrustManager;

// Import classes to create the Binary and Username tokens

import weblogic.wsee.security.bst.ClientBSTCredentialProvider;

import weblogic.wsee.security.unt.ClientUNTCredentialProvider;

// Import classes for creating the client-side credential provider

import weblogic.xml.crypto.wss.WSSecurityContext;

import weblogic.xml.crypto.wss.provider.CredentialProvider;

import weblogic.wsee.security.util.CertUtils;

/**

 * @author Copyright © 1996, 2008, Oracle and/or its affiliates. 
 * All rights reserved. 

 */

public class MtomClient {

  private static final String FOO = "FOO";

  private static SecurityMtomService port;

  public MtomClient(String args[]) throws Exception {

    //client keystore file

    String clientKeyStore = args[0];

    String clientKeyStorePass = args[1];

    String clientKeyAlias = args[2];

    String clientKeyPass = args[3];

    //server certificate

    String serverCertFile = args[4];

    String wsdl = args[5];

    SecurityMtomServiceService service = new SecurityMtomServiceService_Impl(wsdl);

    port = service.getSecurityMtomServiceSoapPort();

	X509Certificate serverCert = (X509Certificate) CertUtils.getCertificate(serverCertFile);

    //create emtpy list of credential providers

    List credProviders = new ArrayList();

    //Create client-side BinarySecurityToken credential provider that uses

    // X.509 for identity, based on certificate and keys parameters

    CredentialProvider cp = new ClientBSTCredentialProvider(clientKeyStore, clientKeyStorePass, clientKeyAlias, clientKeyPass, "JKS", serverCert);

    credProviders.add(cp);

    Stub stub = (Stub) port;

    // Set stub property to point to list of credential providers

    stub._setProperty(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);

    // setup the TrustManager.

    stub._setProperty(WSSecurityContext.TRUST_MANAGER,

        new TrustManager() {

          public boolean certificateCallback(X509Certificate[] chain, int validateErr) {

            //Typically in a real-life application, Java code that actually

            //verifies the certificate goes here; for sake of simplicity, this

            //example assumes the certificate is valid and simply returns true.

            return true;

          }

        });	

  }

  public static void main(String[] args) throws Exception {

    MtomClient client = new MtomClient(args);

    client.invokeEchoBinaryAsString();

    client.invokeEchoStringAsBinary();

    client.invokeEchoBinaryArrayAsStringArray();

  }

  public void invokeEchoBinaryArrayAsStringArray() throws RemoteException {

    System.out.println("sending a String '" + FOO + "' as a byte array.");

    String result = port.echoBinaryArrayAsStringArray(FOO.getBytes()).getJavaLangstring()[0];

    System.out.println("echoing '" + result + "' as a String array.");

  }

  public void invokeEchoStringAsBinary() throws RemoteException {

    System.out.println("sending a String '" + FOO + "'");

    String result = new String(port.echoStringAsBinary(FOO));

    System.out.println("echoing '" + result + "' as a byte array.");

  }

  public void invokeEchoBinaryAsString() throws RemoteException {

    System.out.println("sending a String '" + FOO + "' as a byte array.");

    String result = port.echoBinaryAsString(FOO.getBytes());

    System.out.println("echoing '" + result + "' as a String.");

  }

}

The client application takes six arguments:

The client application uses the following WebLogic Web Services security APIs to create the needed client-side credential providers, as specified by the WS-Policy files that are associated with the Web Service:

When you write this client application, you need to consult the WS-Policy files associated with a Web Service to determine the types and number of credential providers that must be set in the JAX-RPC stub. Typically, if the WS-Policy file specifies that SOAP messages must be signed or encrypted, using X.509 for identity, then you must create a ClientBSTCredentialProvider. (If it specifies that the user provides a username token for identity, then the application must create a ClientUNTCredentialProvider.)

The example creates a client BST credential provider for the indicated keystore, certificate alias, and server certificate. The certificate passed for the parameter serverCert is used to encrypt the message body contents and to verify the received signature. Any KeyInfo received as part of the in-bound signature (for example, certificate thumbprint) must correctly identify the same server certificate.

The Web Services client runtime also consults this WSDL so it can correctly create the security headers in the SOAP request when an operation is invoked.

Finally, the client application must use the weblogic.security.SSL.TrustManager WebLogic security API to verify that the certificate used to encrypt the SOAP request is valid. The client runtime gets this certificate (serverCert in the example) from the deployed WSDL of the Web Service, which in real-life situations is not automatically trusted, so the client application must ensure that it is okay before it uses it to encrypt the SOAP request.

configWss.py Script File

The SecurityMtomService Web Service does not explicitly invoke any WebLogic Server API to handle the requirements imposed by any associated policy files, nor does this Web Service have to understand which, if any, security providers, tokens, or other such mechanisms are involved.

The script file configWss.py uses WLST to create and configure the default Web Service security configuration, default_wss, for the active security realm. (The default Web Service security configuration is used by all Web Services in the domain unless they have been explicitly programmed to use a different configuration.) Further, this script makes sure that x509 tokens are supported, creates the needed security providers, and so forth.

Listing 2-16 shows the configWss.py file. The build.xml file provides the command input. Sections of particular interest are shown in bold.

userName = sys.argv[1]

passWord = sys.argv[2]

url="t3://"+sys.argv[3]+":"+sys.argv[4]

print "Connect to the running adminSever"

connect(userName, passWord, url)

edit()

startEdit()

#Enable assert x509 in SecurityConfiguration

rlm = cmo.getSecurityConfiguration().getDefaultRealm()

ia = rlm.lookupAuthenticationProvider("DefaultIdentityAsserter")

activeTypesValue = list(ia.getActiveTypes())

existed = "X.509" in activeTypesValue

if existed == 1:

  print 'assert x509 is aleady enabled'

else:

  activeTypesValue.append("X.509")

ia.setActiveTypes(array(activeTypesValue,java.lang.String))

ia.setDefaultUserNameMapperAttributeType('CN');

ia.setUseDefaultUserNameMapper(Boolean('true'));

#Create default WebServcieSecurity

securityName='default_wss'

defaultWss=cmo.lookupWebserviceSecurity(securityName)

if defaultWss == None:

  print 'creating new webservice security bean for: ' + securityName

  defaultWss = cmo.createWebserviceSecurity(securityName)

else:

  print 'found exsiting bean for: ' + securityName

#Create credential provider for DK

cpName='default_dk_cp'

wtm=defaultWss.lookupWebserviceCredentialProvider(cpName)

if wtm == None:

	wtm = defaultWss.createWebserviceCredentialProvider(cpName)

	wtm.setClassName('weblogic.wsee.security.wssc.v200502.dk.DKCredentialProvider')

	wtm.setTokenType('dk')

	cpm = wtm.createConfigurationProperty('Label')

	cpm.setValue('WS-SecureConversationWS-SecureConversation')

	cpm = wtm.createConfigurationProperty('Length')

	cpm.setValue('16')

else:

  print 'found exsiting bean for: DK ' + cpName

#Create credential provider for x.509 

cpName='default_x509_cp'

wtm=defaultWss.lookupWebserviceCredentialProvider(cpName)

if wtm == None:

	wtm = defaultWss.createWebserviceCredentialProvider(cpName)

	wtm.setClassName('weblogic.wsee.security.bst.ServerBSTCredentialProvider')

	wtm.setTokenType('x509')

else:

  print 'found exsiting bean for: x.509 ' + cpName

#Custom keystore for xml encryption

cpName='ConfidentialityKeyStore'

cpm=wtm.lookupConfigurationProperty(cpName)

if cpm == None:

	cpm = wtm.createConfigurationProperty(cpName)

keyStoreName=sys.argv[5]

cpm.setValue(keyStoreName)

cpName='ConfidentialityKeyStorePassword'

cpm=wtm.lookupConfigurationProperty(cpName)

if cpm == None:

	cpm = wtm.createConfigurationProperty(cpName)

cpm.setEncryptValueRequired(Boolean('true'))

KeyStorePasswd=sys.argv[6]

cpm.setEncryptedValue(KeyStorePasswd)

cpName='ConfidentialityKeyAlias'

cpm=wtm.lookupConfigurationProperty(cpName)

if cpm == None:

	cpm = wtm.createConfigurationProperty(cpName)

keyAlias=sys.argv[7]

cpm.setValue(keyAlias)

cpName='ConfidentialityKeyPassword'

cpm=wtm.lookupConfigurationProperty(cpName)

if cpm == None:

	cpm = wtm.createConfigurationProperty('ConfidentialityKeyPassword')

cpm.setEncryptValueRequired(Boolean('true'))

keyPass=sys.argv[8]

cpm.setEncryptedValue(keyPass)

#Custom keystore for xml digital signature

cpName='IntegrityKeyStore'

cpm=wtm.lookupConfigurationProperty(cpName)

if cpm == None:

	cpm = wtm.createConfigurationProperty(cpName)

keyStoreName=sys.argv[5]

cpm.setValue(keyStoreName)

cpName='IntegrityKeyStorePassword'

cpm=wtm.lookupConfigurationProperty(cpName)

if cpm == None:

	cpm = wtm.createConfigurationProperty(cpName)

cpm.setEncryptValueRequired(Boolean('true'))

KeyStorePasswd=sys.argv[6]

cpm.setEncryptedValue(KeyStorePasswd)

cpName='IntegrityKeyAlias'

cpm=wtm.lookupConfigurationProperty(cpName)

if cpm == None:

	cpm = wtm.createConfigurationProperty(cpName)

keyAlias=sys.argv[7]

cpm.setValue(keyAlias)

cpName='IntegrityKeyPassword'

cpm=wtm.lookupConfigurationProperty(cpName)

if cpm == None:

	cpm = wtm.createConfigurationProperty(cpName)

cpm.setEncryptValueRequired(Boolean('true'))

keyPass=sys.argv[8]

cpm.setEncryptedValue(keyPass)

#Create token handler for x509 token

#cpName='default_x509_handler'

th=defaultWss.lookupWebserviceTokenHandler(cpName)

if th == None:

	th = defaultWss.createWebserviceTokenHandler(cpName)  

	th.setClassName('weblogic.xml.crypto.wss.BinarySecurityTokenHandler')

	th.setTokenType('x509')

	cpm = th.createConfigurationProperty('UseX509ForIdentity')

	cpm.setValue('true')

save()

activate(block="true")

disconnect()

exit()

Build.xml File

The build.xml file has the targets shown in Table 2-11.

The complete build.xml file is shown in Listing 2-17.

<?xml version="1.0" encoding="ISO-8859-1"?>

<project name="webservices.security_mtom" default="all" basedir=".">

  <!-- set global properties for this build -->

  <property file="../../../examples.properties"/>

  <property name="client.dir" value="${client.classes.dir}/webservicesSecurityMtom_Client" />

  <property name="package.dir" value="examples/webservices/security_mtom"/>

  <property name="package" value="examples.webservices.security_mtom"/>

  <property name="ws.file" value="SecurityMtomService" />

  <property name="ear.dir" value="${examples.build.dir}/webservicesSecurityMtomEar" />

  <property name="cert.dir" value="${basedir}/certs" />

  <property name="certs.dir" value="${basedir}/certs" />

  <!--client keystore-->

  <property name="client-keystore-name" value="clientKeyStore.jks"/>

  <property name="client-keystore-pass" value="keystorepw"/>  

  <property name="client-cert" value="ClientCert"/>

  <property name="client-key" value="ClientKey"/>

  <property name="client-key-pass" value="ClientKeyPass"/>

  <property name="client-cert-alias" value="testClientCert"/>

  <!--server keystore-->

  <property name="server-keystore-name" value="serverKeyStore.jks"/>

  <property name="server-keystore-pass" value="keystorepw"/>

  <property name="server-cert" value="ServerCert"/>

  <property name="server-key" value="ServerKey"/>

  <property name="server-key-pass" value="ServerKeyPass"/>

  <property name="server-cert-alias" value="testServerCert"/>

  <path id="client.class.path">

    <pathelement path="${client.dir}"/>

    <pathelement path="${java.class.path}"/>

  </path>

  <!-- Web Service WLS Ant task definitions -->

  <taskdef name="jwsc"

    classname="weblogic.wsee.tools.anttasks.JwscTask" />

  <taskdef name="clientgen"

      classname="weblogic.wsee.tools.anttasks.ClientGenTask" />

  <target name="all" depends="build, deploy"/>

  <target name="build" depends="clean,server,client"/>

  <target name="clean">

    <delete dir="${ear.dir}"/>

    <delete dir="${client.dir}"/>

  </target>

  <!-- Target that builds the MTOM Web Service -->

  <target name="server" description="Target that builds the MTOM Web Service">

    <jwsc

      srcdir="${examples.src.dir}/${package.dir}"

      sourcepath="${examples.src.dir}"

      destdir="${ear.dir}"

      classpath="${java.class.path}"

      fork="true"

      keepGenerated="true"

      deprecation="${deprecation}"

      debug="${debug}">

        <jws file="SecurityMtomService.java" explode="true"/>

    </jwsc>

  </target>

  <!-- Target that builds the MTOM Web Service client -->

  <target name="client" description="Target that builds the source Web Service">

    <mkdir dir="${client.dir}/${package.dir}/client/"/>

    <clientgen

      wsdl="${ear.dir}/${ws.file}/WEB-INF/${ws.file}Service.wsdl"

      destDir="${client.dir}"

      classpath="${java.class.path}"

      packageName="${package}.client"/>

    <copy file="MtomClient.java" todir="${client.dir}/${package.dir}/client/"/>

    <javac

      srcdir="${client.dir}" destdir="${client.dir}"

      classpath="${java.class.path}"

      includes="${package.dir}/client/**/*.java"/>

  </target>

  <!-- Target that deploys the MTOM Web Service -->

  <target name="deploy" description="Target that deploys the reliable destination Web Service">

    <wldeploy

      action="deploy"

      source="${ear.dir}"

      user="${wls.username}"

      password="${wls.password}"

      verbose="true"

      adminurl="t3://${wls.hostname}:${wls.port}"

      targets="${wls.server.name}"

      failonerror="${failondeploy}"/>

  </target>

  <!-- Target that runs the MTOM Web Service client -->

  <target name="run" >

    <java fork="true"

      classname="examples.webservices.security_mtom.client.MtomClient"

      failonerror="true" >

	  <jvmarg line="-Dweblogic.wsee.verbose=*"/>

      <classpath refid="client.class.path"/>

      <arg line=	"  

      ${basedir}/certs/${client-keystore-name}

      ${client-keystore-pass}

      ${client-cert-alias}

      ${client-key-pass}    

      ${basedir}/certs/testServerCertTempCert.der

      http://${wls.hostname}:${wls.port}/SecurityMtomService/SecurityMtomService?WSDL" />

    </java>

  </target>

    <!-- Target the configure the web service security -->

  <target name="config.server.security" description="Target the configure the web service security">

    <copy todir="${examples.domain.dir}" overwrite="true">

      <fileset dir="${certs.dir}" includes="${server-keystore-name}"/>

    </copy>

    <java classname="weblogic.WLST" fork="true" failonerror="true">

      <arg line="configWss.py ${wls.username} ${wls.password} ${wls.hostname} ${wls.port}

      ${server-keystore-name} ${server-keystore-pass} ${server-cert-alias} ${server-key-pass}" />

    </java>

  </target>

</project>

Building and Running the Example

Follow these steps to build and run the example:

Deployed WSDL for SecurityMtomService

The deployed WSDL for the SecurityMtomService Web Service is available at the following URL:

http://host:port/SecurityMtomService/SecurityMtomService?WSDL

The complete WSDL is shown in Listing 2-18.

<?xml version="1.0" encoding="UTF-8" ?> 

- <s1:definitions name="SecurityMtomServiceServiceDefinitions" targetNamespace="http://examples/webservices/security_mtom" xmlns="" xmlns:s0="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:s1="http://schemas.xmlsoap.org/wsdl/" xmlns:s2="http://examples/webservices/security_mtom" xmlns:s3="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">

  <wsp:UsingPolicy s1:Required="true" /> 

- <wsp:Policy s0:Id="Mtom.xml">

  <wsoma:OptimizedMimeSerialization xmlns:wsoma="http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization" /> 

  </wsp:Policy>

- <wsp:Policy s0:Id="Wssp1.2-Wss1.1-EncryptedKey.xml">

- <sp:SymmetricBinding xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512">

- <wsp:Policy>

- <sp:ProtectionToken>

- <wsp:Policy>

- <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never">

- <wsp:Policy>

  <sp:RequireThumbprintReference /> 

  <sp:WssX509V3Token11 /> 

  </wsp:Policy>

  </sp:X509Token>

  </wsp:Policy>

  </sp:ProtectionToken>

- <sp:AlgorithmSuite>

- <wsp:Policy>

  <sp:Basic256 /> 

  </wsp:Policy>

  </sp:AlgorithmSuite>

- <sp:Layout>

- <wsp:Policy>

  <sp:Lax /> 

  </wsp:Policy>

  </sp:Layout>

  <sp:IncludeTimestamp /> 

  <sp:OnlySignEntireHeadersAndBody /> 

  </wsp:Policy>

  </sp:SymmetricBinding>

- <sp:Wss11 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512">

- <wsp:Policy>

  <sp:MustSupportRefKeyIdentifier /> 

  <sp:MustSupportRefIssuerSerial /> 

  <sp:MustSupportRefThumbprint /> 

  <sp:MustSupportRefEncryptedKey /> 

  <sp:RequireSignatureConfirmation /> 

  </wsp:Policy>

  </sp:Wss11>

  </wsp:Policy>

- <wsp:Policy s0:Id="Wssp1.2-2007-EncryptBody.xml">

- <sp:EncryptedParts xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

  <sp:Body /> 

  </sp:EncryptedParts>

  </wsp:Policy>

- <wsp:Policy s0:Id="Wssp1.2-2007-SignBody.xml">

- <sp:SignedParts xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

  <sp:Body /> 

  </sp:SignedParts>

  </wsp:Policy>

- <s1:types>

- <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="java:examples.webservices.security_mtom" xmlns:s0="http://schemas.xmlsoap.org/wsdl/" xmlns:s1="http://examples/webservices/security_mtom" xmlns:s2="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:xs="http://www.w3.org/2001/XMLSchema">

- <xs:complexType name="ArrayOfJavaLangstring_literal">

- <xs:sequence>

  <xs:element maxOccurs="unbounded" minOccurs="0" name="JavaLangstring" nillable="true" type="xs:string" /> 

  </xs:sequence>

  </xs:complexType>

  <xs:element name="ArrayOfJavaLangstring_literal" type="java:ArrayOfJavaLangstring_literal" xmlns:java="java:examples.webservices.security_mtom" /> 

  <xs:element name="base64Binary_literal" type="xs:base64Binary" /> 

  </xs:schema>

- <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://examples/webservices/security_mtom" xmlns:s0="http://schemas.xmlsoap.org/wsdl/" xmlns:s1="http://examples/webservices/security_mtom" xmlns:s2="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:import namespace="java:examples.webservices.security_mtom" /> 

- <xs:element name="echoBinaryAsString">

- <xs:complexType>

- <xs:sequence>

  <xs:element name="bytes" type="xs:base64Binary" /> 

  </xs:sequence>

  </xs:complexType>

  </xs:element>

- <xs:element name="echoBinaryAsStringResponse">

- <xs:complexType>

- <xs:sequence>

  <xs:element name="return" type="xs:string" /> 

  </xs:sequence>

  </xs:complexType>

  </xs:element>

- <xs:element name="echoBinaryArrayAsStringArray">

- <xs:complexType>

- <xs:sequence>

  <xs:element name="array" type="xs:base64Binary" /> 

  </xs:sequence>

  </xs:complexType>

  </xs:element>

- <xs:element name="echoBinaryArrayAsStringArrayResponse">

- <xs:complexType>

- <xs:sequence>

  <xs:element name="return" type="java:ArrayOfJavaLangstring_literal" xmlns:java="java:examples.webservices.security_mtom" /> 

  </xs:sequence>

  </xs:complexType>

  </xs:element>

- <xs:element name="echoStringAsBinary">

- <xs:complexType>

- <xs:sequence>

  <xs:element name="s" type="xs:string" /> 

  </xs:sequence>

  </xs:complexType>

  </xs:element>

- <xs:element name="echoStringAsBinaryResponse">

- <xs:complexType>

- <xs:sequence>

  <xs:element name="return" type="xs:base64Binary" /> 

  </xs:sequence>

  </xs:complexType>

  </xs:element>

  </xs:schema>

  </s1:types>

- <s1:message name="echoBinaryAsString">

  <s1:part element="s2:echoBinaryAsString" name="parameters" /> 

  </s1:message>

- <s1:message name="echoBinaryAsStringResponse">

  <s1:part element="s2:echoBinaryAsStringResponse" name="parameters" /> 

  </s1:message>

- <s1:message name="echoBinaryArrayAsStringArray">

  <s1:part element="s2:echoBinaryArrayAsStringArray" name="parameters" /> 

  </s1:message>

- <s1:message name="echoBinaryArrayAsStringArrayResponse">

  <s1:part element="s2:echoBinaryArrayAsStringArrayResponse" name="parameters" /> 

  </s1:message>

- <s1:message name="echoStringAsBinary">

  <s1:part element="s2:echoStringAsBinary" name="parameters" /> 

  </s1:message>

- <s1:message name="echoStringAsBinaryResponse">

  <s1:part element="s2:echoStringAsBinaryResponse" name="parameters" /> 

  </s1:message>

- <s1:portType name="SecurityMtomService" wsp:PolicyURIs="#Wssp1.2-2007-SignBody.xml #Wssp1.2-2007-EncryptBody.xml #Wssp1.2-Wss1.1-EncryptedKey.xml">

- <s1:operation name="echoBinaryAsString" parameterOrder="parameters">

  <s1:input message="s2:echoBinaryAsString" /> 

  <s1:output message="s2:echoBinaryAsStringResponse" /> 

  </s1:operation>

- <s1:operation name="echoBinaryArrayAsStringArray" parameterOrder="parameters">

  <s1:input message="s2:echoBinaryArrayAsStringArray" /> 

  <s1:output message="s2:echoBinaryArrayAsStringArrayResponse" /> 

  </s1:operation>

- <s1:operation name="echoStringAsBinary" parameterOrder="parameters">

  <s1:input message="s2:echoStringAsBinary" /> 

  <s1:output message="s2:echoStringAsBinaryResponse" /> 

  </s1:operation>

  </s1:portType>

- <s1:binding name="SecurityMtomServiceServiceSoapBinding" type="s2:SecurityMtomService">

  <s3:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> 

- <wsp:Policy>

  <wsp:PolicyReference URI="#Mtom.xml" /> 

  </wsp:Policy>

- <s1:operation name="echoBinaryAsString">

  <s3:operation style="document" /> 

- <s1:input>

  <s3:body parts="parameters" use="literal" /> 

  </s1:input>

- <s1:output>

  <s3:body parts="parameters" use="literal" /> 

  </s1:output>

  </s1:operation>

- <s1:operation name="echoBinaryArrayAsStringArray">

  <s3:operation style="document" /> 

- <s1:input>

  <s3:body parts="parameters" use="literal" /> 

  </s1:input>

- <s1:output>

  <s3:body parts="parameters" use="literal" /> 

  </s1:output>

  </s1:operation>

- <s1:operation name="echoStringAsBinary">

  <s3:operation style="document" /> 

- <s1:input>

  <s3:body parts="parameters" use="literal" /> 

  </s1:input>

- <s1:output>

  <s3:body parts="parameters" use="literal" /> 

  </s1:output>

  </s1:operation>

  </s1:binding>

- <s1:service name="SecurityMtomServiceService">

- <s1:port binding="s2:SecurityMtomServiceServiceSoapBinding" name="SecurityMtomServiceSoapPort">

  <s3:address location="http://localhost:7001/SecurityMtomService/SecurityMtomService" /> 

  </s1:port>

  </s1:service>

  </s1:definitions>

Example of Adding Security to Reliable Messaging Web Service

This section describes an update to an example that is already included with WebLogic Server:

This section shows how to update the example to use the most recent version of the policy file. Oracle recommends that you use the new policy namespace, as shown in the revised example, as those are official namespaces from OASIS standards and they will perform better when interoperating with other vendors.

Overview of Secure and Reliable SOAP Messaging

Reliable SOAP messaging is a framework whereby an application running in one WebLogic Server instance can reliably invoke a Web Service running on another WebLogic Server instance. Reliable is defined as the ability to guarantee message delivery between the two Web Services.

WebLogic Web Services conform to the WS-ReliableMessaging 1.1 specification, which describes how two Web Services running on different WebLogic Server application servers can communicate reliably in the presence of failures in software components, systems, or networks. In particular, the specification describes an interoperable protocol in which a message sent from a source endpoint (client Web Service) to a destination endpoint (Web Service whose operations can be invoked reliably) is guaranteed either to be delivered, according to one or more delivery assurances, or to raise an error. The WS-ReliableMessaging specification defines an interoperable way to provide security by composing WS-ReliableMessaging with WS-SecureConversation and associating a reliable sequence with a secure session. At sequence creation time, the sending side needs to present a Security Token Reference to point to a Security Context Token that will be used to identify the owner of the sequence. All subsequent sequence messages and protocol messages in both directions will need to demonstrate proof-of-possession of the referenced key.

WebLogic reliable SOAP messaging works only between two Web Services. This means that you can invoke a WebLogic Web Service reliably only from another Web Service, and not from a standalone client application. This example shows how to create both types of Web Services (source and destination). The WsrmSecurityClient.java class is a standalone Java application that then invokes the source Web Service.

Overview of the Example

The existing example shows how to provide security functionality on top of reliability for Web Services messaging by creating two WebLogic Web Services:

The existing example includes functional code and an extensive instructions.html file that describes its use and function, how to build it, and so forth This section does not repeat that information, but instead concentrates on the changes made to the example, and the reasons for the changes.

How the Example Sets Up WebLogic Security

The configWSS.py WLST script sets up security for the WebLogic Server instance that hosts the source and destination Web Service. The security requirements are dictated by the WS-SecurityPolicy files associated with the destination Web Service.

The Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.0.xml policy imposes the following requirements:

In response, the configWSS.py WLST script performs the following functions:

In addition, the configWSSRuntime.py WLST script also performs the following functions:

Files Used by This Example

The example uses the files shown in Table 2-12. The contents of revised source files are shown in subsequent sections.:

Revised ReliableEchoServiceImpl.java

The ReliableEchoServiceImpl.java JWS file is the same as that in WL_HOME\samples\server\examples\src\examples\webservices\wsrm_security\ReliableEchoServiceImpl.java, with the revised Policy annotation shown in bold.

@WebService(name = "ReliableEchoPort",

    serviceName = "ReliableEchoService")

@WLHttpTransport(contextPath = "WsrmSecurity", serviceUri = "ReliableEchoService")

@Policies({

  @Policy(uri="policy:Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.0.xml"),

  @Policy(uri="policy:Reliability1.1_SequenceSTR")}

)

You can specify the @Policy annotation at both the class- and method- level. In this example, the annotation is used at the class-level to specify the pre-packaged WS-Policy files, which means all public operations of the Web Service are associated with the specified WS-Policy files.

Revised configWss.py

The ReliableEchoServiceImpl Web Service does not explicitly invoke any WebLogic Server API to handle the requirements imposed by any associated policy files, nor does this Web Service have to understand which, if any, security providers, tokens, or other such mechanisms are involved.

The script file configWss.py uses WLST to create and configure the default Web Service security configuration, default_wss, for the active security realm. (The default Web Service security configuration is used by all Web Services in the domain unless they have been explicitly programmed to use a different configuration.) Further, this script makes sure that x509 tokens are supported, creates the needed security providers, and so forth.

The configWss.py file is the same as that in WL_HOME\samples\server\examples\src\examples\webservices\wsrm_security\configWss.py, with the changes shown in bold. The build.xml file provides the command input.

:

#Create credential provider for SCT

cpName='default_sct_cp'

wtm=defaultWss.lookupWebserviceCredentialProvider(cpName)

if wtm == None:

  print 'creating new webservice credential provider : ' + cpName

  wtm = defaultWss.createWebserviceCredentialProvider(cpName)

  wtm.setClassName('weblogic.wsee.security.wssc.v13.sct.ServerSCCredentialProvider')

  wtm.setTokenType('sct')

  cpm = wtm.createConfigurationProperty('TokenLifeTime')

  cpm.setValue('43200000')

else:

  print 'found exsiting bean for: ' + cpName

#Create credential provider for DK

cpName='default_dk_cp'

wtm=defaultWss.lookupWebserviceCredentialProvider(cpName)

if wtm == None:

	wtm = defaultWss.createWebserviceCredentialProvider(cpName)

	wtm.setClassName('weblogic.wsee.security.wssc.v13.dk.DKCredentialProvider')

	wtm.setTokenType('dk')

	cpm = wtm.createConfigurationProperty('Label')

	cpm.setValue('WS-SecureConversationWS-SecureConversation')

	cpm = wtm.createConfigurationProperty('Length')

	cpm.setValue('16')

else:

  print 'found exsiting bean for: DK ' + cpName

:

Revised configWss_Service.py

The configWss_Service.py script is similar to configWss.py, but it is used only when the source and destination Web Service are hosted in two servers.

The configWss_Service.py file is the same as that in WL_HOME\samples\server\examples\src\examples\webservices\wsrm_security\configWss_Service.py, with the changes shown in bold. The build.xml file provides the command input.

:

 #Create credential provider for SCT

cpName='default_sct_cp'

wtm=defaultWss.lookupWebserviceCredentialProvider(cpName)

if wtm == None:

  print 'creating new webservice credential provider : ' + cpName

  wtm = defaultWss.createWebserviceCredentialProvider(cpName)

  wtm.setClassName('weblogic.wsee.security.wssc.v13.sct.ServerSCCredentialProvider')

  wtm.setTokenType('sct')

  cpm = wtm.createConfigurationProperty('TokenLifeTime')

  cpm.setValue('43200000')

else:

  print 'found exsiting bean for: ' + cpName

#Create credential provider for DK

cpName='default_dk_cp'

wtm=defaultWss.lookupWebserviceCredentialProvider(cpName)

if wtm == None:

	wtm = defaultWss.createWebserviceCredentialProvider(cpName)

	wtm.setClassName('weblogic.wsee.security.wssc.v13.dk.DKCredentialProvider')

	wtm.setTokenType('dk')

	cpm = wtm.createConfigurationProperty('Label')

	cpm.setValue('WS-SecureConversationWS-SecureConversation')

	cpm = wtm.createConfigurationProperty('Length')

	cpm.setValue('16')

else:

  print 'found existing bean for: DK ' + cpName

:

Building and Running the Example

After you have changed the example to use the new policy namespace, follow the steps in the WL_HOME\samples\server\examples\src\examples\webservices\wsrm_security\instructions.html file to build and run the example.

There are no changes needed to these steps.

Proprietary Web Services Security Policy Files (JAX-RPC Only)

Previous releases of WebLogic Server, released before the formulation of the WS-SecurityPolicy specification, used security policy files written under the WS-Policy specification, using a proprietary schema for security policy.

This section describes the set of pre-packaged Web Services security policy schema files included in WebLogic Server. These policy files are all abstract; see Abstract and Concrete Policy Files for details.

The policy assertions used in these security policy files to configure message-level security for a WebLogic Web Service are based on the assertions described in the December 18, 2002 version of the Web Services Security Policy Language (WS-SecurityPolicy) specification. This means that although the exact syntax and usage of the assertions in WebLogic Server are different, they are similar in meaning to those described in the specification. The assertions are not based on later updates of the specification.

The pre-packaged Web Services security policy files are:

Abstract and Concrete Policy Files

The WebLogic Web Services runtime environment recognizes two slightly different types of security policy files: abstract and concrete.

Abstract policy files do not explicitly specify the security tokens that are used for authentication, encryption, and digital signatures, but rather, the Web Services runtime environment determines the security tokens when the Web Service is deployed. Specifically, this means the <Identity> and <Integrity> elements (or assertions) of the policy files do not contain a <SupportedTokens><SecurityToken> child element, and the <Confidentiality> element policy file does not contain a <KeyInfo><SecurityToken> child element.

If your Web Service is associated with only the pre-packaged policy files, then client authentication requires username tokens. Web Services support only one type of token for encryption and digital signatures (X.509), which means that in the case of the <Integrity> and <Confidentiality> elements, concrete and abstract policy files end up being essentially the same.

If your Web Service is associated with an abstract policy file and it is published as an attachment to the WSDL (which is the default behavior), the static WSDL file packaged in the Web Service archive file (JAR or WAR) will be slightly different than the dynamic WSDL of the deployed Web Service. This is because the static WSDL, being abstract, does not include specific <SecurityToken> elements, but the dynamic WSDL does include these elements because the Web Services runtime has automatically filled them in when it deployed the service. For this reason, in the code that creates the JAX-RPC stub in your client application, ensure that you specify the dynamic WSDL or you will get a runtime error when you try to invoke an operation:

HelloService service = new HelloService(Dynamic_WSDL);

You can specify either the static or dynamic WSDL to the clientgen Ant task in this case. See “Browsing to the WSDL of the Web Service” in Getting Started With WebLogic Web Services Using JAX-RPC for information on viewing the dynamic WSDL of a deployed Web Service.

Concrete policy files explicitly specify the details of the security tokens at the time the Web Service is programmed. Programmers create concrete security policy files when they know, at the time they are programming the service, the details of the type of authentication (such as using x509 or SAML tokens); whether multiple private key and certificate pairs from the keystore are going to be used for encryption and digital signatures; and so on.

Auth.xml

The WebLogic Server Auth.xml file, shown below, specifies that the client application invoking the Web Service must authenticate itself with one of the tokens (username or X.509) that support authentication.

Because the pre-packaged Web Services security policy schema files are abstract, there is no specific username or X.509 token assertions in the Auth.xml file at development-time. Depending on how you have configured security for WebLogic Server, either a username token, an X.509 token, or both will appear in the actual runtime-version of the Auth.xml policy file associated with your Web Service. Additionally, if the runtime-version of the policy file includes an X.509 token and it is applied to a client invoke, then the entire body of the SOAP message is signed.

If you want to specify that only X.509, and never username tokens, be used for identity, or want to specify that, when using X.509 for identity, only certain parts of the SOAP message be signed, then you must create a custom security policy file.

<?xml version="1.0"?>

<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:wssp="http://www.bea.com/wls90/security/policy"

  >

  <wssp:Identity/>

</wsp:Policy>

Sign.xml

The WebLogic Server Sign.xml file specifies that the body and WebLogic-specific system headers of the SOAP message be digitally signed. It also specifies that the SOAP message include a Timestamp, which is digitally signed, and that the token used for signing is also digitally signed. The token used for signing is included in the SOAP message.

The following headers are signed when using the Sign.xml security policy file:

The WebLogic Server Sign.xml file is shown below:

<?xml version="1.0"?>

<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:wssp="http://www.bea.com/wls90/security/policy"
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
  xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
  >

  <wssp:Integrity>

    <wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

    <wssp:CanonicalizationAlgorithm 
          URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>

    <wssp:Target>
      <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
      <wssp:MessageParts 
          Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
          wls:SystemHeaders()
      </wssp:MessageParts>
    </wssp:Target>

    <wssp:Target>
      <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
      <wssp:MessageParts 
          Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
          wls:SecurityHeader(wsu:Timestamp)
      </wssp:MessageParts>
    </wssp:Target>

    <wssp:Target>
      <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1" />
      <wssp:MessageParts 
          Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
          wsp:Body()
      </wssp:MessageParts>
    </wssp:Target>

  </wssp:Integrity>

  <wssp:MessageAge/>

</wsp:Policy>

Encrypt.xml

The WebLogic Server Encrypt.xml file specifies that the entire body of the SOAP message be encrypted. By default, the encryption token is not included in the SOAP message.

<?xml version="1.0"?>

<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:wssp="http://www.bea.com/wls90/security/policy"
  >

  <wssp:Confidentiality>
    <wssp:KeyWrappingAlgorithm URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
    <wssp:Target>
      <wssp:EncryptionAlgorithm 
         URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
      <wssp:MessageParts 
         Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
         wsp:Body()
      </wssp:MessageParts>
    </wssp:Target>
    <wssp:KeyInfo/>
  </wssp:Confidentiality>

</wsp:Policy>

Wssc-dk.xml

Specifies that the client and Web Service share a security context, as described by the WS-SecureConversation specification, and that a derived key token is used. This ensures the highest form of security.

This policy file provides the following configuration:

If you need to change the default security context and derived key behavior, you will have to create a custom security policy file, described in later sections.

<?xml version="1.0"?>

<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:wssp="http://www.bea.com/wls90/security/policy"
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
  xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
  >

  <wssp:Integrity SupportTrust10="true">
    <wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
    <wssp:CanonicalizationAlgorithm URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>

    <wssp:Target>
      <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
          wls:SystemHeaders()
      </wssp:MessageParts>
    </wssp:Target>

    <wssp:Target>
      <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
          wls:SecurityHeader(wsu:Timestamp)
      </wssp:MessageParts>
    </wssp:Target>

    <wssp:Target>
      <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
       wsp:Body()
      </wssp:MessageParts>
    </wssp:Target>

    <wssp:SupportedTokens>
      <wssp:SecurityToken IncludeInMessage="true"
        TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"
        DerivedFromTokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
        <wssp:Claims>
          <wssp:Label>WS-SecureConversationWS-SecureConversation</wssp:Label>
          <wssp:Length>16</wssp:Length>
        </wssp:Claims>
      </wssp:SecurityToken>
    </wssp:SupportedTokens>

  </wssp:Integrity>

  <wssp:Confidentiality SupportTrust10="true">

    <wssp:Target>
      <wssp:EncryptionAlgorithm URI="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
      <wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()</wssp:MessageParts>
    </wssp:Target>

    <wssp:KeyInfo>
      <wssp:SecurityToken IncludeInMessage="true"
        TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"
        DerivedFromTokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
        <wssp:Claims>
          <wssp:Label>WS-SecureConversationWS-SecureConversation</wssp:Label>
          <wssp:Length>16</wssp:Length>
        </wssp:Claims>
      </wssp:SecurityToken>
    </wssp:KeyInfo>

  </wssp:Confidentiality>

  <wssp:MessageAge/>

</wsp:Policy>

Wssc-sct.xml

Specifies that the client and Web Service share a security context, as described by the WS-SecureConversation specification. In this case, security context tokens are used to encrypt and sign the SOAP messages, which differs from Wssc-dk.xml in which derived key tokens are used. The Wssc-sct.xml policy file is provided to support all the use cases of the specification; for utmost security, however, Oracle recommends you always use Wssc-dk.xml when specifying shared security contexts due to its higher level of security.

This security policy file provides the following configuration:

If you need to change the default security context and derived key behavior, you will have to create a custom security policy file, described in later sections.

<?xml version="1.0"?>

<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:wssp="http://www.bea.com/wls90/security/policy"
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
  xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
  >

  <wssp:Integrity SupportTrust10="true">
    <wssp:SignatureAlgorithm URI="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
    <wssp:CanonicalizationAlgorithm URI="http://www.w3.org/2001/10/xml-exc-c14n#"/>

    <wssp:Target>
      <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>      <wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
         wls:SystemHeaders()
      </wssp:MessageParts>
    </wssp:Target>

    <wssp:Target>
      <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <wssp:MessageParts Dialect="http://www.bea.com/wls90/security/policy/wsee#part">
         wls:SecurityHeader(wsu:Timestamp)
      </wssp:MessageParts>
    </wssp:Target>

    <wssp:Target>
      <wssp:DigestAlgorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
      wsp:Body()
      </wssp:MessageParts>
    </wssp:Target>

    <wssp:SupportedTokens>
      <wssp:SecurityToken IncludeInMessage="true"
        TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
      </wssp:SecurityToken>
    </wssp:SupportedTokens>

  </wssp:Integrity>

  <wssp:Confidentiality SupportTrust10="true">

    <wssp:Target>
      <wssp:EncryptionAlgorithm URI="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
      <wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">
wsp:Body()</wssp:MessageParts>
    </wssp:Target>

    <wssp:KeyInfo>
      <wssp:SecurityToken IncludeInMessage="true"
        TokenType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct">
      </wssp:SecurityToken>
    </wssp:KeyInfo>
  </wssp:Confidentiality>

  <wssp:MessageAge />

</wsp:Policy>

Copyright © 1994, 2016, Oracle and/or its affiliates. All rights reserved.