Develop > Persistence layer > Commerce Web services with JSP pages > Understand the Commerce Web service framework > Commerce as a service provider
Security and the Commerce Web service framework
Overview
The WS-Security specification 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 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.
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"> mypassword </wsse:Password> </wsse:UsernameToken> </wsse:Security> </soapenv:Header> <soapenv:Body> <!-- message pay load --> </soapenv:Body> </soapenv:Envelope>
User credentials are found within the security node of the SOAP header.
The Commerce Web service controller will...
- Extract the credential information from the SOAP header
- Call the business context service to begin a new session based on the credentials found
A temporary activity token is associated with the user ID obtained from the thread authentication context. 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.
Protocol authentication performance
Requiring security to be enabled on the application server might result in a performance penalty. This penalty can be avoided by allowing the transport protocol to provide validation without enabling global security. The certificate approach could still be used without impacting performance.
One way to accomplish this is to leverage the flag secureTransportProtocol. If set, and the credentials are not found, instead of executing the request as generic user, the default messaging user will be used.
The flag will be found in the Messaging section of the 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 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.
Commerce Web service framework leverages the custom token pluggable architecture 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 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> <!-- message pay load --> </soapenv:Body> </soapenv:Envelope>
Related concepts
Commerce Web services with JSP pages
Commerce security model
Business context service
Related tasks
Enable Commerce as a service provider
Configure Commerce Developer for Web service development
Modify an inbound Web service
Related reference
Additional information about Web services
Inventory update