Resource protection in WAS

The following WebSphere Commerce resources are protected under access control by WAS:

Entity beans

These beans model objects in an e-commerce application. They are distributed objects that can be accessed by remote clients.

JSP templates

WebSphere Commerce uses JSP templates for display pages. Each JSP template can contain one or more data beans that retrieve data from entity beans. Clients can request JSP pages by composing a URL request.

Controller and view commands

Clients can request controller and view commands by composing URL requests. In addition, one display page may contain a link to another by using the JSP file name or the view name, as registered in the Configure a Web application.

The WebSphere Commerce Server is typically configured to use the following Web paths:

/webapp/wcs/stores/servlet/*

This is used for requests to the request servlet.

/webapp/wcs/stores/*.jsp

This is used for requests to the JSP servlet.

The following diagram shows the route that requests could potentially follow to access WebSphere Commerce resources, for the preceding Web path configuration.

All the legitimate requests should be directed to the request servlet, which then directs them to the Web controller. The Web controller implements access control for controller commands and views. The Web paths shown above do, however, make it possible for malicious users to directly access JSP templates (path 1) and entity beans (path 2). In order to prevent these malicious attacks from being successful, they must be rejected at run time.

Direct access to the JSP templates and entity beans can be prevented by using one of the following approaches:

WAS security

WAS provides a number of security features. WebSphere Commerce uses one of these features to ensure that all enterprise bean methods and JSP templates are configured to be invoked only by a chosen identity. To access these WebSphere Commerce resources, a URL request must be routed to the request servlet. The request servlet sets the chosen identity on the current thread before passing it to the Web controller. The Web controller then ensures that the caller has the required authorization before passing the request to the corresponding controller command or view. Any attempts to directly access JSP templates and entity beans (that is, without using the Web controller) are rejected by the WAS security component.

For information about security within WebSphere Application Server, refer to the System Administration topic in the WebSphere Application Server documentation.

Firewall protection

IBM recommends to run WebSphere Commerce Server behind a firewall. When a WebSphere Commerce Server runs behind the firewall, Internet clients are not able to directly access the entity beans. Using this approach, protection for JSP templates is provided by the data bean that is included in the page. The data bean is activated by the data bean manager. The data bean manager detects if the JSP template was forwarded by a view command. If it was not forwarded by a view command an exception is thrown and the request for the JSP template is rejected.

If you put a firewall between your WebSphere Commerce application server and your Web server, your Web server plug-in may not recognize when application server is down, preventing correct fail-over behavior. In this case IBM recommends that you enable the ExtendedHandshake attribute in your Web server plug-in configuration file, plugin-cfg.xml. For example

<Server CloneID="1234abcd" ConnectTimeout="0" ExtendedHandshake="true" LoadBalanceWeight="2" MaxConnections="-1" 
Name="WC_demo" ServerIOTimeout="0" WaitForContinue="false"> 

Related concepts

Understanding access control
Protectable interface
WebSphere Commerce access control policies
Access control interactions
Groupable interface

Related tasks

Enabling WAS security
Configure a Web application