WebLogic web services implement the following OASIS Standard 1.1 Web Services Security (WS-Security 1.1 (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss) specifications, dated February 1, 2006:

• WS-Security 1.0 and 1.1

• Username Token Profile 1.0 and 1.1

• X.509 Token Profile 1.0 and 1.1

• SAML Token Profile 1.0 and 1.1

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).

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

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

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

The following OASIS WS-SX TC Web Services SecurityPolicy namespace is 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.

• Trust10 and Trust13 assertion. Both Trust10 and Trust13 assertions are supported.

• SC10SecurityContextToken and SC13SecurityContextToken, as described in Specification Backward Compatibility.

• Derived Key using different WSSC versions (200502, 1.3).

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:

• (1) WS-SecurityPolicy 1.2 OASIS standard.

• (2) WS-SecurityPolicy 1.2, as included in WebLogic Server 10.0.

• (3) Proprietary format WebLogic Server 9.x-style policies (deprecated).

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 the following Version-Independent Matrix table.

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.

The WebLogic Server web service security policies support both the SHA-1 and much stronger SHA-2 (SHA-256) secure hash algorithms for hashing digital signatures. In addition to the SHA-2 secure hash algorithm, FIPS 140-2 mode requires a stronger digital signature method algorithm which is supported by extended algorithm suite policies. See Using the Extended Algorithm Suite. If digital signatures in the FIPS-140 mode are not required in your environment, then you can use the SHA-256 policies.

The predefined web service security policies select which specific algorithm they use in the <sp:AlgorithmSuite> element.

WebLogic Server includes policies such as Wssp1.2-2007-Wss1.1-X509-Basic256Sha256.xml that specifically use the SHA-256 secure hash algorithm, as shown in Table 2-2.

If an SHA-256 version of a policy you want to use exists, use it instead of the older SHA-1 version.

1. Update your JWS file, adding WebLogic-specific @Policy and @Policies JWS annotations to specify the predefined policy files that are attached to either the entire web service or to particular operations.

   See Updating the JWS File with @Policy and @Policies Annotations, which describes how to specify any policy file.

2. Recompile and redeploy your web service as part of the normal iterative development process.

   See Developing WebLogic Web Services in Developing JAX-WS Web Services for Oracle WebLogic Server.

3. Create a keystore used by the client application. Oracle recommends that you create one client keystore per application user.

   You can use the Cert Gen utility or keytool utility to perform this step. For development purposes, the keytool utility is the easiest way to get started. See Keytool in JDK Tool Specifications.

   See Obtaining Private Keys, Digital Signatures, and Trusted Certificate Authorities in Administering Security for Oracle WebLogic Server.

4. Create a private key and digital certificate pair, and load it into the client keystore. The same pair will be used to both digitally sign the client's SOAP request and encrypt the SOAP responses from WebLogic Server.

   Make sure that the certificate's key usage allows both encryption and digital signatures. Also see Ensuring That WebLogic Server Can Validate the Client's Certificate for information about how WebLogic Server ensures that the client's certificate is valid.

   Note:

   Oracle requires a key length of 1024 bits or larger.

   You can use the Keytool utility to perform this step. See Keytool in JDK Tool Specifications.

   See Obtaining Private Keys, Digital Signatures, and Trusted Certificate Authorities in Administering Security for Oracle WebLogic Server.

5. Using the WebLogic Remote Console, create users for authentication in your security realm.

   See Securing Resources Using Roles and Policies for Oracle WebLogic Server.

6. Update your client application by adding the Java code to invoke the message-secured web service.

   See Using a Client-Side Security Policy File.

7. Recompile your client application.

   See Developing JAX-WS Web Services for Oracle WebLogic Server for general information.

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:

• Ensure that the client application obtains a digital certificate that WebLogic Server automatically trusts, because it has been issued by a trusted certificate authority.

• Create a certificate registry that lists all the individual certificates trusted by WebLogic Server, and then ensure that the client uses one of these registered certificates.

See SSL Certificate Validation in Administering Security for Oracle WebLogic Server.

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.

