Security and the WebSphere Commerce Web service framework

Security and the WebSphere Commerce Web service framework

The WS-Security specification (http://www.oasis-open.org/committees/wss/) defines several techniques for implementing Web service security.
By default, all Web service requests are given the authentication of the generic user. However, since much of the WebSphere Commerce business logic that will be exposed through Web services cannot be executed by the generic user, WS-Security can be leveraged to allow different credentials to be used.
The following sections cover the security considerations involved when enabling WebSphere Commerce Web services.

Basic authentication

One approach to Web service security is basic authentication. Under this approach, the user's credentials are attached to the header of the SOAP envelope. The chief shortcoming of basic authentication is that the authentication information is found in plain text within the SOAP message and, if the underlying transport protocol is not secure, is accessible by an attacker with appropriate network monitoring tools. As a consequence, basic authentication should always be used in conjunction with a secure underlying transport protocol, such as HTTPS.
The following is an example of a SOAP request that uses basic authentication:
<soapenv:Envelope
      xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
      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:Header>
            
<wsse:Security soapenv:mustUnderstand="1"
                 
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-secext-1.0.xsd">
                  <wsse:UsernameToken>
                       
<wsse:Username>David</wsse:Username>
                        <wsse:Password
                             
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wssusername-token-profile-1.0#PasswordText">
                              divaD
                        </wsse:Password>
                  </wsse:UsernameToken>
            </wsse:Security>
      </soapenv:Header>
      <soapenv:Body>
            
      </soapenv:Body>
</soapenv:Envelope>
Note that , in compliance with the latest WS-Security specification, the user credentials are found within the security node of the SOAP header. This node is the placeholder for the security information that should be associated with the Web service request.
When basic authentication is used to authenticate a user, the WebSphere Commerce Web service controller will extract the credential information from the SOAP header and call the business context service to begin a new session based on the credentials found. This will establish an activity associated with the specified user, but the activity will only exist for the lifetime of request processing. It will be assumed that the activity is not needed to process subsequent requests, and the activity token will not be returned to the calling client. After the request has been serviced, the activity will be completed and can no longer be used for other requests.

WebSphere security

When WebSphere global security is enabled, the WAS Web service engine will authenticate the user and place their credentials on the thread. The Web service controller will, in turn, create a temporary activity with the user ID obtained from the thread authentication context.
This approach leverages the WebSphere security and Web service engine to authenticate the user and requires no additional implementation besides that for reading the credentials from the thread.

Protocol authentication

Requiring security to be enabled on the application server might result in a performance penalty. However, since certificate is a transport protocol concept, if there were a way to allow the transport to provide this validation without enabling WebSphere global security, the certificate approach could still be used without impacting performance.
One solution is to have a generic flag such that if the credentials are not found on the Web service requests and this flag is set, instead of executing the request with the authority of a generic user, the default messaging user will be used. This generic flag, named secureTransportProtocol, will be found in the Messaging section of the WebSphere Commerce configuration file. When its value is set to true, the Web service framework will assume the protocol has been configured to provide validation of the request credentials and the user ID for the activity will be that of the default messaging user. In the sample configuration snippet below, this means that any request with no credentials will be executed under the authority of wcsadmin.
<Messaging
      EcInboundMessageDtdFiles="NCCommon.mod, NCCustomer_10.mod"
      EcInboundMessageDtdPath="messaging"
      EcMimePropFile="lang_mime.data"
      EcSystemTemplateFile="sys_template.xml"
      EcTemplatePath="messaging"
      EcUserTemplateFile="user_template.xml" 
      
XMLWebControllerUserId="wcsadmin"
      secureTransportProtocol="true" />
The secureTransportProtocol flag cannot be set with the Configuration Manager. You must edit the WebSphere Commerce configuration file directly.

Using this technique implies that all the necessary security precautions are in place at the transport layer to ensure secure transmission of messages and request validation. If the transport is not secure and the secureTransportProtocol flag is set to true , every unauthenticated request will be executed with the default messaging user's authority. This could be a security exposure.

Activity token

The activity token is a way to establish a session for a normally session-less protocol.
WebSphere Commerce Web service framework leverages the custom token pluggable architecture provided by WAS Web service engine to place the activity token into the SOAP header of the request. The only difference between this form of authentication and those discussed previously is that the activity will not be completed after the request is serviced. The activity will be kept alive to be used for subsequent requests.
The following is an example of a SOAP request that uses an activity token:
<soapenv:Envelope
      xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
      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:Header>
            <wsse:Security soapenv:mustUnderstand="1"
                 
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-secext-1.0.xsd">
                  
<wc:ActivityToken>
                       
<wc:ActivtyGUI>10001</wc:ActivtyGUI>
                       
<wc:Signature>sg399bs99gesgs</wc:Signature>
                  </wc:ActivityToken>
            </wsse:Security>
      </soapenv:Header>
      <soapenv:Body>
            
      </soapenv:Body>
</soapenv:Envelope>
Related concepts

WebSphere Commerce Web services with JSP pages
WebSphere Commerce security model
Business context service
Related tasks

Enabling WebSphere Commerce as a service provider
Enabling WebSphere global security
Configure WebSphere Commerce Developer for Web service development
Related reference

Additional information about Web services