WCSADMIN.COM

Authenticating a Web Service

Commerce provides built in web services for updating commerce data by the third party tools using messages sent over a transport protocol. These are typically used for updating product inventory levels, product pricing, order status and certain customer updates. In prior versions of Commerce this was predominantly handled by “Legacy” messaging system wherein the message, typically, comes over an MQ Queue. In all the cases, whether web services or legacy way, the incoming message triggers a command on the commerce server. Calling internal commerce command requires the caller to provide its identity before the command can be executed. Without a valid identification, commerce simply returns a message indicating the user does not have authority to execute the command.

 In the case of web services, there are four different ways of doing this. I have used two of them. This note discusses the two methods. The four methods are discussed briefly in an infocenter articles found here.

Basic Authentication

This is the default method. If you do not do anything at all, commerce expects to see userId/password in the SOAP header of the incoming message. An example for this is shown in the infocenter link provided above. The problem with this approach is that it is basic and it is not secure. You have to give out commerce userid/password to some third party and the message coming over a protocol, such as MQ or HTTP, can and will be intercepted to steal the userid and password.

Protocol Authentication

This approach assumes(and that is the catch!) that the request is always coming from a secure source and therefore no additional authentication will be necessary. Therefore the request xml need not have the user credentials embedded in the soap header as in basic authentication approach. Why would you use this approach? There are two reasons: One, the caller of the service may not have the capability of producing the wsse headers to specify userid/password in the soap header. I was told Informatica does not have this capability. Two, it is not desirable to use basic authentication as the userid/password information may not be secure over a transport protocol.

Using Protocol authentication requires a configuration change on the commerce server. To implement this configuration change, you have to manually update the commerce instance xml file. This change cannot be implemented using the config admin tool. This file is {WCS_HOME}/instances/{INST_NAME}\xml/{INST_NAME}/xml/{INST_NAME}.xml. You have to add secureTransportProtocol=”true” to “Messaging EcInboundMessageDtdFiles ” the section of the file. This change is not immediately reflected unless you add this change to wc-server.xml file as well. For further information please read my other post on “Implementing Config Changes in 6.0“

Please note that this is a critical change to the configuration file that has security implications. As noted above, any webservice request coming into the commerce is assumed to be coming from a safe source and hence will not be authenticated. It is assumed that the underlying protocol is going to handle authentication. To address this risk, it is a good idea to import a private client certificate on the system that is initiating the webservice call. The server certificate will ensure that the request is coming from a secure source by validating the client.