1. Obtain two private key and digital certificate pairs to be used by the web services runtime. One of the pairs is used for digitally signing the SOAP message and the other for encrypting it.

   Although not required, Oracle recommends that you obtain two pairs that will be used only by WebLogic web services. You must also ensure that both of the certificate's key usage matches what you are configuring them to do. For example, if you are specifying that a certificate be used for encryption, be sure that the certificate's key usage is specified as for encryption or is undefined. Otherwise, the web services security runtime will reject the certificate.

   Note:

   Oracle requires that the key length be 1024 bits or larger.

   You can use the Cert Gen utility or the keytool utility to perform this step. For development purposes, the keytool utility is the easiest way to get started. See Keytool in JDK Tool Specifications.

   See Obtaining Private Keys, Digital Signatures, and Trusted Certificate Authorities in Administering Security for Oracle WebLogic Server.

2. Create, if one does not currently exist, a custom identity keystore for WebLogic Server and load the private key and digital certificate pairs you obtained in the preceding step into the identity keystore.

   If you have already configured WebLogic Server for SSL, then you have already created an identity keystore that you can also use in this step.

   You can use WebLogic's ImportPrivateKey utility and the keytool utility to perform this step. For development purposes, the keytool utility is the easiest way to get started. See Keytool in JDK Tool Specifications.

   See Creating a Keystore and Creating a Keystore Using ImportPrivateKey in Administering Security for Oracle WebLogic Server.

3. Using the WebLogic Remote Console, configure WebLogic Server to locate the keystore you created in the preceding step. If you are using a keystore that has already been configured for WebLogic Server, you do not need to perform this step.

   See Configuring Keystores for Production in Administering Security for Oracle WebLogic Server.

4. Using the WebLogic Remote Console, create the default web service security configuration, which must be named default_wss. 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.
5. Update the default web services security configuration you created in the preceding step to use one of the private key and digital certificate pairs for digitally signing SOAP messages.

   When you create the properties used to identify the keystore and key pair, enter the exact value for the Name of each property (such as IntegrityKeyStore, IntegrityKeyStorePassword, and so on), but enter the value that identifies your own previously-created keystore and key pair in the Value fields.

6. Similarly, update the default web services security configuration you created in a preceding step to use the second private key and digital certificate pair for encrypting SOAP messages.

   When you create the properties used to identify the keystore and key pair, enter the exact value for the Name of each property (such as ConfidentialityKeyStore. ConfidentialityKeyStorePassword, and so on), but enter the value that identifies your own previously-created keystore and key pair in the Value fields.

1. In your EJB, servlet, or JWS code, invoke the web service operation as if it were not configured for message-level security. Specifically, do not create a CredentialProvider object that contains username or X.509 tokens, and do not use the TrustManager core security API to validate the certificate from the WebLogic Server hosting the secure web service. The reason you should not use these APIs in your client code is that the web services runtime will perform this work for you.
2. Using the WebLogic Remote Console, configure the required credential mapping providers of the core security of the WebLogic Server instance that hosts your client application. The list of required credential mapper providers depends on the policy file that is attached to the web service you are invoking. Typically, you must configure the credential mapper providers for both username/password and X.509 certificates. See Valid Class Names and Token Types for Credential Provider for the possible values.

   Note:

   WebLogic Server includes a credential mapping provider for username/passwords and X.509. However, only username/password is configured by default.

3. Using the WebLogic Remote Console, create the actual credential mappings in the credential mapping providers you configured in the preceding step. You must map the user principal, associated with the client running in the server, to the credentials that are valid for the web service you are invoking. See Configuring a WebLogic Credential Mapping Provider in Administering Security for Oracle WebLogic Server.
4. Using the WebLogic Remote Console, configure the core WebLogic Server security framework to trust the X.509 certificate of the invoked web service. See Configuring the Certificate Lookup and Validation Framework in Administering Security for Oracle WebLogic Server.

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

• For WS-SecureConversation 1.3:

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

