| Oracle® Access Manager Identity and Common Administration Guide 10g (10.1.4.0.1) Part Number B25343-01 |
|
|
View PDF |
| Oracle® Access Manager Identity and Common Administration Guide 10g (10.1.4.0.1) Part Number B25343-01 |
|
|
View PDF |
This chapter explains how to specify Identity System administrators.
This chapter contains the following topics:
The Identity System manages user, group, and organization identity information, as described in the Oracle Access Manager Introduction.Administering the Identity System involves a broad range of tasks that are designed to help you manage your data, enhance performance, and control the appearance and functionality of Identity System applications. For details about these tasks, see "Configuring Global Settings".The responsibility of administering the Identity System is shared between Master Administrators and Master Identity Administrators:
Master Administrators: At least one Master Administrator is specified when the product is set up. This is the highest level administrator. This administrator can specify other Master Administrators and Master Identity Administrators.
Master Identity Administrators: Master Identity Administrators can delegate specific responsibilities to administrators called Delegated Identity Administrators.
Delegated Identity Administrators: Delegated Identity Administrators are assigned by Master Identity Administrators and created in User Manager.
See Table 2-1 for a description of the types of Identity System administrators and their privileges
Table 2-1 Types of Identity System Administrators
| Administrator | Becomes an Administrator When | Tasks Performed |
|---|---|---|
|
Assigned when Oracle Access Manager is installed |
|
|
|
Assigned by the Master Administrator |
|
|
|
Assigned by Master Identity Administrators |
|
You use the Identity System Console to assign Delegated Identity Administrators and Master Identity Administrators. As mentioned earlier, you must be a Master Administrator to complete this task.
To specify Master Administrators and Master Identity Administrators
Log in to the Identity System as a Master administrator, and from the landing page for the Identity System, click the Identity System Console link.
If you are already logged in, click the Identity System Console tab.
Click the System Configuration sub-tab.
The System Configuration page appears.
Click Administrators in the left navigation pane.
The Configure Administrators page appears, displaying two options: Master Identity Administrators and Master Administrators.
See Table 2-1 for a list of the tasks performed by each type of administrator.
Click the category of administrator you want to add.
A Modify type_of_administrator page appears.
where, type_of_administrator is either a Master Administrator or a Master Identity Administrator.
Click Select User to add an administrator.
See "The Selector" for information about using this feature.
Select a user and click Add.
The name you select in the Selector page appears in the Modify type of administrator page, where type of administrator is a Master Administrator or a Master Identity Administrator. You can specify multiple administrators.
Click Done to leave the Selector page.
Click Save to add the administrator.
When you delete an administrator, you remove administration rights from the user, but you do not remove or deactivate the user from the LDAP directory.
From the Identity System Console, click the System Configuration sub-tab.
Click Administrators.
In the Configure Administrators page, click the link for the type of administrator that you want to delete.
The Modify type of administrator page appears, where type of administrator is a Master Administrator or a Master Identity Administrator.
Click Select User.
Clear the DEL button next to the administrator who you want to delete.
Click Done to confirm the deletion.
You can delegate your rights and responsibilities to other administrators. The tasks delegated are specific to the delegated right, the target, and the tree path.
This section covers:
Delegating administration allows the Master Administrator and Master Identity Administrator to delegate their responsibilities to other, more local administrators. This is particularly useful in large organizations, where it may be necessary to administer thousands or millions of users.
When you delegate administration, you determine what rights you want to grant to another user. Rights include the ability to configure the following:
Read access for attributes
Write access for attributes
Notification by email of attribute modifications
Setting the searchbase
Monitoring requests
Defining workflows
Containment limits
In addition, you can designate people to act as your substitute. People who are granted substitution rights can temporarily perform any of the functions that you are permitted to perform.
After you have delegated a right to another user, that user becomes a Delegated Identity Administrator. By delegating administration, you determine who can configure or access which feature, at what level, and with which filters. Configuration or access authority may be for a specific user or group of users, a role, or a rule. The resource that can be configured or accessed may include a searchbase, an attribute access control, a workflow definition and so forth. The level is the starting DN.
Task overview: Delegating administrators
Start the delegation procedure for the desired application.
Select the right that you want to grant (for Read, Write, and Notify permissions only).
Identify the attribute associated with the right.
Specify the level of access control for that attribute, thus setting the scope of the directory tree to which the rights apply.
Select the person to whom you are delegating the rights.
For example, as the Master Identity Administrator, you can grant one or more users the ability to set Read access control for the Title attribute. You can specify whether you want the Delegated Identity Administrator to be able to delegate access control to others.
For more information, see "Adding Delegated Administrators".
The Identity System enables you to set access controls and delegate administration for directory tree structures that represent different business models. These models include an extranet model, an intranet model, and an ASP model. These models are described in the following sections:
A typical business-to-business extranet might have 500 or more extranet organizations using a site. These organizations represent customers, partners, and suppliers, each having between 1 and 100 users.
The goal in the extranet model is to have the Master Identity Administrators push out administrative responsibilities to each of the partners. But because there are so many partners, it would be a burden to define new roles and responsibilities each time a partner joined. Therefore, the Directory Administrator must define a fixed set of roles and responsibilities that are leveraged across all customers, existing and new. The Master Identity Administrator can then define access controls and create delegated administrator policies that are symmetric across all organizations.
The Delegated Identity Administrator at each partner site is typically a line-of-business person who has a fixed, well-defined set of tasks and rights, such as creating users and changing attribute access permissions. Delegated Identity Administrators can only give others in their organization administrative privileges by adding and deleting people from a set of pre-defined roles.
For example, the Delegated Identity Administrator creates a new user with an attribute of admin=yes. This new user then inherits the ability to change attribute access control permissions, create new users, and other well-defined tasks, as illustrated in Figure 2-1.
In a typical intranet model, the directory tree is generally organized according to a logical separation of users, such as by geography (North America and Europe) or function (Marketing and Engineering).
The directory might be characterized by only a few branches at each OU, but may be several layers deep in branching. The branches may be very different from each other and may have several thousand users in each branch. At a given node, a European branch might have 500 users under Sales and Marketing, while a North American branch might have 10,000 users under East, Central, and West.
The Master Identity Administrator may choose to delegate administration centrally or at the OU level, depending on where the technical and business process knowledge resides. Or additionally, the Master Identity Administrator may choose to delegate administration across specific tasks; for example, you might delegate the task of provisioning phone numbers—but not managing access permissions or creating new users.
Figure 2-2 illustrates the intranet model:
Some business-to-business extranet sites may follow the application service provider (ASP) model more closely than the extranet model described earlier.
In an ASP model, there are fewer extranet partners but significantly more users at each partner site. For example, there may be only approximately 50 partners but each partner may have 1000 users.
ASPs provide hosted services. Different customers may need different sets of services. This means the scope of data that needs to be managed, such as access rights, may differ for each OU. Further, the directory structure of each OU may be substantially different. Under each OU may be all the complexity of an intranet directory tree as in the intranet model, yet the structure of the tree could be completely different between the OU for Customer 1 and the OU for Customer 2.
The ASP model needs a flexible delegation model similar to the intranet model. The Master Identity Administrators at the ASP site performs some top-level configuration, such as setting the searchbase, and configures an initial delegation model similar to the extranet model. However, each customer site requires the flexibility to create a customized delegated administration model, either by a technical Delegated Identity Administrator at the customer site or by the Master Identity Administrators at the ASP site.
Delegating administration allows the Master Identity Administrator or a Delegated Identity Administrator to further delegate responsibility to other local administrators.
Log in to the Identity System, and from the landing page select the link for the User Manager, Group Manager, or Organization Manager.
If you are already logged in, select the tab for the application.
Click the Configuration sub-tab.
The Configuration page appears.
Click the Delegated Administration link.
On some browsers you may receive a prompt asking if you trust the certificate of the application. If you receive this prompt, select the Trust Always option.
The Delegate Administration page appears.
In the Management Domain box, specify the scope of the DIT that this right applies to.
Initially this field displays the searchbase defined during setup. The searchbase is usually defined at the highest (company-wide) level. Depending on the level of your delegated rights, you can specify access control at any level, from the lowest level (an individual user), through intermediate levels (departments, divisions, partners), and then to the highest level (company-wide). For example, if you select the Full Name attribute and select a department such as Sales, you are setting an access control that applies to all full names belonging to the Sales department.
The selection appears in the field beneath the Management Domain box.
Optionally, use the Filters field to specify either a variable substitution or LDAP rule to filter the DIT level you selected.
For more information, see "Usage of Rules and Filters".
Optionally, in the Add Filter field, enter another filter, then click Save.
The new filter appears in a field beneath the previous filter.
In the Grant Right list, select the right that you want to grant to the delegated administrator:
Read: Allowed to set read (view) permission for the selected attribute
Modify: Allowed to set modify permission for this attribute
Notify: Allowed to set notify permission when user requests attribute value change
Set Searchbase: Allowed to specify the searchbase
Monitor Requests: Allowed to monitor requests and manage deactivated users
Define Workflow: Allowed to define workflows
Substitute Rights: Allowed to designate other people as your substitute
Give the new administrator the authority to further delegate this right to other administrators by selecting the Delegate Right check box.
|
Note: Selecting Delegate does not automatically assign Grant rights. You must define Delegate and Grant rights separately. |
In the Attribute box, select an attribute to associate with the right.
Select a trustee to whom you want to assign one or more rights with one or more of the following methods:
Rule: Click Build Filter and use the Query Builder to create a rule. See "Writing LDAP Filters Using Query Builder" for details.
Person(s): Click Select User and use the Selector to specify one or more users.
Group(s): Click Select Group and use the Selector to specify one or more groups.
The Rule, Person(s), and Group(s) fields have an or relationship. A user specified in any of these fields is assigned the right.
Use the Copy and Paste buttons to copy users and groups from one attribute to another.
Click Copy, click Reset, select another attribute, and click Paste. The users and groups appear in their respective boxes.
Click one of these buttons:
Save: Saves and implements your changes
Reset: Clears all selections
Delete: Clears all rule, group, and user specifications
Report: Generates a report of all attributes and their access permissions across the domain
As an Identity System Administrator, if you have been granted substitute rights, you can designate other people to temporarily assume your rights. After your substitute logs into the Identity System, they can assume your identity. When your substitute views the My Identity page, your information is shown rather than the other person's information.
By assigning substitute rights, you allow someone else temporarily to assume your identity. For example, suppose you are a Delegated Identity Administrator. Before leaving for vacation you assign substitute rights to J. Smith. When J. Smith logs in, he assumes your identity. Later, when J. Smith wants to perform his own duties, he reverts the delegated rights. Although the substitute appears to be you while assuming your identity, the Identity System logs all activities with both the substitute's and your identities. All logs and alarms show duplicate entries using both identities.
To assign or remove a substitute
From the Identity System landing page, log in and select the link for the User Manager.
If you are already logged in, click the User Manager tab.
Click the Substitute Rights link.
The Substitution Rights page appears.
If you have been granted substitute rights, this page contains a Select User button. If you have designated people to be your substitute, these people are listed in the Substitute(s) field. This page also contains a Substitute for field with a list of people who have designated you as their substitute. If no people are listed, no one has designated you as their substitute.
Assuming that you have been granted substitute rights, click Select User.
The Selector page appears. See "The Selector" on page 1-10 for details.
Select the user and click Add.
The user is added to the Selected list.
Select a user and click Delete to remove the user.
The user is removed from the Selected list.
Click Done to leave the Selector page.
Click Save to save your changes.
From the Identity System landing page, log in and select the link for the User Manager.
If you are already logged in, click the User Manager tab.
Click Substitute Rights.
In the Substitute for User section of this page, select the user whose rights you wish to assume.
This user must already have assigned you to be a substitute.
Select Assume Right and click Save.
To revert to your own identity
From the User Manager, select Substitute Rights.
Select Revert
See "Configuring Global Settings" for details about configuring styles for Identity System applications, configuring multiple languages for the Identity System, configuring and managing Identity Servers and WebPass, and configuring password policies and the Access Manager SDK for the Identity System.
