Any identity vault object that you want users to search, display, or edit in the Identity Manager user application must be defined as an entity in the directory abstraction layer. For example, to use the inetOrgPerson identity vault object in the user application, you must create an entity definition for it.
Follow these steps to add entities to the directory abstraction layer:
Step |
Task |
For more information |
---|---|---|
1 |
Decide what identity vault objects you want to use in the user application |
|
2 |
Use the directory abstraction layer editor to define the identity vault objects in the directory abstraction layer |
|
3 |
Use the Provisioning View to validate the data definitions |
Section 4.8, Importing, validating, and deploying directory abstraction layer definitions |
4 |
Deploy the definitions to the identity vault |
|
5 |
Update the application server’s cache to include the new abstraction layer definitions |
|
6 |
Test the Identity Manager user application to ensure that your changes display properly |
To model your identity vault data in the directory abstraction layer, you’ll need to know:
The parts of the directory you want to make available to the Identity Manager user application.
For example, the list of objects that the user can search and display. Check this list against the base set of abstraction layer definitions to determine what you need to add.
The structure of the schema including custom extensions and auxiliary classes
The structure of the data including:
What is required and what is optional
Validation rules
Relationships between objects (DN references)
How attributes are defined (for example, an attribute that represents a phone number might be multi-valued for home, office, and cell phone numbers)
Who will see the data
Is this a public or private site?
Once you have this information, you can use it to map your identity vault objects to abstraction layer entities.
NOTE:The eDirectory ACLs are applicable to all abstraction layer objects. Effective rights on objects and attributes are based on the authenticated user established at application login.
Depending on what you want to expose in the user application, you’ll be defining two kinds of entities:
Entities that are mapped from schema. These entities represent objects that exist in the identity vault that are directly exposed to users in the user application. When defining this type of entity, you’ll expose all of the attributes that you’ll want your users to work with. Examples of this entity type include: User, Group, and Task Group.You can also create more than one entity definition for the same object if you want to expose different sets of attributes to different kinds of users. For more information, see Creating multiple entity definitions for a single object.
Entities that represent LDAP relationships. This type of entity is known as a DNLookup and it is used by the user application to:
Populate a list with the results of a DN search among related entities
Maintain referential integrity across DN referenced attributes during updates and deletes
Entities that support DNLookups are used by the Org Chart portlet to determine relationships and are also used by the Search, Create, and Detail portlets to provide pop-up selection lists and DN contexts. Examples of this kind of entity include: Manager Lookup, Task Manager Lookup, and User Lookup. For more information, see Using DNLookup control types.
You can create more than one entity definition that represents the same identity vault object, but provides a different view of the data. Within the entity definitions you could:
Define different attributes for each entity definition
OR
Define the same attributes, but specify different access properties that control how the attributes are searched, viewed, edited or hidden
NOTE:The entity definitions can optionally include a filter to hide certain entities from the result set.
You could then use these different entity definitions in different parts of the user interface. For example, suppose that you wanted to create a directory of employees; one for a public site and one for an internal site. On the public site you wanted to supply first and last names and a phone number, but on the internal site, you wanted to list additional information like title, managers, and so on. Here’s how you could accomplish this:
Create two entity definitions (with different keys).
Both entity definitions expose the same identity vault object, but one entity definition key is public-staff-information, and the other is internal-staff-information.
Within each entity definition define a different set of attributes: one for public-staff-information, the other for internal-staff-information.
Use the Portal Administration tab of the Identity Manager user application to create a portlet instance for the public page, and another one for the internal page.
For more information about creating portlet instances, see Section 9.0, Portlet Administration.
When you have determined the entities and attributes that you want to expose, you can start adding them to the directory abstraction layer using the editor. You’ll follow a set of steps like this:
With the Identity Manager project open, select the Identity Vault, right-mouse and select Live Operations>Import Schema.
Choose Import from eDirectory and provide the specifications for the eDirectory host.
Click Next.
Select the classes and attributes that you want to import, and click Finish.
You can add an entity via the Add Entity Wizard (described next) or by clicking the Add Entity button from the editor’s toolbar.
NOTE:When using the Add Entity button, you are prompted to select the object class of the entity you want to create. The editor automatically adds the required attributes to the entity. You can then use the Add Attribute dialog to complete the entity definition.
Launch the Add Entity Wizard in one of these ways:
From the Provisioning View:
Select the Entities node, right-mouse click and choose New.
Select File>New>Provisioning. Choose Directory Abstraction Layer Entity. Click Next.
From the directory abstraction layer editor:
Select the Entities node, right-mouse click and choose New Entity-Attributes Wizard.
The New Entity dialog displays.
NOTE:If launched from the File menu, the dialog contains fields not displayed when launched in either of the other ways. It is shown below.
Complete the panel as follows:
Click Next. The New Entity dialog displays:
Choose the Object Class for the entity that you want to create, then select the attributes that you want from the Available Attributes list
HINT:If the object class of the entity that you want to create is not shown in the Available Object Classes list you might need to update the designer’s local schema file. Follow the steps described in To update the list of available schema elements:.
Click Finish.
The property sheet is displayed for editing.
For more information, see Entity property reference.
NOTE:To make the attribute available to the user application, you must deploy the entity that contains the attribute.
Select an entity.
Add an attribute by:
Right-clicking and selecting Add Attribute.
or
Clicking the Add Attribute icon.
You are prompted as follows:
Choose the attribute from the Available Attributes for Entity Class list and add it to the Selected Attributes for Entity list.
HINT:If the attribute that you want to create is not shown in the Available Attributes from Entity Class list you might need to update the designer’s local schema file. Follow the steps described in To update the list of available schema elements:.
Click OK.
The property sheet is displayed for editing.
For more information, see Attribute property reference.
NOTE:To make the attribute available to the user application, you must deploy it.
You can set the following kinds of properties on entities:
The Access Properties control how the user application interacts with the entity. They include:
The Required entity properties are:
The entity Search properties are:
Property name |
Description |
---|---|
Search container |
The distinguished name of the LDAP node or container where searching starts (the search root). For example: ou=sample,o=ourOrg You can browse the identity vault to select the container, or you can use one of the predefined parameters described in Using predefined parameters. |
Search scope |
Specifies where the search occurs in relation to the search root. Values are: <Default>—This search scope is the same as selecting Containers and subcontainers. Container—Search occurs in the search root DN and all entries at the search root level. Container and subcontainers—Search occurs in the search root DN and all subcontainers. This is the same as selecting <Default>. Object—Limits the search to the object specified. This search is used to verify the existence of the specified object. |
Search Time Limit [ms] |
Specify a value in milliseconds or specify 0 for no time limit. |
Max Search Entries |
Specify the maximum number of search result entries you want returned for a search. Specify 0 if you want to use the runtime setting. Recommendations: Set between 100 and 200 for greatest efficiency Do not set over 1000 |
The entity Create and Edit Properties are:
Property name |
Definition |
---|---|
Create Container |
The name of the container where a new entity of this type is created. You can browse the identity vault to select the container, or you can use one of the predefined parameters described in Using predefined parameters. If this value is not specified, then the Create portlet will prompt the user to specify a container for the new object. The portlet will use the search-root specified in the entity definition as the base and allow the user to drill down from there. If there is no search-root specified in the entity definition then it will use the root DN specified during the user application installation. |
Naming Attribute |
The naming attribute of the entity (the Relative Distinguished Name (RDN)). This value is only necessary for entities where the access parameter Create is selected. |
Alternate Edit Entity |
The attributes of the Edit Entity are displayed in the edit mode of the Detail portlet. Choose an entity from the dropdown or <None> if this entity is not displayed by the Detail portlet. |
The Password Management Properties are:
The directory abstraction layer editor allows you to use predefined parameters for certain values. The parameters are:
You can set the following kinds of properties on attributes:
The attribute access properties are:
Name |
Description |
---|---|
Data Type |
Choose a data type from the following list:
|
Format Type |
Used by the user application to format data. Format types include:
The Format Types are dependent on the data type. For example, a Time data type can only be associated with Date and DateTime formats. |
Control Type |
Types include: DNLookup—Defines that this attribute contains a DN reference. Use when you want to:
The user application use this information to generate special user interface elements, and to perform optimized searches based on the DNLookup definition. For more information, see Using DNLookup control types |
Global List—Display this attribute as a dropdown list whose contents are defined in a file outside of this attribute definition. For more information, see Section 4.4, Working with lists. |
|
Local List—Display this attribute as a dropdown list whose contents are defined with this attribute. To define a local list:
|
|
Range—Use the Range control type with Integer data types to restrict user input to a sequential range of values. You’ll supply the range’s start and end values. |
When you define a control type as a DNLookup, it means that:
Users can select from a list of possible values when searching on this attribute.
When this attribute is created, populated, or deleted an attribute on a related entity will be updated appropriately depending on the user action (create, delete, update) to maintain referential integrity.
The installed user application contains entity definitions for Users and Groups. The Users entity definition contains an attribute called Group which is defined as a DNLookup control type. This enables any identity portlet to provide a selection list of groups for a particular user. For example, a user chooses to do a Directory Search. They want to find a user in a group, but they do not know the group name. They would select User as the object to search for and include Group as a search criteria as shown here:
Because Group is defined as a DNLookup control type for the User entity, the Lookup icon displays. If the user selects it, then a list of possible groups displays:
The user can select a group from the list.
DNLookups for updates and synchronization are important because LDAP allows group relationships to map in both directions. For example, your data might be set up so that:
User object contains a group attribute. The group attribute:
Is multi-valued
Lists all of the groups to which a user belongs
Group object contains a user attribute. The user attribute:
Is multi-valued
Lists all of the users that belong to the group
This means that you can have an attribute on the user object that shows all the groups a user belongs to, and on the Group object you have a DN attribute that includes all the members of that group.
When the user requests an update, the user application must honor the relationships and ensure that the target and source attributes are synchronized. In the DNLookup, you’ll specify both attributes that must be synchronized. You can use this technique to provide synchronization between any objects that are related not just group structural objects. You create this kind of DNLookup control type by specifying the advanced DNLookup properties described in the DNLookup Relational Integrity properties reference.
The DNLookup Display properties are:
DNLookup Relational Integrity properties—These properties are used for synchronizing data between two objects such as groups and group members.