• For WS-SecureConversation 1.2:

  http://schemas.xmlsoap.org/ws/2005/02/sc
  http://schemas.xmlsoap.org/ws/2005/02/sc/sct
  

• For SAML 1.1:

  urn:oasis:names:tc:SAML:1.0:assertion
  

  Supported confirmation method are sender-vouches, holder-of-key, and bearer. Symmetric holder-of-key is not supported.

• For SAML 2.0:

  urn:oasis:names:tc:SAML:2.0:assertion
  

  Supported confirmation methods are sender-vouches, holder-of-key and bearer. Symmetric holder-of-key is not supported.

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.

• STS URI (WS-SecureConversation and SAML)

• STS security policy (SAML)

• STS SOAP version (SAML)

• STS WS-Trust version (SAML)

• STS Server Certificate (SAML)

This section describes the following topics:

• Obtaining the URI of the Secure Token Service

• Configuring STS URI for WS-SecureConversation: Standalone Client

• Configuring STS URI for SAML: Standalone Client

• Configuring STS URI Using WLST: Client On Server Side

• Configuring STS Security Policy: Standalone Client

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

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

• Configuring the SAML STS Server Certificate: Standalone Client

You can configure a client application to use WS-Trust to retrieve the SAML 2.0 bearer token from STS, and then use the SAML token for authentication on the bootstrap message on secure conversation.

In this scenario, transport-level message protection is used for WS-Trust message exchange between a client and the SAML STS, as well as the bootstrap message on secure conversation. A public key and private key are not required for this standalone client.

The policy for the service side is similar to the predefined WS-Policy file Wssp1.2-2007-Wssc1.3-Bootstrap-Https-UNT.xml, except the following <sp:SupportingTokens> is used in the policy instead:

<sp:SupportingTokens>
   <wsp:Policy>
      <sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
         <wsp:Policy>
              <sp:WssSamlV20Token11/>
         </wsp:Policy>
      </sp:SamlToken>
   </wsp:Policy>
</sp:SupportingTokens>

The policy that is used to protect the WS-Trust message between the WS-Trust client and the remote STS server is a copy of the packaged security policy file Wssp1.2-2007-Https-UsernameToken-Plain.xml, which uses username token for authentication in transport-level message protection.

When invoking the web service from the client, it 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 major difference is that you need to configure two STS endpoints: one for the retrieved SAML token, and another for getting the Security Context Token (SCT) for Secure Conversation.

Example 2-9 shows a simple example of a client application invoking a web service under JAX-WS that is retrieving a SAML token via WS-Trust. It is associated with a security policy that enables secure conversations by using HTTPS transport-level protection. The sections in bold are relevant to security contexts and are described after the example:

package examples.webservices.samlwsschttps.client;
 
import weblogic.security.SSL.TrustManager;
import weblogic.wsee.message.WlMessageContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.saml.SAMLTrustCredentialProvider;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.wsee.jaxrpc.WLStub;
import weblogic.wsee.security.util.CertUtils;
import com.sun.xml.ws.developer.MemberSubmissionAddressingFeature;
import java.security.cert.X509Certificate;
import javax.xml.ws.*;
import javax.xml.namespace.*;
import javax.net.ssl.HttpsURLConnection;
import java.net.URL;
import java.io.File;
import java.io.IOException;
import java.io.InputStream;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
 
public class TravelAgencyClient {
 
  public static final String STS_POLICY = "StsHttpsUntPolicy.xml";
  static {
    HttpsURLConnection.setDefaultHostnameVerifier(new MyHostnameVerifier());
    try {
      String defaultTrustStore = new File(TravelAgencyClient.class.getResource("/cacerts").getFile()).getCanonicalPath();
      System.out.println("Default trustStore:\t" + defaultTrustStore);
      System.setProperty("javax.net.ssl.trustStore", defaultTrustStore);
    } catch (IOException e) {
      System.out.printf("can't find default trusted keystore");
    }
   }
 
