Secure > Authorization > Customize default access control policies

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, we will be able to follow the same methodology to make changes not specifically covered here.

The examples are organized by business area. Within each business area, the examples are presented in order of increased complexity.

Customization examples organized by type of customization

Customization	See the example
Add a role to a policy's access group	Permitting both coupon administrators and Operations Managers to create coupon promotions
Changing a policy's action group	Allow procurement buyer administrators to submit the procurement shopping cart for orders created by their organization Permitting fulfillment center managers to update fulfillment centers but not to delete them
Changing a policy's resource relationship	Allow only Buyer Administrators to modify orders Allow procurement shopping cart managers to manage the procurement shopping cart for orders created by their organization
Changing a policy to use a different access group	Limiting auction bidding to buyers Permitting only Buyers to create orders Allow only Buyer Administrators to modify orders Allow only registered and approved users to change their address information Allow only buyers to redeem coupons Permitting both coupon administrators and Operations Managers to create coupon promotions
Create a new access group and using it in a policy	Allow RMA approvers to approve all RMAs Allow member registrars to register users
Create a new action group and using it in a policy	Allow member registrars to register users Allow procurement buyer administrators to submit the procurement shopping cart for orders created by their organization
Create a new resource-level policy	Permitting both contract operators and contract administrators to deploy contracts Allow procurement buyer administrators to submit the procurement shopping cart for orders created by their organization
Create a new role-based policy	Allow member registrars to register users Allow auditors to view business intelligence reports
Create a new role and using it in a resource-level policy	Allow member registrars to register users Allow auditors to view business intelligence reports
Delete a policy	Remove the ability of auction managers to retract bids Remove the ability of users to self-register
Remove an action from a policy's action group	Remove the ability of auction administrators to close auction bidding Remove the ability of contract managers to add or delete attachments to contracts

Tips for changing default policies

• Most access groups are defined by user roles such as Buyer or Product Manager.

  To better understand these roles and what actions they are permitted to take, see Roles.

• Before you change a policy to use a different access group, review the definition of that access group to ensure it meets the requirements. To do so, select Access Management > Access Groups from the Organization Administration Console.

• Depending on the value you select for View, the Policies page lists the policies that are owned by the selected organization. It does not distinguish between site-level policies and policies specific to a particular organization.

• Rename any default policies you change so that the policy name reflects what the policy does and so that you can identify the default policies you have changed. Consider implementing a naming convention for the customized policies. If appropriate, you should also modify the description of the policy and its display name.

• The display names and the descriptions of accesscontrol elements are only available in the default language of the instance.

• The access control policy menu is moved to Organization Administration Console. The Organization Administration Console can only perform simple modifications to the access control policy definitions and access group definitions. The more robust solution is to update the data using XML files. The following operations can only be done through XML:

  1. Define new actions, resources, attributes, relationships, relationship groups.

  2. Define complex implicit resource groups, and complex implicit access groups.

  3. Assign a new policy to a policy group.

• Example: Removing the ability of auction administrators to close auction bidding
  By default, auction administrators for a store can modify or delete auctions for the store, as well as close bidding. In certain cases, you may not want to grant auction administrators the authority to close bidding, either because you want this action handled by others or because you do not require this action for the store.

• Example: Removing the ability of auction managers to retract bids
  By default, auction managers for a store can retract bids submitted at their auctions. In some cases, you might not want to grant this authority to anyone.

  To make this change, find the resource-level policy that defines who can retract bids and delete it.

• Example: Limiting auction bidding to buyers
  By default, all registered users are permitted to bid for products being auctioned at a store, regardless of their position in their organization. In some cases, you may want to limit bidding to a restricted group of users such as those assigned the buyer role in WebSphere Commerce.

• 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.

• Create 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, 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, edit the XML files directly, and then load them into the database.

• Create access groups
  Use the Organization Administration Console to create access groups.

• Create an action group
  You must have Site Administrator authority to create an action group.

• Create a resource group
  You must have Site Administrator authority to create new resource group.

• Subscribe to policy groups
  Use the Organization Administration Console to subscribe an organization to a policy group.

• List site-level roles
  Use the Organization Administration Console to list site-level roles.

• Create site-level roles
  Use the Organization Administration Console to create site-level roles.

Related reference

acpload utility

+

Search Tips   |   Advanced Search