Home
Documentation
HCL Commerce is a high-availability, highly scalable and customizable e-commerce platform. Able to support hundreds of thousands of transactions per day, HCL Commerce allows you to do business with consumers (B2C) or directly with businesses (B2B). HCL Commerce uses cloud friendly technology to make deployment and operation both easy and efficient. 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. Business users can also use AI enabled content management capabilities.
Securing
These topics describe the security features of HCL Commerce and how to configure these features.
Authorization
HCL 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 HCL Commerce access control.
Customizing default access control policies
The default access control policies that are provided by HCL 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.

Documentation
HCL Commerce is a high-availability, highly scalable and customizable e-commerce platform. Able to support hundreds of thousands of transactions per day, HCL Commerce allows you to do business with consumers (B2C) or directly with businesses (B2B). HCL Commerce uses cloud friendly technology to make deployment and operation both easy and efficient. 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. Business users can also use AI enabled content management capabilities.
- Getting started
  HCL Commerce has different advantages for business users, administrators and developers. HCL Commerce targets each of these roles with a tailored set of offerings so that each of your users can get maximum benefit.
- Installing and deploying
  Learn how to install and deploy HCL Commerce development environments and HCL Commerce production environments.
- Migrating
  Before you migrate to HCL Commerce Version 9.1, review this information to help plan and execute your migration.
- Operating
  Topics in the Operating category highlight tasks that are typically performed by business users, customer support representatives, to complete their day-to-day tasks in the operation of the HCL Commerce site.
- Integrating
  Topics in the Integrating category highlight the tasks that are commonly performed for using HCL Commerce in combination with other products.
- Administering
  Topics in the Administering category highlight tasks that are typically performed by the Site Administrator, to support daily operations of the HCL Commerce site.
- Customizing
  The topics in the Customizing section describe tasks performed by an application developer to customize HCL Commerce.
- Tutorials
  HCL Commerce provides many tutorials to help you customize and understand your HCL Commerce instance and stores.
- Samples
  Topics in the Samples category highlight the various samples that are provided with HCL Commerce.
- Compliance
  The following section describes how you can leverage HCL Commerce features and functionality to help your site be compliant with different privacy and security standards.
- Securing
  These topics describe the security features of HCL Commerce and how to configure these features.
  - HCL Commerce security model
    Authentication is the process of verifying that users or applications are who they claim to be. In an HCL Commerce system, authentication is required for all users and applications that access the system, except for guest customers.
  - HCL Commerce authentication model
    The HCL Commerce authentication model is based on the following concepts: challenge mechanisms, authentication mechanisms and user registries.
  - Authorization
    HCL 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 HCL 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 HCL 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
      HCL 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 HCL 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 HCL 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 HCL Commerce are organized into the following categories:
    - Default access control policy groups
      The default access control policy groups that are shipped with HCL Commerce are the following:
    - Customizing default access control policies
      The default access control policies that are provided by HCL 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.
      - 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 HCL 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.
  - Hardening site security checklist
    To harden the security of your HCL 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 HCL Commerce site, you can enable various features in Administration Console or in the HCL Commerce configuration file.
  - 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 HCL Commerce environment requires a variety of user IDs. These user IDs along with their requisite authorities are described in the following list. For the HCL 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
  Topics in the Performance section describe the means by which to plan, implement, test, and re-visit the optimization of HCL Commerce site performance.
- Troubleshooting
  Topics in the Troubleshooting section highlight common issues that are encountered with HCL Commerce, and how they can be addressed or mitigated.
- Reference
  Topics in the Reference section contain all of the HCL Commerce reference documentation.

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.