Home
User Guide
The information contained in this section applies to WebSphere Commerce Version 8. The documentation also applies to all subsequent releases and modifications until otherwise indicated in a newer section.WebSphere Commerce is a single, unified e-commerce platform that offers the ability to do business directly with consumers (B2C), directly with businesses (B2B), and indirectly through channel partners (indirect business models). WebSphere Commerce is designed to be a customizable, scalable, and high availability solution that is built to leverage open standards. It provides easy-to-use tools for business users to centrally manage a cross-channel strategy. Business users can create and manage precision marketing campaigns, promotions, catalog, and merchandising across all sales channels.
Securing
These topics describe the security features of WebSphere Commerce and how to configure these features.
Authorization
WebSphere Commerce views access control or authorization as the process of verifying that users or applications have sufficient authority to access a resource. This section describes the details of several aspects of WebSphere Commerce access control.
Customizing default access control policies
The default access control policies that are provided by WebSphere Commerce address the basic requirements that organizations have for regulating the actions and information available to their users. Often, the default policies can be sufficient for your site's needs. At the same time, the default policies are highly customizable, so that you can tailor them to your own requirements.
Defining access control policy elements using XML
The Organization Administration Console allows you to make simple changes to access control policies and their parts. To make more sophisticated changes, you need to edit the XML files directly, and then load them into the database.
Protecting views
Any view that is called directly from an URL, or that is launched as a redirect from another command, needs a role-based access control policy in order to be displayed.

User Guide
The information contained in this section applies to WebSphere Commerce Version 8. The documentation also applies to all subsequent releases and modifications until otherwise indicated in a newer section.WebSphere Commerce is a single, unified e-commerce platform that offers the ability to do business directly with consumers (B2C), directly with businesses (B2B), and indirectly through channel partners (indirect business models). WebSphere Commerce is designed to be a customizable, scalable, and high availability solution that is built to leverage open standards. It provides easy-to-use tools for business users to centrally manage a cross-channel strategy. Business users can create and manage precision marketing campaigns, promotions, catalog, and merchandising across all sales channels.
- Planning
  Creating a custom implementation of a WebSphere Commerce store requires a significant amount of planning. From gathering client needs, to deploying the live solution, much work is needed to successfully deploy a custom client store. Use the resources in here to help you plan every phase of store creation.
- Installing
  Review the following sections for information about installing the WebSphere Commerce product, associated maintenance, and WebSphere Commerce enhancements.
- Migrating
  Before you migrate to WebSphere Commerce Version 8.0, review this information to help plan and execute your migration.
- Deploying
  The topics in this section describe how to publish stores to either a test or production environment, and how to deploy customized code.
- Operating
- Integrating
  Topics in the Integrating category highlight the tasks that are commonly performed for using WebSphere Commerce in combination with other products.
- Administering
- Tutorials
  WebSphere Commerce provides many tutorials to help you customize and understand your WebSphere Commerce instance and stores.
- Samples
- Developing
  The topics in the Developing section describe tasks performed by an application developer.
- Compliance
  The following section describes how you can leverage WebSphere Commerce features and functionality to help your site be compliant with different privacy and security standards.