  public static void main(String[] args) throws Exception {
      TravelAgencyClient client  = new TravelAgencyClient();
      String wsscStsURL = System.getProperty("wsscStsURL");
      System.out.println("WSSC StS URL \t" + wsscStsURL);                                                      
      String samlStsURL = System.getProperty("samlStsURL");
      System.out.println("StS URL \t" + samlStsURL);
      String hotelWsdlURL = System.getProperty("hotelWsdlURL");
      System.out.println("Hotel Service WSDL URL \t" + hotelWsdlURL);
 
      String hotelResult = client.callWsscHotelService("Travel Agency client to Hotel Service", wsscStsURL,hotelWsdlURL, samlStsURL);
      System.out.println("Hotel Service return value: -->"+hotelResult);
  }
 
  public String callWsscHotelService(String hello,
                     String wsscStsURL,
                     String hotelWsdlURL,
                     String samlStsURL) throws Exception{
 
    HotelService service = new HotelService(new URL(hotelWsdlURL),
            new QName("http://wsinterop.org/samples", "HotelService"));
 
    IHotelService port = service.getIHotelServicePort(new MemberSubmissionAddressingFeature());
 
    BindingProvider provider = (BindingProvider)port;
    this.configurePort(provider, wsscStsURL, samlStsURL);
 
    try {
          // for securie conversation, it can call twice
      String s1 = port.getName(hello);
      String s2 = port.getName(hello + " --- " + s1) ;
      WSSCClientUtil.terminateWssc((BindingProvider)port);
      return s2;
    } catch (Exception ex) {
        ex.printStackTrace();
      throw new RuntimeException("fail to call the remote hotel service!", ex);
    }
  }
 
 private void configurePort(BindingProvider provider, String wsscStsURL, String samlStsURL) throws Exception {
 
    Map context = provider.getRequestContext();
    InputStream policy = getPolicy(STS_POLICY);
    context.put(WlMessageContext.WST_BOOT_STRAP_POLICY, policy);
    if (null != wsscStsURL) {
        context.put(WLStub.WST_STS_ENDPOINT_ON_WSSC, wsscStsURL);
    }
    context.put(WLStub.WST_STS_ENDPOINT_ON_SAML, samlStsURL);
    context.put(WSSecurityContext.TRUST_MANAGER,
        new TrustManager() {
          public boolean certificateCallback(X509Certificate[] chain,
                                             int validateErr) {
            // need to validate if the server cert can be trusted
            return true;
          }
        });
    List credProviders = buildCredentialProviderList();
    context.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);

    context.put(com.sun.xml.ws.developer.JAXWSProperties.HOSTNAME_VERIFIER, new MyHostnameVerifier());
  }
 
  private static List buildCredentialProviderList() throws Exception  {
    List credProviders = new ArrayList();
    credProviders.add(new SAMLTrustCredentialProvider());
    credProviders.add(getClientUNTCredentialProvider());
    return credProviders;
  }
  private static CredentialProvider getClientUNTCredentialProvider() throws Exception {
    String username = System.getProperty("target.username", "Alice");
    String password = System.getProperty("target.password", "Password1");
    return new ClientUNTCredentialProvider(username.getBytes(),
        password.getBytes());
  }
  private  InputStream getPolicy(String policyName) {
    String resName = '/' + this.getClass().getPackage().getName().replace('.', '/') + '/' + policyName;
    InputStream  stsPolicy = this.getClass().getResourceAsStream(resName);
    if(stsPolicy == null)    {
        throw new RuntimeException("STS policy is not correctly set!");
    }
    return stsPolicy;
  }
  public static class MyHostnameVerifier implements javax.net.ssl.HostnameVerifier {
      public boolean verify(String hostname, javax.net.ssl.SSLSession session) {
        return(true);
     }
    }      
} 

Similar to Example 2-9, you can configure a client application to use WS-Trust to retrieve the SAML 2.0 bearer token from STS, and then use the SAML token for authentication on the bootstrap message on secure conversation. However, instead of using HTTPS transport-level message protection, it uses WS-Security 1.1 message-level protection, and HTTPS configuration is not required.

