HCM Atom Feed Subscriber using SOA Cloud Service

Introduction HCM Atom feeds provide notifications of Oracle Fusion Human Capital Management (HCM) events and are tightly integrated with REST services. When an event occurs in Oracle Fusion HCM, the corresponding Atom feed is delivered automatically to the Atom server. The feed contains details of the REST resource on which the event occurred. Subscribers who consume these […]

Using File Based Loader for Fusion Product Hub

Using File Based Loader for Fusion Product Hub Introduction File Based Loaders (FBL) offer a broad bandwidth of varieties to import batch data manually by user interaction or automated via locally scheduled processes using existing API’s and Web Services. This article will highlight the Fusion Product Hub specific capabilities to import item data in a […]

Integrating with Sales Cloud using SOAP web services and REST APIs (Part 2)

This is part 2 of the blog series that covers SOAP and REST integration with Sales Cloud In part 1, I covered the topic of invoking Sales Cloud SOAP web services from external applications. In this part, I will cover the topic of invoking external SOAP services from Sales Cloud.   2. Invoking external SOAP Web Services from Sales Cloud Sales Cloud Application […]

Integrating with Oracle Sales Cloud using SOAP web services and REST APIs (Part 1)

Sales Cloud provides several types of interfaces to facilitate integration with other applications within your enterprise or on the cloud, such as SOAP web services, REST APIs, Events, file-loaders, and BI Reports. The focus of this blog series is SOAP web services and REST APIs. Sales Cloud provides SOAP web services and REST APIs for other applications to operate on core […]

Moving To Oracle WebCenter Content 11g Web Services

Introduction Oracle WebCenter Content 11g now provides a new set of JAX-WS Web Services interfaces, read on to find out more details about how to integrate with Oracle WebCenter Content Server 11g using these new Web Services interfaces. Main Article Oracle WebCenter Content (formerly UCM) has been a pioneer in Services Oriented Architecture long before the […]

Non-Standard approaches to SOA Identity Propagation and Authentication

I wanted to take some time to talk about a couple non-standard approaches to identity propagation and authentication that I sometimes see people take when building their web services.

These approaches are non-standard both because they well… don’t utilize the large body of standards that exist for web service security and because they are outside of what would probably be considered best practices by most people in the industry.

Custom Security Headers

It is fairly common to see people develop services that require authentication through a custom security header.

Now, if your service will consume a token that is truly custom, which is to say outside the standard token types defined in the WSS specs, then this is a perfectly reasonable approach. A good example of this would be a service that can consume a web SSO token from Oracle Access Manager.

This approach is especially powerful if your service can consume the custom token plus one or more of the standard tokens. One example would be a service setup to consume the Oracle Access Manager cookie or a standard username token.

However, one mistake you often see people make is to hard code in a required custom security header that is in essence the same as one of the standard WSS authentication methods. Usually, it is a custom security header that just holds a username and password, which makes it equivalent to the WSS username token.

There are several reasons developers take this approach but they mostly center on not understanding the flexibility and value of the security functionality that is already built into the container that is running their service. For example, sometimes developers will say that they need a custom token since the container will only compare the username in username token to the UID attribute in the directory, which is simply not the case.

Even if custom handling of authentication is required, it is still better to utilize a standard token (with custom handling) over a custom token.

Another mistake you see people make is once they decide they need a custom token, they will just turn off security at the container level and process the token inside of their service. It is far better for custom authentication code to live inside of the container than in the service itself. Staying with the container for security will:

  • Allow you to easily use your custom token with other services
  • Allow you to switch to a standard authentication method down the road
  • Keep you compatible with authorization and auditing done at the container level which you may want to keep even if you need to do custom authentication.

I’d propose the following hierarchy of approaches to web service authentication and identity propagation, going from most ideal to least ideal:

  1. Use of standard authentication tokens that are processed by the container’s out-of-the-box functionality.
  2. Use of standard authentication tokens that are processed by custom code in the container.
  3. Use of custom authentication tokens/headers that are processed by custom code in the container.
  4. Use of custom authentication tokens/headers that are processed by code in the service itself.

Propagating Identity in the SOAP Request Body

The second approach I’d like to discuss is specific to propagating an identity from a web app or service to a “downstream” service. The approach is simply to stick the user identity into the body of the request and consume it with custom code in the service. Now obviously, this approach is inherently insecure on its own, but it is an appropriate option in situations where the client of the service can be trusted. Usually this trust will be justified by the security that is present at the transport or network level.

Sticking a user identity into the body of the request is really analogous to use of the SAML bearer confirmation method which I discussed in my first post on this blog.

So, it is probably most useful to think of its appropriateness in the same terms. In the blog post on the bearer confirmation method I discussed some advantages that it had over just sticking the user identity into the request body. Now, I’d like to turn the table and look at some possible advantages putting the identity in the request body sometimes has over SAML with bearer and over creating a custom security header of a similar ilk.

Now, you are probably saying to yourself: Hold on Brian, you just laid out a hierarchy with using standards and container functionality at the top and custom approaches executed in the service code at the bottom.

Well that is true, but there is a reason that putting the identity in the request body and extracting it in the service should sometimes be considered. The main problem with SAML with the bearer confirmation method is a lack of support for it. This lack of support applies not only to server side WSS stacks but, perhaps even more importantly client side stacks. If you are creating a service that may be widely consumed and are operating in a very heterogeneous environment where client side developers maybe be using any number of different software packages for their development, then SAML with bearer may be the wrong choice for you. Likewise, it may be harder for consumers of your service to create a custom security header than to just stick the identity in the request body. Along similar lines, it may be easier to convey the format you want to use for the user identity in the WSDL if the identity is being put in the body.

The final consideration for whether propagating the identity in the request body is a good way to go centers on how many services you might have where such trusted identity propagation is deemed as acceptable. If you have a huge SOA infrastructure with tons of applications consuming tons of internal services then it probably makes sense to standardize on bearer or develop a custom security header and corresponding container plug-in to consume the header.

However, if you only have one service that fits this description and SAML with bearer isn’t supported by your stack, then it may be hard to justify the added effort of developing a custom token. In that case, just sticking the user identity in the request body may be the best way to go.

Using asymmetric cryptography in OWSM

Introduction

It has been somewhat a common practice replicating the same java key store across interacting WLS domains so that web services clients and web services can chat with message protection (WSS – Web Services Security). In that case, OWSM (Oracle Web Services Manager) is able to default to the private key stored in the key store to encrypt the symmetric key used for message encryption/decryption.

While that’s acceptable in developments environments, it might not be in production mode. Organizations may want to eliminate the risk of having the private key shared and compromised in distributed WLS deployments.

This article describes how that can be implemented in OWSM by examining the required OWSM configuration and two sample client applications: one Oracle ADF using a Web Service Data Control and one non-ADF using JAX-WS proxy.

Long story short: web services providers distribute their public key to consumers, who in turn explicitly refer to them when attaching OWSM client-side policies by overriding the keystore.recipient.alias property. Keep reading if you are interested in seeing how that is done.

Configuring the WLS domain hosting the web service

Let’s first understand how OWSM gets the services it needs to work with WSS.

OWSM relies on OPSS (Oracle Platform Security Services) configuration for its required services. By default, OWSM looks for the “default” jpsContext to get a hold of them. We’re interested in credstore and keystore services. OPSS configuration is held in jps-config.xml that sits in $DOMAIN_HOME/config/fmwconfig.

In the snippet below, we’re looking at the default jpsContext in jps-config.xml.

 
   1: <jpsContexts default="default">
   2:     <!-- This is the default JPS context. All the mendatory services and Login Modules must be configured in this default context -->
   3:     <jpsContext name="default">
   4:         <serviceInstanceRef ref="credstore"/>
   5:         <serviceInstanceRef ref="keystore"/>
   6:         <serviceInstanceRef ref="policystore.xml"/>
   7:         <serviceInstanceRef ref="audit"/>
   8:         <serviceInstanceRef ref="idstore.ldap"/>
   9:     </jpsContext>

Line 5 above tells OWSM to look for the keystore serviceInstance, which is out-of-box defined as:

 
   1: <!-- KeyStore Service Instance -->
   2:         <serviceInstance name="keystore" provider="keystore.provider" location="./default-keystore.jks">
   3:             <description>Default JPS Keystore Service</description>
   4:             <property name="keystore.type" value="JKS"/>
   5:             <property name="keystore.csf.map" value="oracle.wsm.security"/>
   6:             <property name="keystore.pass.csf.key" value="keystore-csf-key"/>
   7:             <property name="keystore.sig.csf.key" value="sign-csf-key"/>
   8:             <property name="keystore.enc.csf.key" value="enc-csf-key"/>
   9:         </serviceInstance>

It basically says that ./default-keystore.jks is the keystore file holding the certificate keys for WSS.

Likewise, line 6 in the first snippet informs OWSM on the credential store service. The credential store holds the credentials required for accessing the keystore as well as the aliases defined within it. Here’s how the cred store service is configured in jps-config.xml. Notice the location attribute. It points to the current directory. In reality, the credential store (as a file) is materialized as cwallet.sso file in that directory.

 
   1: <!-- JPS Credential Store Service Instance -->
   2:         <serviceInstance name="credstore" provider="credstoressp" location="./">
   3:             <description>File Based Credential Store Service Instance</description>
   4:         </serviceInstance>

Ok, basic OPSS configuration understood, let’s create an asymmetric key pair for the WLS server hosting the web service.

To execute the subsequent commands, have the keytool tool in your system path.

> keytool -genkeypair -keyalg RSA -alias orakey -keypass welcome1 -keystore default-keystore.jks -storepass welcome1 -validity 3600 

Now default-keystore.jks contains a self-signed certificate whose encrypting algorithm is RSA. RSA will be used for encrypting the symmetric key that encrypts the SOAP message.

Notice the storepass parameter value, which is welcome1. That defines the keystore password. Also notice the alias parameter and keystore parameter values. Those need to be properly seeded in the credential store. Please refer to this article on how to create them.

Next step is exporting the public key to a file.

> keytool -export -keystore default-keystore.jks -alias orakey -file server.crt

Such public key (server.crt) is the one that is distributed to everyone who wants to call in the WSS web services in this WLS domain.

Configuring the WLS domain hosting the web service client

The same jps-config.xml configuration applies to the WLS client domain. But in the client we just need to import the server.crt file containing the server public key into the key store.

> keytool -import -trustcacerts -alias server-public-cert -file server.crt -keystore default-keystore.jks

Notice the alias name: server-public-cert. It defines to where the public key is copied within the key store. You’ll need this name when overriding the keystore.recipient.alias property in the OWSM policy attachment in the web service client application.

Overriding the keystore.recipient.alias property

In this example, our client application is an ADF one that invokes the web service via an ADF Web Service Data Control. I won’t go into the details of defining the data control here. That’s something that can be found in the ADF Developers Guide available at OTN or in JDeveloper itself.

Once the data control is defined, follow these steps:

1 – In Applications Navigator, click the DataControls.dcx file:

showDataControl

2 – In the DataControls.dcx structure, right click the ADF Data Control Web Service and then click Define Web Service Security… option:

defineWSS

3 – In the Edit Data Control Policies window, choose oracle/wss11_username_token_with_message_protection_client_policy. It will allow the client to propagate a fixed identity to the web service at the same time providing WSS to the entire SOAP message. Take a bit of time to read the policy description. It is worth it.

Do notice that choosing such policy implies that the web service is configured with the corresponding OWSM server-side policy.

policyAttachment

4 – Click the Override Properties button.

The csf-key property defined the key in the credential store that holds the user to be propagated to the web service in the UsernameToken header.

In order to create it, execute the following wlst online command in the client WLS domain:

> createCred(map=”oracle.wsm.security”,key=”manager-key”,user=”my-wife”,password=”yesdear”)

If you click the New Key.. button, you have the opportunity to define it right here (thus avoiding the wlst command above) and it will be pushed to the WLS domain credential store when you deploy your application (this “pushing credentials”  feature can be disabled if you want).

keystore.recipient.alias is what we’re really interested in this article. It references the alias name for the server public key in the WLS client domain’s key store.

overridingProperties

What if my client application is a non-ADF one?

If you had a JAX-WS proxy in a non-ADF client application, this is how you would do it.

Notice line 25. There we’re overriding the keystore.recipient.alias.

   1:
   2: import java.net.MalformedURLException;
   3: import java.net.URL;
   4: import javax.xml.namespace.QName;
   5: import javax.xml.parsers.DocumentBuilderFactory;
   6: import javax.xml.ws.BindingProvider;
   7: import oracle.j2ee.ws.common.jaxws.ServiceDelegateImpl;
   8: import oracle.webservices.ClientConstants;
   9: import oracle.wsm.security.util.SecurityConstants;
  10: import org.w3c.dom.Element;
  11:
  12:         String endpoint = "http://127.0.0.1:7101/context-root/GreetingsAppModuleService";
  13:  
  14:         URL wsdlURL = new URL(endpoint+"?WSDL");
  15:  
  16:        ServiceDelegateImpl serviceDelegate = new ServiceDelegateImpl(wsdlURL, new QName("http://xmlns.oracle.com/trunk/owsm/", "GreetingsAppModuleService"), oracle.webservices.OracleService.class);
  17:        MyAppModuleService port = serviceDelegate.getPort(new QName("http://xmlns.oracle.com/trunk/owsm/", "GreetingsAppModuleServiceSoapHttpPort"), GreetingsAppModuleService.class );
  18:        
  19:         InputStream isClientPolicy = this.getClass().getResourceAsStream("client-policy.xml");
  20:        
  21:         try {
  22:           ((BindingProvider)port).getRequestContext().put(ClientConstants.CLIENT_CONFIG, fileToElement(isClientPolicy));
  23:           ((BindingProvider)port).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpoint);
  24:           ((BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSS_CSF_KEY, "manager-key");
  25:           ((BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSS_RECIPIENT_KEY_ALIAS, "server-public-cert");
  26:         }
  27:         catch (Exception ex) {
  28:           ex.printStackTrace();
  29:         }
  30:        
  31:  
  32:         return port.sayHello(name);
  33:  
  34:     public static Element fileToElement(InputStream f) throws IOException, Exception {
  35:        DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
  36:        builderFactory.setValidating(false);
  37:        builderFactory.setNamespaceAware(true);
  38:        builderFactory.setIgnoringElementContentWhitespace(true);
  39:        builderFactory.setIgnoringComments(true);
  40:        return builderFactory.newDocumentBuilder().parse(f).getDocumentElement();
  41:     }

The client-policy.xml would be:

   1: <?xml version="1.0" encoding="UTF-8"?>
   2: <oracle-webservice-clients>
   3:    <webservice-client>
   4:        <port-info>
   5:            <policy-references>
   6:                <policy-reference uri="oracle/wss11_username_token_with_message_protection_client_policy" category="security"/>
   7:             </policy-references>
   8:        </port-info>
   9:    </webservice-client>
  10: </oracle-webservice-clients>

Conclusion

In this article I showed how to use real asymmetric cryptography in OWSM by examining the keystore configuration details and looked at how web services client applications should be configured to support it. I believe this is a very important topic, since it eliminates the risk of having a single private key shared across WLS domains that participates in web services interactions.

Oracle Entitlement Server (OES) Web Services SM Demystified

First of all – Happy New Decade – and welcome to the future!

Now, after some well deserved time off, back to it. I was recently visiting with a customer and they asked me for the WSDL associated with the Web Services SM for OES. Seems like a simple request, but what I quickly figured out was that there is no really simple way to get the WSDL (navigating to http://mywssm:8555/someservicename?WSDL). Simpler is definitely better, so this post is not a full-throated defense of how the WebServices SM works, but rather an opportunity to discuss some of the features of the OES client libraries and the PDPProxy specifically. For those who just want to see the WSDL, here it is. I’ve also included the schema, here. They can also be found in SSM_HOME/webservice-ssm/instance/instancename/config.

Three different SMs – One API – PDP Proxy

There are many different Security Modules (SM) that OES supports but they essentially fall into two categories – centralized or embedded. In the centralized model, applications are making remote calls out to the actual SM service running centrally. OES supports two protocols for centralized SMs – SOAP and RMI. These are affectionately reffered to as the WebServices SM and the RMI SM. In the embededded model, application make calls to the services OES and the authorization enginer is co-located (runs in the same Java process) as the application. This is the Java SM (though when running inside of WLS its called the WLS SM or in WebSphere the WebSphere SM etc.).

When deploying OES into Java applications, you may not know up-front which of the 3 main types of SMs make sense. Initially, you may want to use the WebServices SM because SOAP is a standard and works nicely with the rest of the SOA infrastructure. You may then move to the RMI SM because you need a binary protocol to meet performance requirements. Finally, to get maximium performance, you move to the embedded model and the Java SM. This evolution of SM deployment is natural and to be expected. What would be unatural and unexpected is to have to recode the application just because you were choosing a different SM deployment model. This is the driving thought behind the single Java API.

This is from the SSM_HOME/webservice-ssm/examples/JavaAPIExample/src/java\com\bea\security\examples\JavaAPIExample.java


protected static SecurityRuntime initializeSSM(String configId) {
SecurityRuntime rt = null;

// Initialize this applications configuration
System.out.print("Initializing the Security Runtime ... ");
AppConfig cfg = new AppConfig("Java API Example Application");

cfg.useConfiguration(configId);

// Add this application naming definitions to the config
try {
cfg.addNameAuthorityDefinitionFile("exampleNames.xml");
} catch (FileNotFoundException fnfExc) {
System.out.println(fnfExc.getLocalizedMessage());
return rt;
}

// Initialize the security runtime
try {
SecurityRuntime.initialize(cfg);
} catch (ParameterException pExc) {
// We could not get the policy domain
System.out.println(pExc.getLocalizedMessage());
return rt;
}
catch (Throwable e) {
e.printStackTrace();
return rt;
}

// Get an instance of the runtime
rt = SecurityRuntime.getInstance();
System.out.println("Initialized");

return rt;
}

protected static PolicyDomain tryGetPolicyDomain(SecurityRuntime rt, String configId) {
PolicyDomain pd = null;

try {
pd = rt.getPolicyDomain(configId);
System.out.println("Retrieved Policy Domain");
} catch (ParameterException pExc) {
// We could not get the policy domain
System.out.println(pExc.getLocalizedMessage());
}

return pd;
}

protected static AuthenticationService tryGetAuthenticationService(PolicyDomain pd) {
AuthenticationService atnSvc = null;

try {
atnSvc = (AuthenticationService)pd.getService(ServiceType.AUTHENTICATION);
System.out.println("Retrieved Authentication Service");
} catch (ServiceNotAvailableException naExc) {
// We could not fetch the service
System.out.println(naExc.getLocalizedMessage());
}
return atnSvc;
}

protected static AuthorizationService tryGetAuthorizationService(PolicyDomain pd) {
AuthorizationService atzSvc = null;

try {
atzSvc = (AuthorizationService) pd.getService(ServiceType.AUTHORIZATION);
System.out.println("Retrieved Authorization Service");
} catch (ServiceNotAvailableException naExc) {
// We could not fetch the service
System.out.println(naExc.getLocalizedMessage());
}
return atzSvc;
}


So, the idea is that the SM is just a collection of services – authentication, authorization, roles, audit, credential mapping. These services are accessible from a named configuration called a PolicyDomain. You can see more details of the Java API from the product documentation.. What is interesting is that if you examined the JavaAPIExample from SSM_HOME/java-ssm/examples/JavaAPIExample/src/java\com\bea\security\examples\JavaAPIExample.java, you would see the exact same code. From an API perspective, the type of SM (embedded or centralized) or the protocol (SOAP or RMI) is completely encapsulated.

All of this “magic” is done via what is called the PDPProxy configuration. When an instance of the SM is created with the ConfigTool, a directory is created SSM_HOME/SSM_TYPE/instance/instance-name/config/pdpproxy. In this directory is all of the information (libraries and config), that a client needs to communicate with the SM. At runtime, the Java API looks for a system property -Dpdp.configuration.properties.location to point it to the correct config.

The specific libraries will vary depending on the SM type (axis SOAP library is used for Web Service SM). There is a common configuration file called PDPProxyConfiguration.properties.


# SSM configuration id
SSMConfigID=dt

# Transport indicates underlying transport
# to be used to communicate with the PDP - JAVA / WS / RMI
PDPTransport=WS

# Comma separated list of PDP host & port information.
# For example this could be end point URLs could be,
# http://localhost:9200, or https://localhost:9200
PDPAddress=http://oamwindows:8225

There is more in the file, but this gives the general idea. You can change the PDPTransport and in the case of web-service SM, you define the URL.

Details on the Web Service SM

The basic API pattern is to get a named PolicyDomain and then access the services as needed. The question is, how do you apply this pattern to WebServices? Instead of simply listing each SOAP endpoint in a WSDL, OES uses the concept of the ServiceRegistry. This is basically a service that a client can call to get the location of the other services. With that information in hand, access to the underlying services – authentication, authorization, etc is pretty straight forward. I’ve included the SOAP Request/Response for the ServiceRegistry which is located at http://WS SM URL/ServiceRegistry.

Service Registry Request

<?xml version=”1.0″ encoding=”UTF-8″?><soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”><soapenv:Body><locateService xmlns=”http://security.bea.com/ssmws/ssm-soap-types-1.0.xsd”><ServiceType>ALES_AUTHORIZATION</ServiceType><SsmId>dt</SsmId></locateService></soapenv:Body></soapenv:Envelope>

Service Registry Response

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
<soapenv:Body>
<locateServiceResponse xmlns=”http://security.bea.com/ssmws/ssm-soap-types-1.0.xsd”>
<locateServiceResponse>http://oamwindows:8225/Authorization</locateServiceResponse>
</locateServiceResponse>
</soapenv:Body>
</soapenv:Envelope>

Is this better that just exposing ?WSDL

Personally, I’m not a big fan of “discoverable” security services. For example, I don’t like the idea of adding XACML to WS-Policy and making it readily available. Interoperability of WS-Policy as people know from reading this blog is a sore topic for me. In general, I’m OK with a little security by obscurity in this case. Also, in the context of the overall strategy of OES to simplify access via a single Java API, I think this is a good idea, and is in fact easier then using your own tooling to write a SOAP client. And finally, since this pattern is not obvious, OES does certify and provide its own clients for common platforms like MSFT .net.


 

Reference: WSDL and Schema for Web Services SM

SSM-SOAPWS.wsdl

 

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

<wsdl:definitions

name=”SSM-SOAP-WebService”

targetNamespace=”http://security.bea.com/ssmws/ssm-ws-1.0.wsdl”

xmlns=”http://www.w3.org/2001/XMLSchema”

xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/”

xmlns:ssm=”http://security.bea.com/ssmws/ssm-soap-types-1.0.xsd”

xmlns:tns=”http://security.bea.com/ssmws/ssm-ws-1.0.wsdl”

xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”

xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines SOAP WebService public interface for SSM component.</wsdl:documentation>

<!– WSDL Types Section –>

<wsdl:types>

<xsd:import namespace=”http://security.bea.com/ssmws/ssm-soap-types-1.0.xsd” schemaLocation=”ssm-soap-types.xsd”/>

</wsdl:types>

<!– WSDL Messages Section –>

<wsdl:message name=”serviceFault”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Reports a generic server-side error.</wsdl:documentation>

<wsdl:part element=”ssm:serviceFailure” name=”fault”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Generic error information</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”authenticationFault”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Reports an authentication error.</wsdl:documentation>

<wsdl:part element=”ssm:authenticationFailure” name=”fault”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Authentication error information.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”authorizationFault”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Reports an authorization error.</wsdl:documentation>

<wsdl:part element=”ssm:authorizationFailure” name=”fault”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Authorization error information.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”credentialMappingFault”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Reports a credential mapping error.</wsdl:documentation>

<wsdl:part element=”ssm:credentialMappingFailure” name=”fault”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Credential mapping error information.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”roleMappingFault”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Reports a role mapping error.</wsdl:documentation>

<wsdl:part element=”ssm:roleMappingFailure” name=”fault”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Role mapping error information.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”auditingFault”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Reports an auduting error.</wsdl:documentation>

<wsdl:part element=”ssm:auditingFailure” name=”fault”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Auditing error information.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”registryFault”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Reports a registry error.</wsdl:documentation>

<wsdl:part element=”ssm:registryFailure” name=”fault”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Registry error information.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”authenticateRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to authenticate a user. Accepts any credential type supported by the authentication provider or a response to an earlier authentication challenge, and, optionally, the type of requested identity assertion that represents the identity and application context of the authenticated user.</wsdl:documentation>

<wsdl:part element=”ssm:authenticate” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for authenticate operation</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”authenticateResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response from user’s authentication. Returns either the requested identity assertion token, an authentication challenge, or additional context requests, if a challenge is required by the specific authentication provider or the authentication protocol.</wsdl:documentation>

<wsdl:part element=”ssm:authenticateResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Identifies authentication response</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”assertIdentityRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to assert user’s identity. Accepts any supported identity assertion type or a response to an earlier authentication challenge, and, optionally, the type of requested identity assertion that represents the identity and application context of the authenticated user.</wsdl:documentation>

<wsdl:part element=”ssm:assertIdentity” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for assertIdentity operation</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”assertIdentityResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response from user’s authentication. Returns either the requested identity assertion token, an authentication challenge, or additional context requests, if required by the specific authentication provider or the authentication protocol.</wsdl:documentation>

<wsdl:part element=”ssm:assertIdentityResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Identifies authentication response</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”getServiceTypeRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to get service type. Takes an empty request.</wsdl:documentation>

<wsdl:part element=”ssm:getServiceType” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for getServiceType operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”getServiceTypeResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response containing service’s type. Returns a structure that contains the service. The Web Services SSM supports five security service types: authentication, auditing, authorization, credential mapping, and role mapping.</wsdl:documentation>

<wsdl:part element=”ssm:getServiceTypeResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Contains the service type.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”getVersionRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to get service version. Takes an empty request.</wsdl:documentation>

<wsdl:part element=”ssm:getVersion” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for the getVersion operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”getVersionResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response containing service version. Returns a structure that contains the version of the service.</wsdl:documentation>

<wsdl:part element=”ssm:getVersionResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Contains the service version.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”isAssertionTokenSupportedRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to check for of the assertion token type. Accepts the token type of the identity assertion token that represents the identity of the authenticated user.</wsdl:documentation>

<wsdl:part element=”ssm:isAssertionTokenSupported” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for the isAssertionTokenSupported operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”isAssertionTokenSupportedResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response about assertion token support. Returns a Boolean value (true or false) to indicate whether this token is supported by this instance of the Security Service Module.</wsdl:documentation>

<wsdl:part element=”ssm:isAssertionTokenSupportedResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Indicates whether an token type is supported.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”isCompatibleRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to check service compatibility. Accepts service version information. You use this method to determine whether the version of the service interface specified in the web services client is compatible with the current version of the service interface in the instance of the Security Service Module.</wsdl:documentation>

<wsdl:part element=”ssm:isCompatible” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for the isCompatible operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”isCompatibleResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response about service compatibility. Returns compatibility information.</wsdl:documentation>

<wsdl:part element=”ssm:isCompatibleResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Specifies service’s compatibility.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”validateIdentityRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to verify assertion token. Accepts any supported identity assertion type that represents the identity of the authenticated user.</wsdl:documentation>

<wsdl:part element=”ssm:validateIdentity” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for validateIdentity operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”validateIdentityResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response about assertion token validity. Returns a structure with a Boolean value (true or false) that indicates the authenticity of the token.</wsdl:documentation>

<wsdl:part element=”ssm:validateIdentityResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Specifies assertion token’s validity.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”isAccessAllowedRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to authorize user access. Accepts a supported type of an identity assertion token, and a runtime resource and action structures. Optionally, it can accept type of the requested identity assertion token, (representing the authenticated user’s identity), application context, and authorization direction parameters.</wsdl:documentation>

<wsdl:part element=”ssm:isAccessAllowed” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for the isAccessAllowed operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”isAccessAllowedResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response from user authorization. Returns the authorization decision (optionally accompanied by the time-to-live (TTL) value), an identity Assertion token, and a list of user roles, or, if required by the authorization provider, additional context requests.</wsdl:documentation>

<wsdl:part element=”ssm:isAccessAllowedResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Identifies authorization response.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”isAccessAllowedDebugRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Debug request to authorize user access. Accepts a supported type of an identity assertion token, and a runtime resource and action structures. Optionally, it can accept type of the requested identity assertion token, (representing the authenticated user’s identity), application context.</wsdl:documentation>

<wsdl:part element=”ssm:isAccessAllowedDebug” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for the isAccessAllowed_Debug operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”isAccessAllowedDebugResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Debug response from user authorization. Returns the authorization decision, evaluation debug information, (optionally accompanied by the time-to-live (TTL) value), an identity Assertion token, and a list of user roles, or, if required by the authorization provider, additional context requests.</wsdl:documentation>

<wsdl:part element=”ssm:isAccessAllowedDebugResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Identifies debug authorization response.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”getRolesDebugRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Debug request for user roles. Accepts a supported type of an identity token, and, optionally, runtime resource and action structures and an application context.</wsdl:documentation>

<wsdl:part element=”ssm:getRolesDebug” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for getRoles operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”getRolesDebugResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Debug response with user roles. Returns either a list of user roles associated for the identity or, if such is required by the Role Mapping provider, additional context requests and evaluation debug information. If the identity provided is invalid or not properly authenticated, this method returns a SOAP fault.</wsdl:documentation>

<wsdl:part element=”ssm:getRolesDebugResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Contains the requested user roles.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”isBulkAccessAllowedRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to bulk authorize user access. Accepts a supported type of an identity assertion token, and a list of runtime resource and action structures. Optionally, it can accept type of the requested identity assertion token, (representing the authenticated user’s identity), application context, and authorization direction parameters.</wsdl:documentation>

<wsdl:part element=”ssm:isBulkAccessAllowed” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for the isBulkAccessAllowed operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”isBulkAccessAllowedResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response from user authorization. Returns a list of the following information, the authorization decision (optionally accompanied by the time-to-live (TTL) value), an identity Assertion token, and a list of user roles, or, if required by the authorization provider, additional context requests.</wsdl:documentation>

<wsdl:part element=”ssm:isBulkAccessAllowedResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Identifies bulk authorization response.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”isChildResourceAccessAllowedRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to bulk authorize (child resources) user access. Accepts a supported type of an identity assertion token, and a runtime resource and action structures. Optionally, it can accept type of the requested identity assertion token, (representing the authenticated user’s identity), application context, and authorization direction parameters.</wsdl:documentation>

<wsdl:part element=”ssm:isChildResourceAccessAllowed” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for the isChildResourceAccessAllowed operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”isChildResourceAccessAllowedResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response from user authorization. Returns a list of the following information, authorization decision (optionally accompanied by the time-to-live (TTL) value), an identity Assertion token, and a list of user roles, or, if required by the authorization provider, additional context requests.</wsdl:documentation>

<wsdl:part element=”ssm:isChildResourceAccessAllowedResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Identifies bulk authorization (child resources) response.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”queryActionsOnResourceRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to query actions on resource. Accepts a supported type of an identity assertion token, and a runtime resource. Optionally, it can accept requested actions, application context parameters.</wsdl:documentation>

<wsdl:part element=”ssm:queryActionsOnResource” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for the queryActionsOnResource operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”queryActionsOnResourceResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response from user authorization. Returns the allowed and denied actions</wsdl:documentation>

<wsdl:part element=”ssm:queryActionsOnResourceResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Identifies query actions on resource response.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”queryActionsOnChildResourceRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to query actions on resource clipping node and all child resource nodes. Accepts a supported type of an identity assertion token, and a runtime resource clipping node. Optionally, it can accept requested actions, application context parameters.</wsdl:documentation>

<wsdl:part element=”ssm:queryActionsOnChildResource” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for the queryActionsOnChildResource operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”queryActionsOnChildResourceResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response from user authorization. Returns the allowed and denied actions for the resource and the children of that resource</wsdl:documentation>

<wsdl:part element=”ssm:queryActionsOnChildResourceResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Identifies response for query actions on resource clipping node and all child resource nodes.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”isAuthenticationRequiredRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to check whether a resource is protected. Accepts a runtime resource and a runtime action.</wsdl:documentation>

<wsdl:part element=”ssm:isAuthenticationRequired” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for isAuthenticationRequired operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”isAuthenticationRequiredResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response whether authentication is required. Returns a Boolean value (true or false) that indicates whether authentication is require to access this resource. The web services client uses this method to test whether privileges are required to access a particular resource.</wsdl:documentation>

<wsdl:part element=”ssm:isAuthenticationRequiredResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Identifies authentication requirements for a resource.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”getCredentialsRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for credentials mapping. Accepts a supported type of an identity assertion token and a list of requested credential types. Optionally, this method can accept an identity assertion token that represents the identity of a different user and a runtime resource structure, which includes the requested resource and action and the application context.</wsdl:documentation>

<wsdl:part element=”ssm:getCredentials” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for the getCredentials operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”getCredentialsResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response with requested credentials. Returns either a list of requested user credentials, identity assertion tokens, or, if required by the ALES Credential Mapping provider, context requests.</wsdl:documentation>

<wsdl:part element=”ssm:getCredentialsResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Contains the requested user credentials.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”getRolesRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for user roles. Accepts a supported type of an identity token, and, optionally, runtime resource and action structures and an application context.</wsdl:documentation>

<wsdl:part element=”ssm:getRoles” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for getRoles operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”getRolesResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response with user roles. Returns either a list of user roles associated for the identity or, if such is required by the Role Mapping provider, additional context requests. If the identity provided is invalid or not properly authenticated, this method returns a SOAP fault.</wsdl:documentation>

<wsdl:part element=”ssm:getRolesResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Contains the requested user roles.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”recordEventRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to record auditing message. Accepts an audit record, and, optionally, an identity assertion token, representing the auditing user, and an application context. Returns either an empty response or, if required by the provider, additional context requests.</wsdl:documentation>

<wsdl:part element=”ssm:recordEvent” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for recordEvent operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”recordEventResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Returns a Boolean value (true or false) confirming recording an audit event.</wsdl:documentation>

<wsdl:part element=”ssm:recordEventResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Contains True or false.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”locateServiceRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for service URL. Accepts the requested service type and SSM Configuration ID of the Web Services SSM that provides the service.</wsdl:documentation>

<wsdl:part element=”ssm:locateService” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for locateService operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”locateServiceResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response with service’s URL. Returns the fully qualified URL for the endpoint of the requested service.</wsdl:documentation>

<wsdl:part element=”ssm:locateServiceResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Contains requested service’s URL.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”doesServiceExistRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to check the existence of the service. Accepts the requested service type and SSM Configuration ID of the Web Services Security Service Module that provides the service.</wsdl:documentation>

<wsdl:part element=”ssm:doesServiceExist” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Input parameters for doesServiceExist operation.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”doesServiceExistResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response inidicating whether the service exists. Returns a Boolean value (true or false) that indicates whether the service exists and can be requested.</wsdl:documentation>

<wsdl:part element=”ssm:doesServiceExistResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Contains True or false.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”getParameterValueRequest”>

<wsdl:part element=”ssm:getParameterValue” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Name of the requested parameter.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<wsdl:message name=”getParameterValueResponse”>

<wsdl:part element=”ssm:getParameterValueResponse” name=”parameters”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>The requested parameter value.</wsdl:documentation>

</wsdl:part>

</wsdl:message>

<!– WSDL Ports Section –>

<wsdl:portType name=”AuthenticationPort”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines authentication operations.</wsdl:documentation>

<wsdl:operation name=”authenticate”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines the authentication method.</wsdl:documentation>

<wsdl:input message=”tns:authenticateRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Authentication request input.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:authenticateResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Authentication response result.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

<wsdl:fault name=”authenticationFault” message=”tns:authenticationFault” />

</wsdl:operation>

<wsdl:operation name=”assertIdentity”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines the identity assertion method.</wsdl:documentation>

<wsdl:input message=”tns:assertIdentityRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Assertion request input.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:assertIdentityResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Assertion response result.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

<wsdl:fault name=”authenticationFault” message=”tns:authenticationFault” />

</wsdl:operation>

<wsdl:operation name=”isAssertionTokenSupported”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Checks whether an assertion token type is supported.</wsdl:documentation>

<wsdl:input message=”tns:isAssertionTokenSupportedRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for support check.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:isAssertionTokenSupportedResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response indicating token type support.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

<wsdl:fault name=”authenticationFault” message=”tns:authenticationFault” />

</wsdl:operation>

<wsdl:operation name=”validateIdentity”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Validates identity token.</wsdl:documentation>

<wsdl:input message=”tns:validateIdentityRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for validating identity token.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:validateIdentityResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response indicating token validity.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

</wsdl:operation>

<wsdl:operation name=”getServiceType”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Obtains the service type.</wsdl:documentation>

<wsdl:input message=”tns:getServiceTypeRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for service type.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:getServiceTypeResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response with service type.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

</wsdl:operation>

<wsdl:operation name=”getVersion”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Obtains the service version.</wsdl:documentation>

<wsdl:input message=”tns:getVersionRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for service version.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:getVersionResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response with service version.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

</wsdl:operation>

<wsdl:operation name=”isCompatible”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Checks whether the service version is compatible.</wsdl:documentation>

<wsdl:input message=”tns:isCompatibleRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for compatibility check.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:isCompatibleResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response indicating compatibility.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

</wsdl:operation>

</wsdl:portType>

<wsdl:portType name=”AuthorizationPort”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines authorization operations.</wsdl:documentation>

<wsdl:operation name=”isAccessAllowed”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines the access control method.</wsdl:documentation>

<wsdl:input message=”tns:isAccessAllowedRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Authorization request input.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:isAccessAllowedResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Authorization response result.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

<wsdl:fault name=”authorizationFault” message=”tns:authorizationFault” />

</wsdl:operation>

<wsdl:operation name=”isAccessAllowed_Debug”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines the debug access control method.</wsdl:documentation>

<wsdl:input message=”tns:isAccessAllowedDebugRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Debug Authorization request input.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:isAccessAllowedDebugResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Debug Authorization response result.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

<wsdl:fault name=”authorizationFault” message=”tns:authorizationFault” />

</wsdl:operation>

<wsdl:operation name=”isBulkAccessAllowed”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines the access control method.</wsdl:documentation>

<wsdl:input message=”tns:isBulkAccessAllowedRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Authorization request input.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:isBulkAccessAllowedResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Authorization response result.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

<wsdl:fault name=”authorizationFault” message=”tns:authorizationFault” />

</wsdl:operation>

<wsdl:operation name=”isChildResourceAccessAllowed”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines the access control method.</wsdl:documentation>

<wsdl:input message=”tns:isChildResourceAccessAllowedRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Authorization request input.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:isChildResourceAccessAllowedResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Authorization response result.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

<wsdl:fault name=”authorizationFault” message=”tns:authorizationFault” />

</wsdl:operation>

<wsdl:operation name=”isAuthenticationRequired”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Checks whether authentication is required on a resource.</wsdl:documentation>

<wsdl:input message=”tns:isAuthenticationRequiredRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request to check resource protection.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:isAuthenticationRequiredResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response indicating whether a resource is protected.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

<wsdl:fault name=”authorizationFault” message=”tns:authorizationFault” />

</wsdl:operation>

<wsdl:operation name=”getServiceType”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Obtains the service type.</wsdl:documentation>

<wsdl:input message=”tns:getServiceTypeRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for service type.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:getServiceTypeResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response with service type.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

</wsdl:operation>

<wsdl:operation name=”getVersion”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Obtains the service version.</wsdl:documentation>

<wsdl:input message=”tns:getVersionRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for service version.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:getVersionResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response with service version.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

</wsdl:operation>

<wsdl:operation name=”isCompatible”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Checks whether the service version is compatible.</wsdl:documentation>

<wsdl:input message=”tns:isCompatibleRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for compatibility check.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:isCompatibleResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response indicating compatibility.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

</wsdl:operation>

<wsdl:operation name=”queryActionsOnResource”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines the query actions on resource method.</wsdl:documentation>

<wsdl:input message=”tns:queryActionsOnResourceRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Query actions on resource request input.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:queryActionsOnResourceResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Query actions on resource response result.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

<wsdl:fault name=”authorizationFault” message=”tns:authorizationFault” />

</wsdl:operation>

<wsdl:operation name=”queryActionsOnChildResource”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines the query actions on child resource method.</wsdl:documentation>

<wsdl:input message=”tns:queryActionsOnChildResourceRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Query actions on child resource request input.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:queryActionsOnChildResourceResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Query actions on child resource response result.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

<wsdl:fault name=”authorizationFault” message=”tns:authorizationFault” />

</wsdl:operation>

</wsdl:portType>

<wsdl:portType name=”CredentialMappingPort”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines credential mapping operations.</wsdl:documentation>

<wsdl:operation name=”getCredentials”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines the method for mapping credentials.</wsdl:documentation>

<wsdl:input message=”tns:getCredentialsRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for credentials maping.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:getCredentialsResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Credential mapping results.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

<wsdl:fault name=”credentialMappingFault” message=”tns:credentialMappingFault” />

</wsdl:operation>

<wsdl:operation name=”getServiceType”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Obtains the service type.</wsdl:documentation>

<wsdl:input message=”tns:getServiceTypeRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for service type.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:getServiceTypeResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response with service type.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

</wsdl:operation>

<wsdl:operation name=”getVersion”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Obtains the service version.</wsdl:documentation>

<wsdl:input message=”tns:getVersionRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for the service version.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:getVersionResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response with the service version.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

</wsdl:operation>

<wsdl:operation name=”isCompatible”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Checks whether the service version is compatible.</wsdl:documentation>

<wsdl:input message=”tns:isCompatibleRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for compatibility check.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:isCompatibleResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Response indicating compatibility.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

</wsdl:operation>

</wsdl:portType>

<wsdl:portType name=”RoleMappingPort”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines the role mapping operations.</wsdl:documentation>

<wsdl:operation name=”getRoles”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines the method for mapping roles.</wsdl:documentation>

<wsdl:input message=”tns:getRolesRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for roles maping.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:getRolesResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Role mapping results.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

<wsdl:fault name=”roleMappingFault” message=”tns:roleMappingFault” />

</wsdl:operation>

<wsdl:operation name=”getRoles_Debug”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Defines the debug method for mapping roles.</wsdl:documentation>

<wsdl:input message=”tns:getRolesDebugRequest”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Request for debug roles maping.</wsdl:documentation>

</wsdl:input>

<wsdl:output message=”tns:getRolesDebugResponse”>

<wsdl:documentation xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>Debug role mapping results.</wsdl:documentation>

</wsdl:output>

<wsdl:fault name=”serviceFault” message=”tns:serviceFault” />

<wsdl:fault name=”roleMappingFault” message=”tns:roleMappingFault” />

</w

Problems with Unsigned WS-Security Timestamps in the Response

I’ve had a few customers recently that have struggled with this scenario – a web-service consumer receives a response message that it cannot validate. We spend some much time focusing on the request, but often don’t think about the response. The messages in question look something like this:


<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" S:mustUnderstand="1">
<wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsu:Created>2009-11-03T10:12:44Z</wsu:Created><wsu:Expires>2009-11-03T10:13:44Z</wsu:Expires></wsu:Timestamp>
</wsse:Security>
</S:Header>
<S:Body>
<ns2:sayHelloResponse xmlns:ns2="http://ws.my/">
<return>
Hello,Josh!
</return>
</ns2:sayHelloResponse>
</S:Body>
</S:Envelope>

The issue is that the message includes a timestamp, but its not signed. I’ve seen this issue with both WCF clients as well as Oracle Web Services Manager (OWSM).

Depending on the client stack, there are two ways to fix this issue. The first is to simply sign the response. This is really the best practice, especially for a message that the sender took the time and effort to add WS-Security to in the first place. The second approach, is to simply remove the message security (i.e. WS-Security header and timestamp). For example, below is a modified Wssp1. 2-2007-Https.xml that still ensures that the request is over SSL, but removes the “offending” timestamp.

Wssp1. 2-2007-Https-no-timestamp.xml


<?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:TransportBinding>
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken />
</wsp:Policy>
</sp:TransportToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
</wsp:Policy>
</sp:TransportBinding>
</wsp:Policy>