Examples: Customize 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.
The examples are organized by business area. Within each business area, the examples are presented in order of increased complexity.
Tips for changing default policies
- Most access groups are defined by user roles such as Buyer or Product Manager.
- Before you change a policy to use a different access group, review the definition of that access group to ensure it meets your requirements. To do so, select Access Management > Access Groups from the Organization Administration Console.
- Depending on the value we 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 we can identify the default policies you have changed. Consider implementing a naming convention for our customized policies. If appropriate, you should also modify the description of the policy and its display name.
Note:
- The display names and the descriptions of access control 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:
- Defining new actions, resources, attributes, relationships, relationship groups.
- Defining complex implicit resource groups, and complex implicit access groups.
- Assigning a new policy to a policy group.
See
- Example: Remove the ability of contract managers to add or delete attachments to contracts
- Example: Permit both contract operators and contract administrators to deploy contracts
- Example: Permit only Buyers to create orders
- Example: Allow only Buyer Administrators to modify orders
- Example: Allow RMA approvers to approve all RMAs
- Example: Remove the ability of users to self-register
- Example: Allow only registered and approved users to change their address information
- Example: Allow member registrars to register users
- Example: Allow only buyers to redeem coupons
- Example: Permit both coupon administrators and Operations Managers to create coupon promotions
- Example: Allow procurement shopping cart managers to manage the procurement shopping cart for orders created by their organization
- Example: Allow procurement buyer administrators to submit the procurement shopping cart for orders created by their organization
- Example: Permit fulfillment center managers to update fulfillment centers but not to delete them
- Example: Permit only logistics managers, operations managers, and account representatives to create, update, or delete fulfillment centers
- Example: Allow auditors to view business intelligence reports
- Creating a new role-based access control policy
- Creating access groups
- Creating an action group
- Creating a resource group
- Subscribing to policy groups
- Listing site-level roles
- Creating site-level roles
Related concepts
Access control policy
Authorization
Evaluating access control policies
Relationships between role-based and resource-level policies
Enforcing access control
Role-based and resource-level policies
Related reference
acpload utility