In this scenario, the STS server's X.509 certificate is used to protect the WS-Trust message exchange between the client and the SAML STS, and the server's X.509 certificate is used to protect the bootstrap message on secure conversation. A public key and private key are not required for this standalone client.

The policy for the service side is similar to the packaged WS-Policy file Wssp1.2-2007-Wssc1.3-Bootstrap-Wss1.1.xml, except that it uses a SAML 2.0 token for authentication in the bootstrap message instead of the client's X.509 certificate. That is, it uses a <sp:SignedSupportingTokens> assertion with a SAML token inside the policy instead of using a <sp:SignedEndorsingSupportingTokens> assertion.

The entire secure conversation policy is as follows:

<?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"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <sp:SymmetricBinding>
    <wsp:Policy>
      <sp:ProtectionToken>
        <wsp:Policy>
          <sp:SecureConversationToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
            <wsp:Policy>
              <sp:RequireDerivedKeys/>
              <sp:BootstrapPolicy>
                <wsp:Policy>
                  <sp:SignedParts>
                    <sp:Body/>
                    <sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"/>
                    <sp:Header Namespace="http://www.w3.org/2005/08/addressing"/>
                  </sp:SignedParts>
                  <sp:EncryptedParts>
                    <sp:Body/>
                  </sp:EncryptedParts>
                  <sp:SymmetricBinding>
                    <wsp:Policy>
                      <sp:ProtectionToken>
                        <wsp:Policy>
                          <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
                            <wsp:Policy>
                              <sp:RequireDerivedKeys/>
                              <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:SignedSupportingTokens>
                    <wsp:Policy>
                      <sp:SamlToken
  sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/
IncludeToken/AlwaysToRecipient">
                        <wsp:Policy>
                          <sp:WssSamlV20Token11/>
                        </wsp:Policy>
                      </sp:SamlToken>
                    </wsp:Policy>
                  </sp:SignedSupportingTokens>
                  <sp:Wss11>
                    <wsp:Policy>
                      <sp:MustSupportRefKeyIdentifier/>
                      <sp:MustSupportRefIssuerSerial/>
                      <sp:MustSupportRefThumbprint/>
                      <sp:MustSupportRefEncryptedKey/>
                      <sp:RequireSignatureConfirmation/>
                    </wsp:Policy>
                  </sp:Wss11>
                </wsp:Policy>
              </sp:BootstrapPolicy>
            </wsp:Policy>
          </sp:SecureConversationToken>
        </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:ProtectTokens/>
      <sp:OnlySignEntireHeadersAndBody/>
    </wsp:Policy>
  </sp:SymmetricBinding>
  <sp:Wss11>
    <wsp:Policy>
      <sp:MustSupportRefKeyIdentifier/>
      <sp:MustSupportRefIssuerSerial/>
      <sp:MustSupportRefThumbprint/>
      <sp:MustSupportRefEncryptedKey/>
      <sp:RequireSignatureConfirmation/>
    </wsp:Policy>
  </sp:Wss11>
  <sp:Trust13>
    <wsp:Policy>
      <sp:MustSupportIssuedTokens/>
      <sp:RequireClientEntropy/>
      <sp:RequireServerEntropy/>
    </wsp:Policy>
  </sp:Trust13>
</wsp:Policy>  

The policy that is used to protect the WS-Trust message between the WS-Trust client and the remote STS server is a copy of packaged security policy Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey.xml, which uses the username token for authentication and WS-Security 1.1 message-level security.

The entire security policy is as follows:

<?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">
  <sp:SymmetricBinding>
    <wsp:Policy>
      <sp:ProtectionToken>
        <wsp:Policy>
          <sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/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:SignedEncryptedSupportingTokens>
    <wsp:Policy>
      <sp:UsernameToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
        <wsp:Policy>
          <sp:WssUsernameToken10/>
        </wsp:Policy>
      </sp:UsernameToken>
    </wsp:Policy>
  </sp:SignedEncryptedSupportingTokens>
  <sp:Wss11>
    <wsp:Policy>
      <sp:MustSupportRefKeyIdentifier/>
      <sp:MustSupportRefIssuerSerial/>
      <sp:MustSupportRefThumbprint/>
      <sp:MustSupportRefEncryptedKey/>
      <sp:RequireSignatureConfirmation/>
    </wsp:Policy>
  </sp:Wss11>
  <sp:SignedParts>
    <sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"/>
    <sp:Header Namespace="http://www.w3.org/2005/08/addressing"/>
    <sp:Body/>
  </sp:SignedParts>
  <sp:EncryptedParts>
    <sp:Body/>
  </sp:EncryptedParts>
