Siebel Security Guide > Configuring Access Control > Implementing Access-Group Access Control >

Scenario For Implementing Access-Group Access Control


This topic gives one example of how access-group access control might be used. You might use access-group access control differently, depending on your business model.

Assume that you want the status of your resellers to determine which of your knowledge resources they have access to. Your resellers include partner organizations and some individual consultants that are not associated with a partner organization.

Your solution must meet the following requirements:

  • Provide your base resellers access to basic product information resources—service FAQs, product documentation, and product training classes.
  • In addition to basic product information, provide your "premier" resellers access to more sales-specific resources—marketing FAQs, documents that provide guidance on customer decision issues, and sales training classes.
  • In addition to product and sales resources, provide your alliance resellers access to resources to help design entire marketing campaigns—competitive briefs and training classes.
  • As the status of a reseller changes, the administration required to change the reseller's access to data must be minimal.

Figure 11 illustrates one access control structure that solves this business problem.

Figure 11. Reseller Resources Access Control Example
Click for full size image

This solution assumes that your partners are stored as organizations, in which partner users are associated with positions. The consultants exist as users; they have responsibilities, but not positions, and are not associated with an organization.

The Resellers Community is an access group hierarchy. Each node is an access group whose members are partner organizations and a single user list. The user list in each node contains all consultants of the appropriate status. For internal administrators to have visibility of the catalog, include their positions in the Alliance access group.

The Reseller Resources catalog is constructed of categories containing data and nodes that are empty categories to define access levels.

Apply the following principles to construct this structure:

  • Construct the Resellers Community such that the upper levels have the narrowest access to resources. Therefore, the Base Resellers access group is the parent of the Premier access group, which is in turn the parent of the Alliance access group.
  • Construct the Reseller Resources Catalog such that the Product Resources, Sales Resources, and Alliance Resources nodes are all first-level categories in the catalog.
  • The child nodes to the Product Resources node include categories of product resources. The child nodes to the Sales Resources and Alliance Resources nodes are determined similarly.

The following implementation procedure restricts the base resellers' access to product resources only, premier resellers' access to product resources and sales resources, and alliance resellers' access to all resources.

To implement the Reseller Resources access control structure

  1. Construct the Reseller Resources catalog, and specify it as private, with access provided to the Base Resellers access group.

    Access to the catalog is also granted to the Premier and Alliance access groups because access group access is inherited.

  2. Associate the Base Resellers access group with the Product Resources category, and use the Cascade button.

    Access is inherited by the Premier and Alliance access groups from the Base Resellers group, and access cascades from the Product Resources category to its subcategories containing data. The resulting behavior is that all the nodes in the Resellers Community have access to all the subcategories in the Product Resources category.

  3. Associate the Premier access group with the Sales Resources category, and use the Cascade button.

    Access is inherited by the Alliance access group from the Premier group, and access cascades from the Sales Resources category to its subcategories containing data. The resulting behavior is that the Premier and Alliance groups have access to all the subcategories in the Sales Resources category.

  4. Associate the Alliance access group with the Sales Resources category, and use the Cascade button.

    No group inherits access from the Alliance group. Access cascades from the Alliance Resources category to its subcategories containing data. The resulting behavior is that only the Alliance group has access to the subcategories in the Alliance Resources category.

  5. Set the catalog to type Partner to make it visible to partners and consultants on partner applications such as Siebel Partner Portal, and to internal administrators on Siebel employee applications in the Info Center screen.

This structure meets the minimal maintenance requirement. If the status of a partner organization changes, add the partner organization to the appropriate access group and delete the partner organization from the old access group. If the status of a consultant changes, add the user to the appropriate user list, and delete the user from the old user list. Recategorized consultants and partner users are granted appropriate new access as defined by the structure.

Sales tools of the same type, for example FAQs or product documentation, are in separate categories.

For information about:

Siebel Security Guide Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices.