To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
The exact process by which the application server processes the SOAP request is dependent on the server in question. I don't know of any SOAP servers, though, that use WSDL at runtime to process requests. WSDL doesn't provide the information that a server needs to know to process requests. WSDL is used on the client side, as described below.
Typically, when you deploy the service you supply a configuration file that tells the server how to process requests sent to the service. The configuration file indicates information such as:
- which methods should be invoked in what sequence to process SOAP header entries and to perform other system-level functions, such as authentication, authorization, auditing, logging, decryption, decompression, etc.
- a WSDL operation name maps to an object method name
- an XML type maps to a class using a particular set of serializers and deserializers
None of this configuration information is dynamic in nature.
Rogue schemas could pose a more serious threat than rogue WSDLs. If you indicate that you want to validate an incoming request, then the server loads the schema at runtime and uses it for validation. The validation process is often not under the direct control of the SOAP server; it's typically performed by a "handler" -- often written by a developer. You should establish policies within your organization to prevent use of "wild" schemas for validation.
Many client-side SOAP toolkits use WSDL at runtime to support dynamic binding and dynamic invocation. If you view this practice as too strong a security threat, then you should be able to disable dynamic processing and force clients to use only precompiled stubs.
|