</wsp:Policy>  

When invoking a web service from the WS-Trust client, the configurations are mostly similar to the previous example. The major differences are:

• You need to configure two encryption certificates: one is the certificate of the STS for SAML token retrieval, and the other is the certificate for the server.

• Configuring the service STS endpoint address for secure conversation is not required. When the bootstrap message is not protected by transport-level security, by default the STS endpoint address is the same as the service endpoint address for security conversation.

• The SSL configuration is not required.

Example 2-10 shows a simple example of a client application invoking a web service under JAX-WS that is retrieving a SAML token via WS-Trust. It is associated with a security policy that enables secure conversations by using WS-Security 1.1 message-level security. The sections in bold are relevant to security contexts and are described after the example:

package examples.webservices.samlwssc.client;
 
import weblogic.security.SSL.TrustManager;
import weblogic.wsee.message.WlMessageContext;
import weblogic.wsee.security.bst.ClientBSTCredentialProvider;
import weblogic.wsee.security.saml.SAMLTrustCredentialProvider;
import weblogic.wsee.security.unt.ClientUNTCredentialProvider;
import weblogic.xml.crypto.wss.WSSecurityContext;
import weblogic.xml.crypto.wss.provider.CredentialProvider;
import weblogic.wsee.jaxrpc.WLStub;
import weblogic.wsee.security.util.CertUtils;
import weblogic.wsee.security.wssc.utils.WSSCClientUtil;
import com.sun.xml.ws.developer.MemberSubmissionAddressingFeature;
 
. . .
 
public class TravelAgency1Client {
 
    public static final String STS_POLICY = "StsWss11UntPolicy.xml";
 
    public static void main(String[] args) throws Exception {
        TravelAgencyClient client = new TravelAgencyClient();
        String stsURL = System.getProperty("stsURL");
        System.out.println("StS URL \t" + stsURL);
 
        String hotelWsdlURL = System.getProperty("hotelWsdlURL");
        System.out.println("Hotel Service WSDL URL \t" + hotelWsdlURL);
        String hotelResult = client.callWsscHotelService("Travel Agency client to Hotel Service", stsURL, hotelWsdlURL);
        System.out.println("Hotel Service return value: -->" + hotelResult);
    }
 
    public String callWsscHotelService(String hello,
                                       String stsurl,
                                       String hotelWsdlURL) throws Exception {
 
        HotelService service = new HotelService(new URL(hotelWsdlURL),
                new QName("http://wsinterop.org/samples", "HotelService"));
 
        IHotelService port = service.getIHotelServicePort(new MemberSubmissionAddressingFeature());
 
        BindingProvider provider = (BindingProvider) port;
        this.configurePort(provider, stsurl);
 
        try {
            // for secure conversation, it can call twice
            String s1 = port.getName(hello);
            String s2 = port.getName(hello + " --- " + s1);
            WSSCClientUtil.terminateWssc((BindingProvider)port);
            return s2;
        } catch (Exception ex) {
            ex.printStackTrace();
            throw new RuntimeException("fail to call the remote hotel service!", ex);
        }
    }
 