- Securing
  These topics describe the security features of WebSphere Commerce and how to configure these features.
  - WebSphere Commerce security model
    Authentication is the process of verifying that users or applications are who they claim to be. In a WebSphere Commerce system, authentication is required for all users and applications that access the system, except for guest customers.
  - WebSphere Commerce authentication model
    The WebSphere Commerce authentication model is based on the following concepts: challenge mechanisms, authentication mechanisms and user registries.
  - Authorization
    WebSphere Commerce views access control or authorization as the process of verifying that users or applications have sufficient authority to access a resource. This section describes the details of several aspects of WebSphere Commerce access control.
    - Access control policy
      An access control policy authorizes a group of users to perform a set of actions on a set of resources within WebSphere Commerce. Unless authorized through one or more access control policies, users have no access to any functions of the system. To understand access control policies you need to understand four main concepts: users, actions, resources, and relationships. Users are the people who use the system. Resources are objects in the system that need to be protected. Actions are the activities that users can perform on the resources. Relationships are optional conditions that exist between users and resources.
    - Access control policy groups
      WebSphere Commerce supports various business models, and each business model has its own set of access control policies. In order to group the sets of policies within the models, policy groups were created. Policies are explicitly assigned to appropriate policy groups and then organizations can subscribe to one or more of these policy groups. For example, in the following diagram, Seller Organization subscribes to Seller Organization Policy Group, and Root Organization Policy Group.
    - Enforcing access control
      Policy Manager is the access control component that determines whether the current user is allowed to execute the specified action on the specified resource. Access control policies are specified in XML format. During instance creation, the default policies and policy groups are loaded into the appropriate database tables. When WebSphere Commerce Application Server is started up, the access control information is cached in memory so the Policy Manager can quickly check a user's authorization when called to do so. If access control information is changed in the database through the Administration Console, or by loading XML policy data, the access control cache needs to be updated. You can update the cache by updating the appropriate registry in the Administration Console. If policy data is changed, then update the Access Control Policies registry. If policy group data is changed, update the Access Control Policy Groups registry. Restarting WebSphere Commerce also updates the cache.
    - Evaluating access control policies
      This section can be used as a guide to evaluating access control policies. In this section, you are presented with a scenario and guided through an example of how to evaluate groupable standard and groupable template access control policies. Each section begins with a description of related policies, and scenarios using each policy.
    - Example: Examining an access control policy
      In this section, you look at one of the default policies in detail, using a series of different examples. The policy you will study is the following:
    - Default access control policies
      The default policies shipped with WebSphere Commerce are organized into the following categories:
    - Default access control policy groups
      The default access control policy groups that are shipped with WebSphere Commerce are the following:
    - Customizing default access control policies
      The default access control policies that are provided by WebSphere Commerce address the basic requirements that organizations have for regulating the actions and information available to their users. Often, the default policies can be sufficient for your site's needs. At the same time, the default policies are highly customizable, so that you can tailor them to your own requirements.
      - Relationships between role-based and resource-level policies
        This topic describes how policies are related to each other and why you need to understand their relationships before you can modify an existing policy, or create a new one. In many cases, you need to change several policies to properly implement a change.
      - Role-based and resource-level policies
        Role-based policies are also known as command-level policies because they authorize users with a particular role to execute a set of commands. Resource-level policies authorize a group of users to execute a set of commands on a particular set of resources. For instance, a role-based policy might authorize children to eat. While a resource-level policy might authorize children eat rice.
      - Defining access control policy elements using XML
        The Organization Administration Console allows you to make simple changes to access control policies and their parts. To make more sophisticated changes, you need to edit the XML files directly, and then load them into the database.
        Access control files
        The following table provides the names and descriptions of the default WebSphere Commerce access control files (XML and DTD files). WebSphere Commerce loads these default files when you create your instance.
        Protecting views
        Any view that is called directly from an URL, or that is launched as a redirect from another command, needs a role-based access control policy in order to be displayed.
        Adding a new view using existing policies
        To add a new view that is accessible by roles with existing role-based View policies, create an XML file.
        Adding a new view using a new policy
        To add a new view that is accessible by a new role that does not have an existing role-based policy, create an XML file.
        Protecting controller commands
        All controller commands require a role-based access control policy in order to be executed. A controller or task command also requires a resource-level policy if the command is doing resource-level checking.
        Protecting resources
        You can add resource-level access control to controller or task commands. Resource-level checking is done at WebSphere Commerce runtime, based on data returned by the getResources() method of a command. Resource-level checking can also be done during the performExcecute() portion of the command by making direct calls to the access control policy manager using the method void checkIsAllowed(Object resource, String action) throws ECException. This method will throw the ECApplicationException if the current user is not allowed to perform the specified action on the specified resource.
        Protecting data beans
        Data beans contain information about business objects and are used to display object information about a Web page. Dynamic Web pages are usually mapped to views within WebSphere Commerce, and these views are protected by role-based policies. It is sometimes necessary to further protect the content of the Web page by protecting its data beans, if they exist.
        Grouping resources by attributes
        You may find that a resource policy that is based on class names needs to be more fine-grained than the default policies provided with WebSphere Commerce. An implicit resource group definition will provide the flexibility to protect resources of a particular state. For example, if you want to create a policy in where all users can run the OrderRead command on orders that has status 'P' or 'E', then you will need to define a resource group as shown below.
        Defining relationships
        A relationship provides the ability to grant a user access to a resource that is based on the user's relationship with the resource. If a relationship is defined in the policy, for a user to have access to the resource, the user must also satisfy the relationship with the resource in addition to satisfying the User Group, Action Group and Resource Group definitions. For example, an administrator may want to define a policy that only allows the creator of an order to update it. This type of policy definition is done through relationships.
        Defining relationship groups
        If multiple relationships are required to grant a user access to certain resource, use the RelationGroup construct. However a relationship usually satisfies most of the requirement for this scenario. Relationship groups contain open conditions which are the conditions for belonging to the relationship group. If you need to define relationship groups, you must do so by defining the relationship group information in your XML file, or by modifying the defaultAccessControlPolicies.xml file.
        Defining access groups
        An access group is a required element in a policy definition. It defines which users are entitled to act upon which resources. There are many instances where it is necessary to define a new access group.
        Defining policies
        There are many instances where it is necessary to define a new access group.
      - Loading access control policy data
        If you make policy changes by working directly with the XML files, you must load the changed XML files back into the databases.
      - Extracting policy and access group definitions
        The extraction process reads the access control policy and access group information in the database and generates files that capture the information in XML format. The extraction utility uses an input filter XML file to specify which data to extract from the database. You can extract all access group and policy data, all access group data, or all access group and policy data that is owned by a particular organization.
      - Testing access control policy changes
        Each time you create or modify an access control policy, you must perform certain tests to verify that the policy is working correctly.
      - Examples: Customizing access control policies using the Organization Administration Console
        For all of these examples, it is assumed that a Site Administrator is modifying the policies for Root Organization. Once you step through some of the examples, you will be able to follow the same methodology to make changes not specifically covered here.
  - Security standards
    Some main security standards are: NIST SP 800-131A, FIPS 140-2 and PCI.
  - Security bulletins
    WebSphere Commerce releases security bulletins for APARs that address issues that are considered to be security vulnerabilities. These bulletins provide security risk assessment information to help you assess if a particular issue might impact your organization.
  - Security fixes
    The following WebSphere Commerce releases contain security fixes for defects that are considered to be security vulnerabilities. The following details provide security risk assessment information to help you assess if a particular issue might impact your organization.
  - Hardening site security checklist
    To harden the security of your WebSphere Commerce site, you can enable and configure various security features. In addition, site customizations must always be made to comply with best practices as outlined in this document.
  - Site security considerations
    To enhance the security of your WebSphere Commerce site, you can enable various features in Configuration Manager and the Administration Console.
  - Session management
    Browsers and e-commerce sites use HTTP to communicate. HTTP is a stateless protocol, which means that each command is run independently without any knowledge of the commands that came before it. Because it is a stateless protocol, sessions must be managed between the browser side and the server side.
  - Quick reference to user IDs, passwords, and Web addresses
    Administration in the WebSphere Commerce environment requires a variety of user IDs. These user IDs along with their requisite authorities are described in the following list. For the WebSphere Commerce user IDs, the default passwords are identified.
  - Enabling WebSphere Application Server security
    You can enable WebSphere Application Server security, which includes two orthogonal components: WebSphere global security and Java 2 security.
