Member subsystem roles
WebSphere Commerce defines a default set of roles that govern what a user is allowed to access in the system. In the access control system, policies are set up for each role. These access control policies grant access to a specified set of actions, such as executing commands and views or displaying data beans.
- A user that has a role in a particular organization can complete actions on certain assets that
are owned by that organization.
- Roles in WebSphere Commerce are always assigned in the context of an organizational entity.
- Role assignment is hierarchical in nature. A user that has a role for an organization can also complete actions on assets that are owned by that organization's descendant organizations.
- Users can have roles in their own parent organization or in other organizations as well.
- Roles are assigned to an organization to indicate which roles users can have for that organization. An organization can have only the roles that its parent organization supports. For example, user X that belongs to organization Y can have a role in another organization, Z. Specifically, user X can have any role in organization Z that organization Z supports.
All roles are defined in the ROLE table, and are automatically assigned to the Root Organization. The role assignment data (for both users and organizational entities) is stored in the MBRROLE database table. In addition, the MBRGRP and MBRGRPCOND database tables store other role related information.
- Business relationship roles
- Customer service roles
- Marketing roles
- Operational roles
- Organizational management roles
- Product management and merchandising roles
- Technical operations roles
- Supplemental roles (These roles do not have access to WebSphere Commerce Accelerator, or other WebSphere Commerce tools.)
- Workspaces roles
- Root
- The top level of an organization, which owns site level access control policies, and is automatically assigned all roles included in the WebSphere Commerce product. You are recommended not to assign roles (other than Site Administrator) to users at the Root Organization. Assign roles at the lowest level organization that still satisfies the business requirements instead. For example, if a user needs to manage all the stores in a site, you might assign the user a role at an organization that is a descendant of the Root Organization and is also an ancestor of all of the store organizations. Assigning roles arbitrarily at the Root Organization level can cause performance issues, especially if there are many suborganizations. The performance issues can occur because there are cases when logic needs to iterate through all of the suborganizations to evaluate certain conditions.
- Seller
- An organization that owns one or more stores on a WebSphere Commerce site and typically sells to a buyer organization. The seller organization can also have suborganizations, or divisions, which, in turn, can have one or more stores. For example, if you have a store that sells fashion merchandise, it might have a women's division and a men's division, each with separate, online stores.
- Buyer
- An organization that typically buys from a store. If you are running a business-to-business (B2B) site, one or more buyer organizations can belong to your site. After you establish which businesses participate in a buying relationship with your site, you must create a buyer organization for each business. You can have as many buyer organizations as you require.
Organization | Type of role | Role |
---|---|---|
Root | Technical operations |
|
Seller | Operational |
|
Organizational management |
|
|
Business relationship |
|
|
Product management and merchandising |
|
|
Marketing |
|
|
Workspaces |
|
|
Customer service |
|
|
Buyer | Organizational management |
|
- A Site Administrator is the only role that has the authority to create, assign, or unassign roles to and from all users or organizational entities. To maintain access control that is defined by roles, while roles can be added, they cannot be removed or renamed.
- A Seller Administrator or Buyer Administrator has the authority to perform the following tasks:
- Assign or unassign roles to the organizational entity for which they are the Seller Administrator or Buyer Administrator, and to organizational entities below that organizational entity. However, the organizational entity for which the administrator performs the assignment must not be the administrator's parent or ancestor in the membership hierarchy.
- Assign or unassign roles to users who belong to the organizational entity for which they are the Seller Administrator or Buyer Administrator, or who belong to the organizational entities below this organizational entity.
- Assign roles to themselves.
- An organizational entity can be assigned only roles that its parent organizational entity is assigned.
RegisterType | Description |
---|---|
S | User is assigned the Site Administrator role. |
A | User is assigned certain roles within the Seller organization, such as
Operations Manager, Customer Service Representative, or Seller Administrator. A default implicit member group that is called Administrators is shipped with WebSphere Commerce with the preceding list of roles that are defined as criteria. During role assignment, if the role that is being assigned or unassigned is an administrative role, the value of RegisterType is set to maintain consistency. |
R | Registered customer. A customer who is registered and provided WebSphere Commerce with some profile data. This role is assigned to a user (shopper) when they register with a store organization to indicate that they are registered with the site. |
G | Guest customer. A customer who is not registered. |
- Each of these roles belongs to one or more business models and can perform tasks in one or more profile stores within each model.
- Important. The values of 'S' and 'A' are role-related while the values of 'R' and 'G' are related to whether the user is registered. Although 'S' and 'A' are supported as valid values for RegisterType, they are deprecated and separated from RegisterType. 'S' and 'A' are values of a different attribute. Consequently, do not write code to depend on 'S' or 'A' being the value of the RegisterType attribute. If code must be written to examine the role or registration type of a user, such code should be replaced by access control policies or written to use appropriate APIs instead.