    private void configurePort(BindingProvider provider, String stsurl) throws Exception {
 
        Map context = provider.getRequestContext();
        InputStream policy = getPolicy(STS_POLICY);
        context.put(WlMessageContext.WST_BOOT_STRAP_POLICY, policy);
        context.put(WLStub.WST_STS_ENDPOINT_ON_SAML, stsurl);
        context.put(WLStub.STS_ENCRYPT_CERT, getStsCert());
        context.put(WLStub.SERVER_ENCRYPT_CERT, getServerCert());
        List credProviders = buildCredentialProviderList();
        context.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders);
        context.put(WLStub.POLICY_COMPATIBILITY_PREFERENCE, WLStub.POLICY_COMPATIBILITY_MSFT);
    }
 
    private static List buildCredentialProviderList() throws Exception {
        List credProviders = new ArrayList();
        credProviders.add(new SAMLTrustCredentialProvider());
        credProviders.add(getClientUNTCredentialProvider());
        return credProviders;
    }
 
	. . .
 
    private static X509Certificate getServerCert() throws Exception {
        String defaultServerCert = new File(
TravelAgency1Client.class.getResource("/Bob.cer").getFile()).getCanonicalPath();
        String certName = System.getProperty("target.serverCert",
		 defaultServerCert);
        X509Certificate cert = CertUtils.getCertificate(certName);
        return cert;
    }
}  

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:

• The Web Services Secure Conversation (WS-SecureConversation 1.3) specification requires a token service to return wst:RequestedSecurityToken to the initiating party in response to a wst:RequestSecurityToken. One or more wst:RequestSecurityTokenResponse elements are contained within a single wst:RequestSecurityTokenResponseCollection.

  This differs from the previous version of the specification, in which wst:RequestSecurityTokenResponse was returned by the token service.

  The token service can return wst:RequestSecurityTokenResponse if the service policy specifies the SC10SecurityContextToken, as described in the next bullet item.

• The WS-SecurityPolicy 1.2 Errata document describes the following change to SecureConversationToken Assertion:

  <sp:SC10SecurityContextToken />

  changes to

  <sp:SC13SecurityContextToken />

  sp:SC10SecurityContextToken continues to be supported only when used with the WS-SecureConversation version of 02/2005.

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.

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.

You can configure the SCT expiration value by setting SCT lifetime property. The SCT expiration value is then used to time out the SCT. When the timeout is reached, the web services runtime on the client side automatically renews the SCT. The web services runtime automatically cancels the unused secure context token when the timeout is reached.

The SAML Token Profile 1.1 (http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf) is part of the core set of WS-Security standards, and specifies how SAML assertions can be used for web services security. WebLogic Server 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, it is assumed that users use username tokens to authenticate themselves. Because WebLogic Server implements the SAML Token Profile 1.1 (http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf) 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.

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

• For WSS1.0 Asymmetric Binding, if the SamlToken assertion is inside the <sp:AsymmerticBinding> assertion, then the Holder of Key confirmation method is used.

  For WSS1.1 Symmetric Binding, if the SamlToken assertion is inside the <sp:EndorsingSupportingTokens> assertion, then the Holder of Key confirmation method is used.

  See Table 2-13 for examples of predefined policies that use Holder of Key confirmation.

• For WSS1.0 Asymmetric Binding, if the SamlToken assertion is inside <sp:SignedSupportingTokens>, then the Sender Vouches confirmation method is used.

  For WSS1.1 Symmetric Binding, if the SamlToken assertion is inside the <sp:SignedSupportingTokens> assertion, and the <sp:X509Token> is used in the <sp:EndorsingSupportingTokens> assertion, then the Sender Vouches confirmation method is used.

  For Transport Binding, two-way SSL with client certification is required for the Sender Vouches confirmation method. Use transport-level security as described in Configuring Transport-Level Security in this case.

  See Table 2-13 for examples of predefined policies that use Sender Vouches confirmation.

• For transport-level security, if the SamlToken assertion is inside <sp:SupportingTokens>, then the Bearer confirmation method is used. Use transport-level security as described in Configuring Transport-Level Security in this case.

  For WSS1.1 Symmetric Binding, if the SamlToken assertion is inside the <sp:SignedSupportingTokens> assertion, and there is no <sp:EndorsingSupportingTokens> assertion, then the Bearer confirmation method is used.

  See Table 2-13 for examples of predefined policies that use Bearer confirmation.