- Performance
- Troubleshooting

Protecting views

Any view that is called directly from an URL, or that is launched as a redirect from another command, needs a role-based access control policy in order to be displayed.

About this task

The following example displays a role-based policy for views:


<Policy Name="ProductManagersExecuteProductManagersViews"
        OwnerID="RootOrganization"
        UserGroup="ProductMangers"
        ActionGroupName="ProductMangersViews"
        ResourceGroupName="ViewCommandResourceGroup"
        PolicyType="groupableStandard">
</Policy>

The ResourceGroup name, ViewCommandResourceGroup, indicates that this is a role-based policy for views. The policy states that users in the ProductManagers user group, can display the views in the ProductMangersViews action group. Similarly, for most roles, there is a corresponding action group which groups the views that the role can access, such as Seller role -> Sellers access group -> SellersViews action group.

The following is an example of the ProductMangersViews action group:


<ActionGroup Name="ProductManagersViews"
OwnerID="RootOrganization">
        <ActionGroupAction Name="ProductImageView"/>
        <ActionGroupAction Name="ProductManufacturerView"/>
        <ActionGroupAction Name="ProductSalesTaxView"/>
 </ActionGoup>

The preceding example lists the three actions, ProductImageView, ProductManufacturerView, and, ProductSalesTaxView that can be performed in the ProductManagerViews action group.

The following is an example of the ProductImageView action definition:


<Action Name="ProductImageView"
CommandName="ProductImageView">
</Action>

The Name attribute, ProductImageView,is used as a tag for referencing the action elsewhere in the XML such as when associating the action with an action group.

Note: The name of the view, stored in the VIEW NAME in the Struts configuration files, must match the CommandName in the action definition. The value of CommandName is stored in the ACTION column of the ACACTION table. The Name and CommandName attributes do not have to be the same.