Policy Server Guides › Policy Server Configuration Guide › SiteMinder Administrators › Administrator Use Cases

Administrator Use Cases

This administrator use case illustrates the following:

• How administrators are created
• How an existing administrator can create and grant privileges to a new administrator

This scenario involves three administrators

• SiteMinder Default Administrator (Superuser)
• Manager Admin
• Junior Admin

Using the three administrators, the following scenarios are described:

• Superuser creates Manager Admin
• Superuser creates a workspace and assigns it to scope Manager Admin
• Manager Admin creates Junior Admin
• Manager Admin creates a workspace and assigns it to further scope Junior Admin

The following terms are used throughout the use case:

Access Method

Specifies how an administrator interacts with the Policy Server.

Security Category

Specifies a functional area in which an administrator can execute tasks to manage Policy Server objects or tools.

Scope

Indicates whether administrator privileges extend to all policy objects or a subset of objects defined in an assigned workspace.

Permissions

Determines whether an administrator can read, manage, propagate, or execute tasks related to a security category.

Rights

Defines the complete set of privileges for the administrator. Rights are based on the security category, scope, and permissions.

Superuser Creates Manager Admin

The superuser is the administrator that was delegated system privileges when the connection to the external administrator user store was configured. The superuser can assign all categories, rights, and scope to any other Administrator.

From the Administrative UI, the superuser creates an administrator named Manager Admin. Initially, Manager Admin has no privileges until the superuser assigns them.

The superuser assigns the following to Manager Admin:

Access Method

GUI Allowed

Rights

* Permissions: View, Manage, Propagate, eXecute (only for executing reports)

Note: The Propagate permission allows one manager to assign the category to another administrator.

At this stage, if Manager Admin logs in to the Administrative UI, they can view and modify all agents, applications, and domains in the policy store. If they create an administrator account, they can assign only Application Administration and Policy Administration security categories to that account.

Superuser Creates a Workspace and Assigns it to Scope Manager Admin

The superuser wants to limit the scope of Manager Admin so that they can only manage a subset of policy data. To do this, the superuser first creates a workspace named Workspace1 with the following members:

The superuser then edits the Administrator record for Manager Admin to assign Workspace1.

At this stage, if Manager Admin logs in they can now only view and modify Agent1, Application1, Application2, and policies in DomainB. Other agents, applications and domains in the policy store do not appear in the Administrative UI.

Manager Admin Creates Junior Admin

The second part of this use case shows how an administrator with a specific set of privileges creates another administrator.

Manager Admin creates an administrator named Junior Admin. When Manager Admin goes to add security categories for Junior Admin, only the following two (for which Manager Admin has the propagate permission) are available:

• Application Administration
• Policy Administration

Note: The propagate permission lets one administrator assign the category to another administrator.

Manager Admin proceeds to assign access methods and rights to Junior Admin as follows:

Access Method

GUI Allowed

Rights

* Permissions: View, Manage, Propagate, eXecute (only for executing reports)

At this stage, if Junior Admin logs in to the Administrative UI, they can view Application1 and Application2. They can view and modify DomainB (limited by default to the scope of Manager Admin).

Manager Admin Creates a Workspace and Assigns it to Further Scope Junior Admin

Manager Admin wants to further limit the scope of Junior Admin so that they can only manage a smaller subset of policy data. To do this, Manager Admin first creates a workspace named Workspace2 with the following members:

Manager Admin then edits the Administrator record for Junior Admin to assign Workspace2.

At this stage, if Manager Admin logs in they can now only view Application2, and view and modify policies in DomainB. Other applications and domains in the policy store do not appear in the Administrative UI.