This release of WebLogic Server includes a SAML 1.1 Bearer example with a standalone client. This example is available in the WebLogic Server installation in WLS_HOME\samples\server\examples\src\examples\webservices\saml\bearer11ssl.

This is an example of SAML 1.1 Bearer with a standalone client. It demonstrates the minimum configuration and setup with WS-Trust to use a SAML assertion for authentication of a web service application. The example contains two WebLogic Server instances, which host the FlightService web service and STSHttpsUNT.java used as a Security Token Service (STS), respectively.

The client TravelAgencyClient does not have a public/private key pair and gets the SAML token from the STS for authentication, with transport level message protection.

A SAML assertion is a piece of data produced by a SAML authority regarding either an act of authentication performed on a subject, attribute information about the subject, or authorization data applying to the subject with respect to a specified resource.

The SAML specification (see http://www.oasis-open.org) allows additional, unspecified information about a particular subject to be exchanged between SAML partners as attribute statements in an assertion. A SAML attribute assertion is therefore a particular type of SAML assertion that conveys site-determined information about attributes of a Subject.

Attribute data is of type String.

Attributes are often name/value pairs (for example name=position, value=team lead), with multiple values being possible, but there is no requirement that they follow this model.

SAML attributes can be examined on the target partner service, and they can be used as extra information for authentication or authorization.

Use of SAML attributes works server-to-server. This means that the client application providing the attributes is running inside of a WebLogic Server instance. It then invokes a web service running in the same or other WebLogic Server instance to consume the attributes. Because the client application is itself a web service, the web services security runtime takes care of all the SAML processing.

1. Create the client-side security policy files and save them in a location accessible by the client application. Typically, the security policy files are the same as those configured for the web service you are invoking, but because the server-side files are not exposed to the client runtime, the client application must load its own local copies.

   See Creating and Using a Custom Policy File for information about creating security policy files.

2. Update the build.xml file that builds your client application.
3. Update your Java client application to load the client-side policy files
4. Rebuild your client application by running the relevant task. For example:

   prompt> ant build-client

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:

1. Run the web service without element-level security.

2. Turn on SOAP tracing.

3. Inspect the SOAP message in the logs.

4. Produce the XPath expression from the SOAP message.

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 Example 2-14.

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.oracle.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>

<?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.oracle.com/OrderService">
/soapenv:Envelope/soapenv:Body/myns:submitOrderRequest/myns:OrderRequest/myns:creditCard
    </sp:XPath>
  </sp:EncryptedElements>
</wsp:Policy>

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

• You can include multiple element-level assertions in a policy; all are executed.

• You can include multiple <sp:XPath> expressions in a single assertions; all are executed.

• The EncryptedElements assertion causes the identified element and all of its children to be encrypted.

• The ContentEncryptedElements assertion does not encrypt the identified element, but does encrypt all of its children.

• The RequiredElements assertion may be used to test for the presence of a top-level element in the SOAP header. If the element is not found, a SOAP Fault will be raised.

  RequiredElements assertions cannot be used to test for elements in the SOAP Body.

Example 2-17 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>

You can configure multiple policy alternatives for a single web service by creating a custom policy, as shown in Example 2-17. You then configure the web service client to make a policy selection preference.

You can configure the policy selection preferences for the web service client by using the WebLogic Remote Console, and using stubs.

The following preferences are supported:

• Security

• Performance

• Compatibility

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.

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.

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

• web service whose operations can be invoked using reliable and secure SOAP messaging (destination endpoint). The destination ReliableEchoService web service has two operations that can be invoked reliably and in a secure way: echo and echoOneway.

• Client web service that invokes an operation of the first web service in a reliable and secure way (source endpoint). The source ReliableEchoClientService web service has one operation for invoking the echo and echoOneway operations of the ReliableEchoService web service reliably and in a secure way within one conversation: echo.

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.

The ReliableEchoServiceImpl.java JWS file is the same as that in EXAMPLES_HOME\wl_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")}
)

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 EXAMPLES_HOME\wl_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
:

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 EXAMPLES_HOME\wl_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
:

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

There are no changes needed to these steps.