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.
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.
Creating a new role-based access control policy
To create a new role-based policy for a new role, you can use the Organizational Administration Console for some subtasks, however, you need to load some of the changes manually through the use of access control policy XML files. 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.
Deleting policies
You must have Site Administrator authority to delete access control policies.

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.
      - 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.
        Creating a new role-based access control policy
        To create a new role-based policy for a new role, you can use the Organizational Administration Console for some subtasks, however, you need to load some of the changes manually through the use of access control policy XML files. 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.
        Viewing access control policies
        You must have Site Administrator authority to view policies.
        Viewing parent access control policies
        At a given level in the membership hierarchy, the policies that are owned by ancestor organizations are often worth noting. Although any policy belonging to a policy group can be applied to an organization through policy group subscription, it is often the case that policies owned by ancestor organizations are more general in nature and may be worth viewing. You must have Site Administrator authority to view parent policies.
        Creating an access control policy
        You must have Site Administrator authority to create an access control policy.
        Updating access control policies
        Only the Site Administrator can update an access control policy. Note that the access control policy name is a unique field, and duplicate policy names cannot exist in the database. So when the user tries to modify a default access control policy using the Organization Administration Console, the system expects a new name for the new non-default policy that is going to be created. So if the user does not specify a new name, the new non-default policy is not created and the user gets a message to provide a new name for the policy.
        Deleting policies
        You must have Site Administrator authority to delete access control policies.
        Selecting a user group
        You must have Site Administrator authority to select user groups. When creating or updating policies you need to select user groups.
        Creating access groups
        Use the Organization Administration Console to create access groups.
        Creating an action group
        You must have Site Administrator authority to create an action group.
        Creating a resource group
        You must have Site Administrator authority to create new resource group.
        Subscribing to policy groups
        Use the Organization Administration Console to subscribe an organization to a policy group.
        Listing site-level roles
        Use the Organization Administration Console to list site-level roles.
        Creating site-level roles
        Use the Organization Administration Console to create site-level roles.
        Example: Removing the ability of contract managers to add or delete attachments to contracts
        By default, contract managers for a store can add or delete attachments to contracts they manage. In some cases, you might not want to grant this authority to contract managers.
        Example: Permitting both contract operators and contract administrators to deploy contracts
        By default, contract operators for a store can deploy contracts. In some cases, you might want to grant this authority to contract administrators as well.
        Example: Permitting only Buyers to create orders
        By default, all users are permitted to create orders for products, regardless of their position in their organization. In some cases, you may want to limit the ability to create orders to a restricted group of users, such as the employees of the buying organization. Typically, these employees are assigned the Buyer (buy-side) role for the buying organization.
        Example: Allowing only Buyer Administrators to modify orders
        By default, all users are permitted to modify orders they have created, regardless of their position in their organization. In some cases, you may want only the organization's buyer administrator to have the authority to modify orders.
        Example: Allowing RMA approvers to approve all RMAs
        By default, return merchandise authorization (RMA) approvers for a store are only permitted to approve RMAs for their own stores. In some cases, you may want to allow RMA approvers to approve RMAs for any store. This might be desirable if several stores are owned by the same organization or if the same person handles the RMA approvals for multiple stores.
        Example: Removing the ability of users to self-register
        By default users are permitted to self-register if they belong to a registered organization. Membership administrators are also authorized to register users that belong to their organization. For sites that require strictly controlled access, it might be necessary to remove the ability to self-register and require that users be registered by membership administrators.
        Example: Allowing only registered and approved users to change their address information
        By default, users can modify their address information if their registration has been approved or is pending approval. In some cases, you might want only registered and approved users to manage their addresses.
        Example: Allowing member registrars to register users
        By default, membership administrators for an organization are authorized to register member of their organization. The access group, MemberAdministratorsForOrg, includes several roles such as buyer administrator and seller administrator, which are authorized to perform a variety of administrative tasks. In some cases, you might want to create a separate role that is authorized only to register organization members:
        Example: Allowing only buyers to redeem coupons
        By default, all users are permitted to redeem coupons. In some cases, you may want to limit coupon redemption to users with the Buyer (Buy-side) role in WebSphere Commerce.
        Example: Permitting both coupon administrators and Operations Managers to create coupon promotions
        By default, coupon administrators for a store can create coupon promotions for their store. In some cases, you might want to grant this authority to Operations Managers as well.
        Example: Allowing procurement shopping cart managers to manage the procurement shopping cart for orders created by their organization
        By default, procurement shopping cart managers are authorized to manage the procurement shopping cart when they have created the order. In some cases, you might want to extend the authority of procurement shopping cart managers to let them manage the procurement cart for orders created by any member of their organization.
        Example: Allow procurement buyer administrators to submit the procurement shopping cart for orders created by their organization
        By default, procurement shopping cart managers can save or submit procurement shopping carts if they have created the order. In some cases, you might want to divide the responsibility for these tasks. You could allow procurement shopping cart managers to save procurement shopping carts containing orders they have created but give procurement buyer administrators in the same organization as the order creator the authority to submit the procurement shopping cart. This might be beneficial if you want the procurement buyer administrator to review planned purchases before they are submitted.
        Example: Permitting fulfillment center managers to update fulfillment centers but not to delete them
        By default, fulfillment center managers are authorized to update or delete the fulfillment centers associated with their store. In some cases, you might want to allow fulfillment center managers to update fulfillment centers but not to delete them.
        Example: Permitting only logistics managers, operations managers, and account representatives to create, update, or delete fulfillment centers
        By default, fulfillment center managers are authorized to create, update or delete the fulfillment centers associated with their store. The fulfillment center manager's access group includes the roles: Seller, Logistics Manager, Operations Manager, and Account Representative. In some cases, you might not want Sellers to be authorized as fulfillment center managers.
        Example: Allowing auditors to view business intelligence reports
        By default, intelligence report viewers are permitted to view business intelligence reports for their store. In some cases, you might also want to create a new role called auditor and authorize users with this role to view a store's business intelligence reports.
  - 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

Deleting policies

You must have Site Administrator authority to delete access control policies.

Procedure

Open the Organization Administration Console.
From the Access Management menu, click Policies. A list of policies displays.
Select the check boxes beside the policies you want to delete.
Click Delete. A message box tells you that the selected policies have been deleted and prompts you to refresh the Policy Registry to apply recent changes to the run-time environment. Click OK. Note that the policies are deleted permanently from the database and not just marked as delete.