REST authentication and access control

Depending on the REST services, they might require authentication or access control.

Authentication

Some REST services require authentication. To use these REST services, you must first get authentication data by using one of the three identity services:
loginidentity
Uses a user name and password to authenticate a registered user.
guestidentity
Creates an identity for a guest user.
ltpaidentity
Uses an LTPA token to authenticate a user.
You must send a POST request to one of the REST resources, where the response contains the following data:

{
  "WCToken": "xxxxxxxxxxxxxxxxxxx",
  "WCTrustedToken": "xxxxxxxxxxxxx",
  "personalizationID": "1321550980363-1",
  "userId": "2"
}

After successfully obtaining the authentication data, you must pass the WCToken and WCTustedToken in the HTTP header for every request that requires authentication. If a request is sent over HTTP, pass the WCToken in the HTTP header. That is, do not pass the WCTrustedToken in HTTP requests, as it might be shown. However, both WCToken and WCTrustedToken must be sent if a request is sent over HTTPS.

The following snippet is an example for setting the WCToken and WCTrustedToken in the HTTP header:

HttpPost request = new HttpPost(secureUrl);

request.addHeader("Content-Type", "application/json");
request.addHeader("WCToken", wcToken);
request.addHeader("WCTrustedToken", wcTrustedToken);

HTTP Basic Authentication

Using the HTTP basic authentication standard avoids maintaining a session. Instead, the REST API on the WebSphere Commerce server can be called, specifying the user name and password on every request. WebSphere Commerce validates the user credentials automatically, and an error is thrown if the credentials are not valid.

This is done by using the Authorization header in the following way:
  1. The user name and password are combined into a string called username:password. User names and passwords that contain a colon character (:) are not supported.
  2. The resulting string literal is then encoded using the RFC2045-MIME variant of Base64, except it is not limited to 76 characters per line.
  3. The authorization method and a space is then put before the encoded string. For example, Basic .
For example, if the user agent uses Aladdin as the user name and open sesame as the password, the header is formed in the following way:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Access control

The following access control behavior exists for REST services:

For Create, Update, and Delete operations:
  • REST services must wrap BOD commands or controller commands to have access control enforced. This is the only supported and secure option.
For Get operations:
  • REST services must wrap BOD commands or data beans to have access control enforced.
  • REST over data beans: Access control is enforced if the underlying data bean implements the Delegator interface. If the data bean does not implement the Delegator interface, it can be called using local binding through JSP files, assuming the data bean does not expose sensitive data to the end user. If you are using remote binding through REST service calls, and the data bean does not implement the Delegator interface, only a Site Administrator can run the service call by default. This can be customized by overriding the isSiteResource(DataBean) method of the REST Resource Handler class.