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 is 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 that are involved when you enable 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. If the underlying transport protocol is not secure, the information is easily accessible by an attacker with appropriate network monitoring tools. As a consequence, basic authentication should always be used 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-wss-wssecurity-secext-1.0.xsd">
      <wsse:UsernameToken>
        <wsse:Username>myUserName</wsse:Username>
        <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
          myPassword
        </wsse:Password>
      </wsse:UsernameToken>
    </wsse:Security>
  </soapenv:Header>
  <soapenv:Body>
    
  </soapenv:Body>
</soapenv:Envelope>
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 extracts the credential information from the SOAP header. The controller calls the business context service to begin a new session that is based on the credentials found. This session establishes an activity associated with the specified user, but the activity exists for only the lifetime of request processing. It is assumed that the activity is not needed to process subsequent requests, and that the activity token is returned to the calling client. After the request is serviced, the activity will be completed and can no longer be used for other requests.

WebSphere security

When WebSphere global security is enabled, the WebSphere Application Server web service engine authenticates the user and places 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 uses the WebSphere security and web service engine to authenticate the user and requires no additional implementation for reading the credentials from the thread.

Protocol authentication

Note: The protocol authentication method is applicable only if one of the following classes are used:

com.ibm.commerce.webservices.OpenWebServiceComponentImpl
com.ibm.commerce.webservices.engine.WebServiceEngineBean

Requiring security to be enabled on the application server might result in a performance penalty. Since certificate is a transport protocol concept, we can still use this certificate approach without impacting performance if you enable the transport to provide this validation without enabling WebSphere global security.
One solution is to use a generic flag, named secureTransportProtocol. When the credentials are not found on the web service requests and this flag is set, the default messaging user is used instead of the authority of a generic user to execute requests. This generic flag is found in the Messaging section of the WebSphere Commerce configuration file. When the value of the flag is set to true, the web service framework assumes that the protocol is configured to provide validation of the request credentials. The user ID for the activity is that of the default messaging user. In the sample configuration snippet below, any request with no credentials is 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" />
Note: The secureTransportProtocol flag cannot be set with the Configuration Manager. We must edit the WebSphere Commerce configuration file directly.
Important: 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 is executed with the default messaging user's authority. The use of this authority can 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 uses the custom token pluggable architecture that is provided by WebSphere Application Server web service engine to place the activity token into the SOAP header of the request. The only difference between this form of authentication and the other authentication methods is that the activity is not completed after the request is serviced. The activity is kept to be used for subsequent requests.
To retrieve the activity token information, we can call the MemberFacadeClient.authenticatePassword or authenticateLTPA methods to authenticate the user and retrieve the tokens. For more information about the authentication methods, see client. For more information about the authenticate password message, see Person noun
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 xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsswssecurity-secext-1.0.xsd"> 
      <wc:IdentityToken xmlns:wc="http://www.ibm.com/xmlns/prod/WebSphereCommerce"> 
        <wc:IdentityIdentifier>10001</wc:IdentityIdentifier>
        <wc:Signature>poifhhOgAs+eRlajfn7mzt+m3Dqbw=</wc:Signature>
      </wc:IdentityToken>
    </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
Enable WebSphere Commerce as a service provider
Configure WebSphere Commerce Developer for Web service development
Modifying an inbound Web service

Related reference
Additional information about Web services
Inventory update