| 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 |
The Identity System applications (the User, Group, and Organization Manager) enable users to view and modify data about themselves, other users, groups, and other objects. The items that users see on the Identity System applications consist of LDAP directory attributes that you have configured in the Identity System Console. In order for the Identity System applications to display data, you use the Identity System Console to configure objects and attributes from a directory schema that the application is to work with.
The Identity System applications also enable users to send data to back-end applications. For example, users can enter data in a workflow, and that data can be sent to an application that creates new user email accounts. To prepare the Identity System applications to be used in this manner, you use the Identity System Console and configure objects and attributes from a template schema. A generic schema file is supplied with the Identity System.
This chapter discusses the following topics:
As an Identity System administrator, you configure three applications for your users (and other administrators). These applications are the User Manager, Group Manager, and Organization Manager.
Figure 3-1 shows a portion of a User Manager Profile page.
The Identity System applications obtain most of the data that they display from entries in an LDAP directory. For instance, the User Manager may show a person's name, email, and so on. This data is taken from attribute values stored on a person object in the directory. These attributes and their values are displayed on profile pages in the User Manager. In Figure 3-1, the name displayed in the user profile is based on the name attribute for the person object in the directory. The actual name being displayed is a value stored with the attribute. The title is based on the title attribute for the person object.
All of the Identity System applications—the User Manager, Group Manager, and Organization Manager—display attribute values for specific objects on profile pages.
In addition to configuring objects and attributes from an LDAP directory, the Identity System enables you to define template schemas. Using the Identity System Console, you configure the objects and attributes from a template schema in the same way that you configure LDAP data. However, LDAP data and template data are used in different ways. You configure LDAP data to populate Identity System applications. Users enter values for LDAP data from either an Identity System application profile page or from a workflow. The LDAP data is displayed on the profile page. In contrast, you can only enter template data during a workflow step. The data is not displayed on the profile page. Instead, it is sent to a back-end application that needs the data.
Unlike LDAP data, you can use only template object data for sending data to back-end systems. For example, you can create an object template schema with attributes that an email system can understand. You would then configure the attributes from this schema in the Identity System, define a workflow that uses these attributes, and use the Identity Event API to send this data to the back-end system.
|
Note: For instructions on how to configure the template object file, see "Sending Non-LDAP Data to External Applications". The template object file must be finalized before you can configure the template objects in the Identity System Console, as described in "Sending Non-LDAP Data to External Applications" . |
When you first install and set up Oracle Access Manager, the User Manager, Group Manager, and Organization Manager applications are empty. You need to configure these applications with information. For example, you may want the User Manager to display information about a user such as their name, title, phone number, email, and so on. Before configuring the appearance of these applications, you must first use the Identity System Console to configure the LDAP objects and attributes that you want to display on the application profile page. You must also define how each attribute is to be displayed, for example, if it is a string value, a selection list, or a radio button. You primarily use LDAP directory data to identify in the Identity System Console which objects and attributes you want to display to users on application profile pages.
Once you have configured objects and attributes in the Identity System Console, you can configure Identity System applications to display these attributes and their values. Configuring the Identity System applications is discussed in "Configuring User, Group, and Organization Manager". Finally, you assign View and Modify rights to determine who can view and modify these attributes.
If you are using the Identity System as the entry mechanism for an external application, you use the Identity System Console to configure template objects and attributes. As with LDAP data, you define how each attribute is to be displayed on a profile page. The primary difference between LDAP and template data is that users may only enter values for template attributes during a workflow step, and you must use the Identity Event API to pass this data to a back-end application.
During installation and setup of the Identity System, you configured the following object classes:
Group Manager: A required group object class
Organization Manager: A predefined location object class
These object classes are taken from the LDAP directory that the Identity System communicates with.
In addition to the object classes that are configured during the installation process, you may want to configure additional LDAP and template-based objects and attributes. The following sections discuss how you configure objects and attributes to provide the Identity System applications with data.
|
Note: Configuring an attribute does not ensure that the attribute is displayed on an Identity System application page. You must associate specific attributes with an Identity System application page, and assign View and Modify rights to these attributes. See "Configuring User, Group, and Organization Manager" for details. |
The Identity System works with structural and auxiliary LDAP object classes. When you install the Identity System, the User, Group, and Organization Manager applications are associated with one structural object class each. A structural object class describes the basic aspects of an object. Examples of structural object classes include person and groupOfNames. The person object class may contain attributes such as name, department, employee ID, and email address.
The User Manager and Group Manager are always associated with only one structural object class.
The Organization Manager can be associated with any number of structural object classes of a generic or location object class type (see "Object Class Types" for details). During installation and setup, a location structural object class is associated with the Organization Manager. In the Organization Manager, each structural object class is represented as an option in the menu in the top right corner of the page. The work area for a particular object class in the Organization Manager is referred to as a tab.
You use an auxiliary object class to add a set of related attributes to an entry that already belongs to a structural class. Auxiliary object classes are mix-in LDAP object classes that can be added to any structural class. Items such as a billing address, a challenge phrase, a response to a challenge phrase, and so on may be useful for definition in an auxiliary object class.
You must configure attributes for each object class that you want to manage through the Identity System Console. See "About Object Class Attributes" for more details.
|
Note: Before users can see values for attributes that you configure, you must set up the User Manager, Group Manager, and Organization Manager tabs and provide view and modify permissions, as appropriate, to the users. See "Configuring User, Group, and Organization Manager" for details. |
The inheritance of all objects is based on the premise of a common super class for both the structural object class and the auxiliary class. Otherwise, object class extension is not feasible. For example, if you don't choose Top as the inherited Object Class in eDirectory, NDS sets the inherited object class to None. When you configure the object class as an auxiliary class in the Identity System, no problems are evident initially. However, if you execute a Create User Workflow that contains attributes of this auxiliary class, the Enable step fails when trying to commit because the schema is incompatible and the auxiliary class cannot be added to the entry's object class attribute due to a schema violation.
In addition to structural and auxiliary object classes, the Identity System recognizes template object classes. Template object classes function in part like auxiliary object classes, in that they are used to augment the functionality on an Identity System application tab, and they cannot be used as the foundation for a tab. However, template objects are not defined in an LDAP directory, and you do not use template objects for configuring the profile pages shown on a tab.
You define template objects in a schema file. The template objects are only used in Identity System workflows, for sending data to back-end applications. Template object classes differ from the other kinds of object class in several respects:
Users interact with the template object class attributes to send data to back-end applications.
Users interact with template object class data attributes only in the context of an Identity System workflow.
Template attribute values are only visible when a user invokes a workflow instance and enters the data. Once the data is submitted, it cannot be displayed again in the Identity System. See "Chaining Identity Functions Into Workflows" for details. This is different from LDAP data, which you use to configure the fields, labels, and other items displayed on the Identity System application pages.
|
Note: Template attribute values cannot currently be displayed because the flow of data from the Identity System to the back-end system is one-way. This limitation will be removed in a future release. |
Template object data resides a template object file, not an LDAP directory.
For information on defining template objects and the complete process for using them with back-end applications, see "Sending Non-LDAP Data to External Applications".
When configuring your object classes, you are asked to specify an object class type. The term object class type refers to how an object class is used within the Identity System. Table 3-1 lists the object class types supported in the Identity System.
Table 3-1 Object Class Types
| Type | Description |
|---|---|
|
This type contains information about a person. Examples of this type include companyOrgPerson and customerOrgPerson. When you install the Identity System, the oblixOrgPerson type is created. This is an important auxiliary object class. It provides the obUserAccountControl attribute, which you should never modify. This attribute is written to the profile of any user you deactivate. |
|
|
This type contains information about a group. Examples include groupOfUniqueNames and mailGroups. When you install the Identity System, the oblixGroup and the oblixadvancedgroup type auxiliary classes are created to help you configure useful information on the Group manager. |
|
|
This type contains information about locations. The Organization Manager uses this object class to store and display location information. |
|
|
Any object class that does not fit in the other categories. An example includes the organizationalUnit object class that is managed by the Organization Manager. |
When you install and set up the Identity System, several object classes are already configured. You can view and modify these object classes, and you can create additional object classes.
To view configured object classes
From the Identity System Console, click Common Configuration.
The Common Configuration page appears.
Click the Object Classes link in the left navigation pane.
The Configure Object Classes page displays object classes that are configured in your LDAP directory and object templates, along with the following information:
| Column | Description |
|---|---|
| Object Class | Name of the object class. |
| Object Class Type | How the object class is used by the Identity System. See "Object Class Types" for details. |
| Object Class Kind | If you have configured an LDAP object, the kind can be Structural, Auxiliary, or other object. See "Structural and Auxiliary Object Classes in the Identity System" for details. An object class kind of Other indicates that the object class kind is undefined. Text can be Don't care or Unknown.
If you have configured a template object, the kind can only be Template. See "Template Object Classes" for details. |
| Object Class Attribute | This is used by the Identity System for attribute access and it is also the attribute that the Identity System uses to link search results to a profile page. See "Selecting a Class Attribute" for a description. |
From the Identity System Console, you can change the class attribute and the type for an object class. It is important to specify a class attribute for your structural object classes.
You can change the structural object class. However, it is best if you plan your configuration so that this task is not necessary.
|
Note: Using the application-specific Tabs function, you can provide a different display name or display type for an attribute on that application-specific Configuration tab only (different than what is configured at the object class level). This will override the information configured for the attribute at the object class level. For details, see "Modifying and Localizing Attributes Displayed on a Panel". |
To modify an object class type
From the Identity System Console, click Common Configuration.
The Common Configuration page appears.
Click the Object Classes link in the left navigation pane.
Click the link for the object class you want to modify.
The View Object Class page appears.
Click Modify.
The Modify Object Class page appears.
Select a new class type.
See "Object Class Types" for more information on object class types.
Save your change.
In the User Manager, Group Manager, and Organization Manager, each tab is associated with a structural object class. Within the structural object class, you select an attribute to be the class attribute. The class attribute is used for attribute access. Users who do not have read access to a class attribute do not have access to the entire entry.
|
Note: It is not required to set a class attribute for a template object class. You determine user access to template objects and attributes when you configure a workflow, as described in "Chaining Identity Functions Into Workflows". |
The Identity System also uses the class attribute when displaying search results on a profile page. When a user conducts a search, the Identity System returns a list of results. Each returned item has one value that is displayed as a link. The linked value is taken from the class attribute of the returned object. When the user clicks the link, the Identity System displays the profile associated with that link.
For example, if you specify User Name as the class attribute for the orgPerson object class, when someone searches in the User Manager, the list of search results displays user names as links. Clicking a link displays the profile for that user.
Class attributes are usually selected as follows:
Group Manager uses a class attribute for a group's name.
Organization Manager uses one class attribute for each tab. For the location structural object class, the attribute would typically be a location name.
From the Identity System Console, click Common Configuration.
The Common Configuration page appears.
Click the Object Classes link in the left navigation pane.
Click the link for the object class you want to modify.
The View Object Class page appears.
Click Modify.
The Modify Object Class page appears.
Select the class attribute from the list of attributes.
Note that you can only select a class attribute for a structural object class.
Click Save.
Changing the user or group structural object class requires you to rerun Identity System setup.
To change user or group structural object classes
Shut down all but one Identity Server.
Locate IdentityServer_install_dir/identity/oblix/config/setup.xml, and change the status parameter value from "done" to "incomplete," as described in "Rerunning Setup Manually".
Depending on which application you are modifying, delete the top node for the structural object class, as follows:
User Manager node: obapp=userservcenter,o=Oblix,o=company,c=us
Group Manager node: obapp=groupservcenter,o=Oblix,o=company,c=us
Restart the Identity Server and navigate to the Identity System Administration Console to initiate and complete the setup process as you reconfigure the structural object classes.
When you restart the Identity Server, the other Identity Servers should pick up the new structural user or group object class from the updated directory tree.
There are two basic methods for adding an object class in the Identity System Console:
Configure each attribute manually.
Select the autoconfigure object class option
This method configures the object class using settings from the Identity System. This option is faster than manual configuration. You cannot view or modify the Identity System-provided attributes before importing them.
With either option, you can later modify the attributes from the System Console. See "About Object Class Attributes".
From Identity System Console, click Common Configuration, Object Classes.
Click Add.
The Add Object Class page appears.
The default schema domain is LDAP. If you have not defined any template object classes, LDAP is the only choice. If you have configured additional template object classes and want to configure objects from the additional class, select the class from the Schema Domain list.
In the Schema Domain list, select the type of schema that you want to work with, if applicable.
From the Object Class list, select the object class to add.
This allows the Identity System to manage the object class. The list contains object classes that were defined in your LDAP directory prior to installing the Identity System.
In the Class Type field, select what type of Identity System application can manage this object class.
See "Object Class Types" for details.
In the Class Kind field, select Structural, Auxiliary, Template, or Other.
If the Identity System can determine the Class Kind from the LDAP directory, these radio buttons are hidden.
Select Auto Configure object class to populate this object class with attributes from an Identity System-provided file.
Click Save.
When a template object class is saved, it is saved in fully qualified form. For example:
obclass=person.miis,o=oblix,o=company,c=us
This format is taken from the .tpl file that contains the template object class definition. See "Sending Non-LDAP Data to External Applications" for details.
You can use auxiliary object classes as mix-ins with structural object classes. This can be helpful when you configure the User Manager, Group Manager, and Organization Manager applications. The more object classes you have at your disposal, the more items you can display on the tabs for these applications, and the more information you can configure for users of those applications.
An object assigned to an auxiliary object class must be associated with a structural class. For example, you can add inetOrgPerson as your structural object class and associate it with the tab in the User Manager application. You can then add auxiliary object classes with attributes for particular kinds of people, such as customers, partners, and so on.
To associate one or more auxiliary object classes with the structural object classes chosen for the Identity System applications, see "Adding Auxiliary and Template Object Classes to a User or Org. Manager Tab".
You can delete auxiliary object classes. You also can delete template object classes that have not yet been added to a tab for a user or group. You cannot delete a structural object class. You can only substitute a new structural object class for an existing one. See "Changing the Structural Object Class" for details. When you delete an object class, you should also remove any searchbases that you have configured for that object class. See "Setting the Searchbase" for details.
To delete an auxiliary object class
From the Identity System Console, select Common Configuration, Object Classes.
Click a link for the object class.
The object class Kind must be Auxiliary.
From the View Object Class page, click Delete.
When installing the Identity System, you configure required structural object classes and their attributes. After completing Identity System setup, you may want to add object classes, configure additional attributes, and modify existing attributes. When adding an object class, you can have the Identity System automatically configure attributes in that object class, as described in "Adding Object Classes". Use the Modify Attributes feature to change attributes and to configure additional attributes.
The following sections describe attribute configuration:
|
Note: For Active Directory installations, there is a subset of attributes that are unavailable to schema definition by default. To make these attributes visible to the Identity System for configuration, you must remove their entries from the following three files in the IdentityServer_install_dir/identity/oblix/data/common directory: exclude_attrs_config.xml, exclude_attrs-ad.xml, and ad_exclude_attrs.xml. Restart the Identity Server for your changes to take effect. |
When configuring an object in the Identity System, you select a class attribute, as described in "Selecting a Class Attribute". In addition, you need to decide how the Identity System will display and work with other object attributes. For instance, you need to decide what facts about a person you want the User Manager to display. You also need to decide how you want to display data. For instance, you may want to display lists of printers on the Organization Manager. Or you may want to display a list of preferred travel agents based on a user's geographical location.
You can configure the Identity System to use any attributes stored in your LDAP directory. Having a well-structured set of attributes to work with allows the Identity System to display the data you want to display and to provide fine-grained access controls for your users.
After configuring an attribute, you must perform additional steps to display the attribute on a profile page in the User, Group, or Organization Manager. For more information, see "Configuring Tab Profile Pages and Panels".
After configuring an attribute you must set view and modify privileges to allow users to see the attributes you are displaying. For information about providing users with read and modify privileges, see "Allowing Users to View and Change LDAP Data".
Before you configure attributes, you need to understand the relationships between an attribute's data type, semantic type, and the ability to perform searches. These topics are discussed in the following sections.
When you modify an attribute as described in "About Object Class Attributes", a data type for that attribute is displayed. A data type is the format of the attribute's value. For instance, a name attribute may have a data type of a single text line. Every LDAP attribute has an associated data type. In the Identity System, six data types are supported. Data types have corresponding display types, described in "Attribute Display Types". You cannot configure the data type for a template or LDAP attribute in the System Console. You configure the data type in the .tpl file or the LDAP schema. Supported data types are shown in Table 3-2:
Table 3-2 Supported Data Types
A semantic type is an optional characteristic that governs the behavior of the attribute within an Identity System application. For example, the value of an attribute assigned to the semantic type Photo appears in the header area of a profile page in an Identity System application. You can only assign a semantic type to one attribute. However, an attribute can have more than one semantic type assigned to it. For example, you can assign the Login and DNPrefix semantic types to the cn attribute.
Once a semantic type is assigned, it cannot be assigned to another attribute within a domain unless you disassociate it from the first attribute. For example, only one LDAP attribute can be assigned the semantic type of Password. If you have configured any other schema domain, you could assign the semantic type of Password to only one attribute in that domain. See "Sending Non-LDAP Data to External Applications" for details.
To disassociate a semantic type from an attribute, you must first specify a semantic type of None for the attribute, and then assign a new semantic type to it.
Each semantic type is associated with one or more display types, as described in "Attribute Display Types".
Table 3-3 describes semantic types that are required during Identity System setup:
Table 3-3 Semantic Types
| Semantic Type | Description | Allowed Display Type |
|---|---|---|
|
Required for the person and group structural object classes and for all structural object classes in Organization Manager. Typically assigned to the cn attribute. The cn attribute is required for most schemas. |
Check box, Date, Email address, Multi-line text, Numeric string, Radio button, Selection menu, Single line text |
|
|
Required for the person object class. Specifies the user credentials during login. |
Single line text, Email address |
|
|
Required for password management for the person object class. It is also required for Active Directory. Specifies the user password for password management. Note: If you are using Sun's iPlanet directory, passwords cannot use UTF-8 characters. If the user supplies UTF-8 characters, the iPlanet directory default 7-bit plug-in fails the operation. By default the 7-bit plug-in requires the uid, mail, and user password attribute values to be 7-bit. To resolve this problem, turn off the plug-in or remove the user password attribute from the configuration. |
Password |
|
|
Required for the person and group structural object classes and for all structural object classes in Organization Manager. Specifies the relative distinguished name (RDN) of an object. The RDN is the leftmost part of the distinguished name (DN). The DN prefix is used when creating an object through a workflow. The attribute with this semantic type must be in the initiating step of a workflow. |
Check box, date, email address, multi-line text, numeric string, radio button, selection menu, single line text |
Table 3-4 shows semantic types used in profile header panels. For more information about profile panels, see "Configuring User, Group, and Organization Manager":
Table 3-4 Semantic Types in a Profile Header Panel
Table 3-5 shows semantic types used in the Group Manager:
Table 3-5 Semantic Types Used in the Group Manager
| Semantic Type | Description | Allowed Display Type |
|---|---|---|
|
Specifies the attribute where a group owner is stored. The Identity System uses this information primarily as a role in attribute access and delegated administration. Also, group owners can be notified when a user subscribes or unsubscribes from their groups. |
Object Selector |
|
|
Specifies the attribute storing the dynamic filter that defines the dynamic membership of a group. If you are configuring the Group Manager, you must assign this semantic type to an attribute. The attribute must also belong to the group object class. |
Object Selector |
|
|
Specifies the attribute where static members of a group are stored. If you are using the Group Manager, you must assign this semantic type to an attribute. The attribute must also belong to the group object class. For NetScape installations, this attribute is uniqueMember. For Active Directory, it is Member. |
Object Selector |
The Location Coordinates semantic type is used to track location. It specifies the position of the location GIF image and is used with the obRectangle attribute. It has no allowable display type because it is used internally by the Identity System.
Two semantic types are used for lost password management. The Identity System provides lost password functionality for both the Identity System and the Access System. Once you configure attributes with these semantic types, end users can enter a challenge-and-response phrase that can later be used to recover their lost passwords:
Table 3-6 Semantic Types Used for Lost Password Management
| Semantic Type | Description | Allowed Display Type |
|---|---|---|
|
Displays a challenge phrase when an end user initiates lost password management. The end user must type the correct response phrase. |
Single line text |
|
|
The end user must type the correct response to a challenge phrase when implementing the lost password management feature. |
Password |
Table 3-7 describes other semantic types:
Table 3-7 Other Semantic Types
The display type specifies the appearance of an attribute value, for instance, whether the possible values are True or False or an email address. The display type determines whether the attribute can be used when users conduct a search. Only certain display types such as Date and Multi-Line Text are searchable, as indicated in the following table.
Once you have assigned an attribute to an Identity System application panel as described in "Configuring Tab Profile Pages and Panels", if you want to change the attribute display type or semantic type you must delete the panel, change the attribute display type, and re-create the panel.
Table 3-8 describes the attribute display types:
Table 3-8 Object display types
| Display Type | Description | Configurable Characteristics |
|---|---|---|
|
A place holder. |
N.A. |
|
|
Displays a True or False choice that the user must make. This display type is not searchable. |
N.A. |
|
|
Provides a check box. This display type only supports multiple values, and it requires you to specify a rule or a list. See "Using Rules and Lists" for details. This display type is not searchable. |
Rule (LDAP filter and attribute), List (display name and other features) |
|
|
Allows users to enter month, day, and year. This display type supports single or multiple values. This display type is searchable. |
Data type, data separator |
|
|
Displays a link to an end user's email address. This display type is searchable. |
N.A. |
|
|
Creates a button that launches the Filter Builder. The Filter Builder allows users to design custom LDAP queries. This display type is not searchable. |
Target object class list |
|
|
Allows users to find an image. Some Identity System applications also support JPEGs. This display type is not searchable. |
Photo style, height, width |
|
|
Allows you to specify an external location for the GIF image. This enables you to display the image on a profile page. This display type is searchable. |
Photo style, height, width |
|
|
Creates a link in the associated profile page to the Locations page. This display type is used internally in the Identity System. |
Target object class list |
|
|
Used for binary media files. This attribute must have the binary data type. This display type is not searchable. |
Description, MIME type |
|
|
Two or more lines of text, such as an address. This display type supports single or multiple values. This display type is searchable. |
N.A. |
|
|
Provides a field for specifying a number. This field does not accept non-numeric characters. This display type is searchable. |
N.A. |
|
|
Use the Object Selector display type when you want users to modify an attribute using the Selector. This display type is only valid for attributes of type DN. This display type supports single and multiple values and is not searchable. For more information on the Object Selector display type, see "Search Filters for the Object Selector Display Type". |
List of object classes, LDAP filter |
|
|
Lets users type a password. The password characters appear as asterisks, and the user is prompted to enter the password twice. This display type is not searchable. |
Text size and length |
|
|
Six data entry fields in which a user can specify a postal address. Each field can contain a maximum of 30 characters. This display type supports single and multiple values. |
N.A. |
|
|
Provides a set of radio buttons that allows the user to select one value from the list of radio buttons. This display type requires you to specify a rule or a list. See "Using Rules and Lists" for details. This display type is not searchable. |
Rule (LDAP filter, attribute), list (display name, storage name) |
|
|
Provides a list. This display type supports single or multiple selectable values. This display type requires you to specify a rule or a list. See "Using Rules and Lists" for details. This display type is not searchable. Do not configure DN attributes using the Selection Menu display type. This display type does not support order, which can be important in a DN. For example, if there are two ous in a DN, the order is important. |
Rule (LDAP filter, attribute), list (display name, storage name) |
|
|
Displays information in a single line of text. There is no maximum number of characters for this field. This display type supports either single or multiple values. This display type is searchable. |
N.A. |
|
|
Stores certificate data in the configured attribute rather than on disk. This display type is not searchable. |
N.A. |
|
Note: In the Identity System Console, the display names that appear as values for items in the list of display types (radio button, checkbox, and so on) may be corrupt due to a known limitation with Java Applets and internationalized characters. The browser's JVM displays only those characters that are in the current locale. Internationalized characters are displayed correctly in applets only if you have set the browser to the same locale. |
You view attributes on the Modify Attribute page.
To view the Modify Attribute page from the System Console
From the Identity System landing page, click the link for the Identity System Console.
If you have already logged in, click the Identity System Console tab.
Click the Common Configuration sub-tab, then click Object Classes in the left navigation pane.
Click the link for an object class.
The View Object Class page for the selected class appears.
Click Modify Attributes.
The Modify Attributes page appears.
To view an application-specific Modify Attribute page
From the Identity System landing page, click the link for the Identity System Console.
If you are already logged in, click the Identity System Console tab.
In the System Console, click the User Manager Configuration sub-tab.
You can also click the sub-tab for Group Manager Configuration or Organization Manager Configuration.
In the left navigation pane, click Tabs.
The Configure Tab page appears. The structural object class for that tab is displayed as a link under the heading "Existing Tabs."
Click the link under the Existing Tabs label.
The View Tab page appears.
Click the Modify Attributes button.
The Modify Attributes page appears.
When installing the Identity System, you configure all required attributes for your structural object classes. After installation, you can modify attributes to resolve conflicts among configured attributes and to configure additional attributes.
For Active Directory installations, some attributes are unavailable by default. To make these attributes available for configuration in the Identity System, remove their entries from the following three files in the IdentityServer_install_dir/identity/oblix/data/common directory: exclude_attrs_config.xml, exclude_attrs-ad.xml, and ad_exclude_attrs.xml and restart the Identity Server.
|
Note: In the object class oblixadvancedgroup, the attribute obgroupsubscribenotification has a display type of Check Box and a List sub-type. The list contains two values:
If you want to modify the values for this attribute, note that you can change only the values in the Display Name field. Do not change the value in the Storage field. |
Open the Modify Attributes page as described in "Viewing Attributes".
|
Note: Using the application-specific Tabs function, you can provide a different display name or display type for an attribute on that application-specific Configuration tab only (different than what is configured at the object class level). This will override the information configured for the attribute at the object class level. For details, see "Modifying and Localizing Attributes Displayed on a Panel". |
In the Attribute list, select an attribute you want to modify.
The attribute's data type appears after the list. This is a read-only field.
In the Display Name field, enter a user-friendly display name for this attribute.
The display name appears on an Identity System application page, for instance, the User Manager. For example, for the departmentNumber attribute, you might enter Department Number as the display name.
For template object attributes, the Display Name should indicate the template being used. As noted earlier, users will not be able to see the data values for these attributes. As a result, you should identify these "special case" fields so that users can be advised that it is normal for data not to be shown. For example, in an object template for application ABC, you might want all ABC-related attributes to be identifiable by their display names, such as assistant.person.abc.
The Data Type field displays the attribute's data type, as described in "Attribute Data Types" on page 3-10. This is a read-only field.
You cannot use attributes with binary, distinguished name, or postal address data types as report criteria or in search attributes.
In the Semantic Type list, you can optionally select one or more semantic types.
See "Attribute Semantic Types" for details on semantic types.
In the Attribute Values field, specify whether the attribute can have single or multiple values.
Depending on the attribute, data type, and display type, this option may not be available.
In the Display Type list, select the attribute's display type.
If you select a date attribute for the display type, you must select a date type to indicate how you want the date to appear on the Identity System application profile page. Do not change the date type after you select it because this may display existing data incorrectly.
Several display types allow you to specify a rule or list. See "Using Rules and Lists" for details.
Other display types allow you to specify a photo or text. For more information on these fields, see "Configuring Other Display Types".
The display types of Selection Menu, Radio Buttons, and Check Box require that you specify a rule or a list. For instance, you may assign a data type of string and a display type of radio button to a Title attribute. To display a list of titles on a User Manager profile page, you need to build a list.
A list is a static set of values. A rule is an LDAP filter that queries the directory before building a list. For example, if you create a filter to find every instance of objectClass=dialUpConnection with an attribute of TelephoneNumber, a list of phone numbers is shown in the selection menu.
For more information about LDAP filters, refer to "Search Filters for the Object Selector Display Type"for information. Also, the Internet Engineering Task Force's RFC 2254 defines a string representation of LDAP search filters.
You can define a static list to display on an Identity System application page, or you can define a rule. For instance, you can provide a static list of available printers, or you can construct this list from entries for printers in your directory. When you configure a rule, you create a dynamic list based on entries in your directory. A rule is a directory query based on an attribute that you specify in the rule. The query returns a set of records from the directory. Using the rule, you cause the Identity System to build the list to be displayed on the application page by doing the following:
Querying the directory for a specific object or attribute
Building a list of hits
Selecting one attribute from each directory hit
Building a list showing the values for each attribute
The advantage of a rule over a list is that what is displayed as a result of the rule filter is updated whenever the directory is updated.
Open the Modify Attributes page as described in "Viewing Attributes".
Select an Attribute from the list.
From the Display Type list, select the attribute's display type.
To configure a rule for the attribute, the display type must be Selection Menu, Checkbox, or Radio Buttons.
A Rule button, Add Filter text box, and Attribute field appear.
Select the Rule button.
A rule must be a valid LDAP filter.
In the Add Filter box, type an LDAP filter.
For example:
(objectclass=printer)
Suppose you invoked the Modify Attribute page for an attribute called Printer, with a display name of Printers. The rule shown in this step would be appropriate for displaying a list of printers.
For examples of filters, see "Search Filters for the Object Selector Display Type".
In the Attribute field, type the LDAP name of the attribute that you want to associate with the filter.
In the printer example, you might type PrinterName. This rule causes an LDAP query on the printer object class and builds a list of values taken from the PrinterName attribute of each returned entry.
Continue with "Defining a List".
A list is a static set of values presented to a user.
On the Modify attributes page, click the List button.
List-related Display and Storage fields become active.
In the Display field, type the list item's Display Name.
This is a name that the user sees when this attribute is displayed on an application page, for instance, the User Manager.
In the Storage field, type a storage name for the attribute.
This value is saved in the database. It can be the same as the display name, or it can follow your own database-naming conventions.
When you click Add, if you omit a storage name, the display name is used as the storage name.
If you want to change a storage name, delete the entry in the Storage field, and retype the Display and Storage names.
Click Add.
The information is added to the List field.
Items in the list appear on the Identity System application page in the order they appear on this page. To rearrange items in the list, or to remove an item, use the Move Up, Move Down, and Delete buttons.
You can localize attribute display names to present to Identity System applications to end-users in their native language. See "Configuring Multiple Languages for Oracle Access Manager" for information on managing multiple languages.
In order to localize object class attributes, you must manually enter the attribute display names in the Identity System Console for each language that you installed. After you have localized object class attributes, you can view and modify them in the Identity System Console.
The process for localization is the same for LDAP and template objects.
Table 3-9 lists the attributes that can be localized for each object class.
Table 3-9 Items You Can Localize
| Items | What You Can Translate |
|---|---|
|
Object classes configured for tabs |
NameDescriptionMouseover |
|
Object classes configured for panels |
NameDescriptionMouseover |
|
Attributes |
Display name |
|
Attributes with a media display type |
Display name |
|
Attributes with a choice display type |
Display name |
|
Workflow definitions |
Workflow name Note: You specify a translation for your workflow name when you create or modify a workflow definition, as described in "Chaining Identity Functions Into Workflows". |
To create, view, or modify localized attribute display names
From the Identity System Console, click Common Configuration.
The Common Configuration page appears.
Click the Object Classes link in the left navigation pane.
Click the link for the object class you want to modify.
The View Object Class page appears.
Click Translate.
|
Note: The Translate button appears only if more than one language has been installed. |
The Summary of Attribute Display Names page appears. All language-specific attribute display names appear on this page. Display names that have not been configured are marked as Not Configured and appear in blue text.
Click Modify to enter or modify a display name.
The Configure Attribute Display Names page appears. This page lists links for installed languages and the localized display names for attributes. Display names that have not been configured appear in blue text and are not flush left.
Click the language for which you want to modify attribute display names.
Enter display names in the Display Name fields.
Click Save to save your changes (or Cancel to exit the page without saving your changes).
|
Note: If a display name has not been configured for a language, a localized "Not Configured" message is displayed in the display name field. |
The object selector display type associates a Selector with the LDAP attribute assigned to this display type. (This does not apply to template attributes.) Users invoke the Selector to search for users or groups. The Selector is available when you view, create, or modify a profile or a workflow.
Use the object selector display type to create a search filter for the Selector. See "The Selector" on page 1-10 for details. You can write search filters to help people conduct a Selector search during the following operations:
Create profile
Modify profile
Modify workflow
Delete workflow
These filters do not apply to the Query Builder.
When a user invokes the Selector, they perform a directory search. When you create a filter for the Selector, the filter is used in an "and" relationship with the search criteria that the user provides.
A filter can be static. For example, you can restrict Selector searches so that the search results only contain people with an organizational unit of Corporate in their directory profile.
A filter can also be dynamic. For example, you can restrict a Selector search to return only people whose organizational unit matches that of the person being displayed on the Modify Profile page where the search was invoked. When using a dynamic filter for a Modify Profile page, the Selector search is based on the directory profile of the person being displayed. In the case of creating profiles, a dynamic filter produces Selector search results based on the login profile of the person performing the task.
A filter helps the user narrow down a search. A filter narrows down the place in the directory tree where a search may be conducted.
From the Identity System Console, click Common Configuration, then click Object Classes.
Click the link for the object class for which you want to create a filter.
For example, to develop a search filter for a sales person, you might navigate to the Modify Attribute page for the Person object class.
Click Modify Attributes.
On the Modify Attribute page, in the Attribute list, choose the attribute for which you want to define a Selector search.
You must choose a DN attribute. For instance, if you want Selector searches for sales people, you might select a DN attribute called salesPersonDN.
On the Display Type list, select Object Selector.
If the attribute you chose in the previous step is a DN attribute, the Object Selector option appears in the list. The Target Object Class list and the Add Filter input box are also displayed.
In the Target Object Class list, select an object class to be used as the primary key in the search filter.
The target object class determines what is displayed on the Selector search page. For instance, if you want the Selector to help users find sales people, you might use Person as the target object class. If you select more than one Target Object Class on the Modify Attribute page, the Selector application will contain a tab for each object class.
Type a valid LDAP filter in the Add Filter input box.
The filter determines what is displayed on the Selector search results. For examples of the types of LDAP filters you can write, see "Static LDAP Search Filters" and "Examples of Dynamic LDAP Search Filters".
Note that your filter can use only attributes that are contained in the definition of the target object class.
|
Note: the Identity System treats white spaces literally. Be aware of extra trailing spaces or carriage returns in your filters. |
Save your changes.
This creates a filter that is used in an And relationship with any other criteria the user specifies on the Selector search.
If you select more than one target object class on the Modify Attribute page, the Selector application will contain a tab for each object class. Your search filter will need to contain an Or operator ( | ) and separate selection criteria for each object class you selected. An example of this type of search filter is provided in "Static Searches Using Multiple Target Object Classes".
This section covers important topics related to rules and filters:
Creating basic static filters
Creating dynamic filters using substitution syntax
Use of wild cards in a search
Proper use of the Not operator when writing a filter
When you implement a static search filter, all search results must match a fixed value. For example, you can restrict a search to return only people whose directory profiles show an organizational unit of Sales.
As an example of a simple static filter, suppose you want to provide Selector searches for the seeAlso attribute. The filter will return search results that show only people whose directory profiles contain a businessCategory value of dealership.
Open the Modify Attributes page as described in "Viewing Attributes".
Navigate to the Modify Attribute page for the object type that triggers this search filter (for instance, Person).
Select the seeAlso attribute in the Attribute list.
From the Display Type list, select Object Selector.
In the Target Object Class, select the object class that will be the primary key for the filter (for instance, Person).
In the Filter text box, input the following:
(businessCategory=dealership)
As an example of a static filter that uses wild cards, suppose you want only people with the word Manager in their title to be returned on a search using the Selector. You can create a filter that searches for the string Manager.
To create a static search filter using a wild card
Navigate to the Modify Attribute page for the object class containing the DN attribute to be associated with the Selector (for instance, the Person object class).
In the Attribute list, select the DN attribute (for instance, the Manager attribute).
On the Display Type list, select Object Selector.
In the Filter text box, input the following:
(attribute=*value*)
For example:
(title=*manager*)
You can build a static filter that searches for more than one target object class. For example, suppose you want to build a filter for the uniqueMember attribute so that a search using the Selector returns one of two items:
On a search of people, the search results show only full time employees
On a search of groups, the search results show only mail groups
In this example, to create an LDAP filter for both characteristics, you need to select people with employee=fulltime in their directory profiles, and you need to select groups with the object class of MailGroup in their directory profile. Each attribute in the filter must be associated with an appropriate object class. Finally, you need to join the two searches with an Or operator ( | ), as follows:
(|(&(objectclass=inetOrgPerson)(employeeType=FullTime))
(&(objectclass=groupOfUniqueNames) (objectclass=MailGroup)))
You can enter substitution syntax using the Advanced button of the Query Builder. See "Writing LDAP Filters Using Query Builder" for details.
When using substitution syntax, the variable attribute value for the source DN (the person logged into the application) is substituted in the rule and evaluated against the target DN (the entry you are trying to view or modify).
Substitution syntax allows a rule to be evaluated dynamically, according to the person executing a task. The syntax is as follows:
attribute=$attribute$
For example:
(ou=$ou$)
This rule filters all those in the same organizational unit as the person logged into the application.
You can use operators such as And and Or in a filter. For example:
(|(ou=$ou$)(ou=people))
|
Note: For the selected searchbase, users can search only for entries from the same ou as their own. Additionally, users from ou=people can search for entries within the selected searchbase. |
In addition to specifying a conventional LDAP search filter, you can use the Identity System's filter substitution syntax to create a dynamic filter. A dynamic filter allows a search to return results that are based on a user profile. For instance, suppose you create a search filter for the orgPerson attribute that contains the following:
(ou=$ou$)
Using this search filter, if you conduct a Selector search on a Modify Profile page for a person, your search results contain only people whose directory profiles match the organizational unit in the profile of the person you are modifying. For example, if you invoke the Modify Profile page for John Smith and invoke the Selector to choose John Smith's manager, the search results show only people in John Smith's organizational unit.
When you use filter substitution, the profile of the search target is substituted. In the example (ou=$ou$), the value of John Smith's ou is substituted. If a target is not present, for instance, in the Create Workflow function, the search filter substitutes the value from the login profile of the person creating the workflow.
For example, suppose you are creating a workflow for a group named Corporate whose organizational unit is not yet defined in the directory server. In this case, the Identity System uses the ou value of the logged-in participant who is creating the group. The logged-in participant's ou value carries over in the workflow until you commit this group in the directory server. At that point, the ou value in the dynamic filter (ou=$ou$) changes to the group's ou value.
As another example, suppose you want people who have the Secretary attribute in their directory profile to receive search results containing only people who have the same manager that they do. From the Configure Attribute page for the Secretary attribute, you would specify the following:
(manager=$manager$)
You can use wild cards in a dynamic filter. For example, suppose you want to supply a contactPerson attribute in an organizationalUnit object. The contactPerson attribute should return people in same Zip code as the organizationalUnit object. If the organizationalUnit profile contains an attribute called zipCode, and the Zip code is specified at the end of a postalAddress directory attribute, you would specify the following in the filter:
(postalAddress=*$zipCode$)
Finally, you can supply multiple values in a dynamic search filter. For example, suppose you want the seeAlso attribute for business objects to select the businessCatagory of dealership, and specifically, dealerships in the same state as the search target. You would specify the following filter for the seeAlso attribute:
(&(businessCategory=dealership)(state=$state$))
You use And (&) and Not (!) operators when constructing a filter. For example:
Example of an And Operation--(&(sn=white)(objectclass=personOC))
Example of a Not Operation--(&(!(sn=white))(objectclass=personOC))
In the example of the Not filter in the previous example, you might expect the following filter to be valid:
(!(sn=white))
However, when specifying a Not operation, you need to embed it within an And and specify the person object class. A filter such as (!(sn=white)) is not allowed because a search of this type would be conducted on the entire domain before targeting the reduced domain set specified on the filter. This is costly steps in terms of performance. The optimized algorithm that the Identity System uses causes the search to be conducted on the reduced domain set. The proper use of the Not operation is as follows:
(&(!(sn=white))(objectclass=personOC))
The optimized algorithm causes the filter (!(sn=white)) to not give the expected result.
There are configuration options for the other display types.
To configure a GIF image display type
On the Modify Attributes page, select the Attribute Photo.
Using the buttons under the Display Type list, select the photo style:
True Size—Select True Size to display the GIF in its actual size.
Fixed Size—Select Fixed Size to specify the height and width for the image.
When you select a text-based display type, you can use XSL style sheets to configure the defaults for the text. This is also true for setting columns and rows. See the Oracle Access Manager Customization Guide for details.
When you select an attribute with a display type that uses target object classes, you specify one or more objects for association with this attribute. This display type supports single or multiple values.
If you want to set a target object class, select one or more required object classes in the Target Object Class list.
If you want to set the MIME type, select the kind of media file you want to attach from the MIME Type list.
Derived attributes are virtual LDAP object class attributes. Derived attributes are generated by comparing the contents of one object class's attribute with an attribute in the same or a different object class. The main purpose of a derived attribute is reverse lookup.
For example, someone's profile may contain the name of their administrative assistant, but administrative assistant profiles rarely contain the names of all of the people they administer. A derived attribute allows the administrative assistant's profile to refer back to all of the people who have the administrative assistant attribute in their profile. In this example, the administrative assistant's Self attribute value is compared with the AdminAssistant attribute value of the other people in the organization. Similarly, a groupOfUniqueNames object may contain a uniqueMember attribute with links to members of the group. But an object that contains data for a person might not link back to the groupOfUniqueNames object. The derived attribute feature would allow group members to refer back to the group they belong to.
To create derived attributes, you specify two attributes whose values are to be compared. All matches are added to the derived attribute.
Use derived attributes to provide information in profiles that otherwise would require an LDAP filter, search, or report.
Attributes associated with template objects cannot be configured as derived attributes.
Suppose the administrative assistants of your organization have asked to view all the managers they support in the User Profiles in User Manager. To do this, you can create a derived attribute that takes the attribute of each administrative assistant and compares it with the value for Secretary in everyone else's profile. When an administrative assistant views user identities in User Manager, only people who match the derived attribute are displayed.
Here is a summary of the steps required to create a derived attribute.
Task overview: Configuring a derived attribute
Add a derived attribute in the Identity System Console, giving your new attribute a descriptive display name, such as My Direct Reports.
Specify Self as the Match Attribute.
This indicates that the administrative assistants' DNs are the search criteria.
Because you are looking for your administrative assistant's direct reports, specify Person object class as the searched object class.
Be sure you are looking for people and not groups or other kinds of objects.
Specify secretary as the Lookup Attribute.
You are searching the user identities for users with matching values in the secretary attribute.
Save your new attribute and associate it with the Employee tab in User Manager.
Now, whenever an administrative assistant views the User Profile page, the Identity System takes the value of the Self attribute (DN) and compares it against the values of everyone's secretary attribute. Wherever there is a match, the Identity System lists that manager's name in the administrative assistant's My Direct Reports section of the User Profile page.
|
Note: The attributes displayed in the profile are determined by the selected object class's Object Class Attribute. To change this value, you must modify the object class. |
To configure a derived attribute
From the Identity System Console, click Common Configuration.
The Common Configuration page appears.
Click the Object Classes link in the left navigation pane and click the named link of an object class.
The View Object Class page appears.
Click the link for the object class whose derived attribute you want to modify.
Click Modify Derived Attributes, then click Add.
The Create Derived Attribute page appears.
In the Attribute Name field, specify a name for your new derived attribute.
|
Note: Since a derived attribute is a virtual attribute, the attribute name must not exist in the schema. |
In the Display Name field, type the name of the derived attribute as it will appear in the Identity System pages.
In the Match Attribute field, select the attribute in the current object class whose values you want to match.
In the Object Class field, select the object class you want to search.
In the Lookup Attribute field, select an attribute in the specified object class whose values you want to compare against.
Click Save to save your changes (or Cancel to exit without saving).
Before you can use your derived attribute, you must assign it to an Identity System application tab.
To add a derived attribute to an application tab
From the Identity System Console, click User Manager Configuration (or Group Manager Configuration or Organization Manager Configuration).
Click Tabs.
Under the Existing Tabs label, click the link for the application tab that you want to modify, then click View Object Profile.
The page that appears depends on which application you are using. In User Manager, the Configure User Profile page appears. In Group Manager, the Configure Group Profile page appears. In Organization Manager, the Configure Object page appears.
If you are working with User Manager Configuration or Organization Manager Configuration, click Configure Panels.
For the Group Manager, the link name is Configure Group Profiles Panel.
The Configure Panels (or Configure Group Profile Panels) page displays the panels currently configured to appear in a User Manager profile.
Click the name of the panel to which you want to add the derived attribute.
The View Panel page appears.
Click Modify.
The Modify Panel page appears.
In the Attributes menu, select the derived attribute you want to add.
In the associated text box, type the name as you want it to appear in the Identity System pages.
If you need additional Attribute fields, click Add.
Click Save to save your changes (or Cancel to exit without saving).
You can assign Read permissions to a derived attribute. See "Setting and Modifying LDAP Attribute Permissions" for information about assigning rights to an attribute.
When you configure attributes as described in this chapter, these attributes are available to any Identity System application. In other words, the attribute can be used within the User Manager, Group Manager, or Organization Manager.
However, you may want to make only certain attributes available to certain applications. For example, you may want an attribute for a person's address to only be available to the User Manager application. If this is the case, you can access the object and attribute configuration functionality described in the preceding sections from the relevant application. In the case of the Organization Manager, you can configure objects and attributes for individual tabs.
For more information on configuring the User, Group, and Organization Managers, see "Configuring User, Group, and Organization Manager".
