| 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 User, Group, and Organization Manager are Identity System applications that enable users to view and modify information about themselves, other people, groups, inventory, and any other item that you, the administrator, choose to make available. As explained in the chapter, you can apply business logic to actions performed in the Identity System applications, so that, for example, review and approval must be performed before information about a user can be modified.
With the Identity System's object template functionality, you can extend an Identity workflow so that information that is added, deleted, or changed is propagated to other applications. With templates non-LDAP schema can be managed in the Identity System, allowing for non-LDAP data to be made available to workflows and to the Identity Event API.
This chapter covers the following topics:
The User Manager, Group Manager, and Organization Manager applications rely on information in an LDAP directory or in an object template:
LDAP Directory--You configure the information in the directory to display data on profile pages and to enable configuration of workflows that manipulate data about users, groups, and objects. The LDAP directory is the authoritative data source for the Identity System.
Object Template--You can manually configure information in an object template to propagate data that is entered during an Identity workflow step to different target data sources. For example, you can configure an Add or Modify User workflow that uses non-LDAP data and makes this available to the Identity Event API (see Oracle Access Manager Developer Guide for details).
For sending non-LDAP data to a back-end system, the process is as follows:
Task overview: Configuring non-LDAP data for a back-end application
Configure an object template, as described in "Object Template Configuration"
The template should contain objects and attributes that can be understood by the back-end application.
Store this file in:
IdentityServer_install_dir\oblix\config\template\xxx.tpl
where IdentityServer_install_dir is the directory where the Identity System is installed and xxx is the name of the .tpl file.
Configure the template objects and attributes in the Identity System Console, as described in "Making Schema Data Available to the Identity System" and note the following:
Users can only specify values for template attributes in the context of a workflow step.
Template attributes are not searchable in the Identity System.
You cannot set View or Modify permissions for template attributes.
You configure access control for template attributes by defining workflow step participants. Only individuals who are step participants have access to these attributes.
Template attributes cannot be configured as derived attributes.
Associate one or more template attributes with panels on a tab in an Identity System application, for example, the User Manager, as described in "Configuring User, Group, and Organization Manager".
Create a workflow and associate the template attribute with one or more workflow steps, as described in this chapter and "Chaining Identity Functions Into Workflows".
The attribute display name appears on the profile page associated with the workflow. However, the attribute value is not shown. This is because the data flow is only one-way from the Identity System to the target application. (In a future release, the data flow will be two-way, which will permit the display of these attribute values.) See "About Template Object Data and Workflows" for details.
Ensure that the workflow has separate enable, commit, and other steps to write the data to each schema that is used in the workflow, as described in "Configuring User, Group, and Organization Manager".
Configure an external action using the Identity Event API and IdentityXML to send the data in the object template to the back-end application, as described in the Oracle Access Manager Developer Guide.
The rest of this chapter discusses how object templates work and how to configure an object template.
The Identity System provides a generic object template schema file, located in:
Identity_install_dir\oblix\config\template\
This is the required location for this file and for any other object template file that you configure.
Template objects created in this file are similar to LDAP objects. The primary difference is that you use LDAP objects and attributes to display data on user profile pages and to configure workflows, whereas template objects are only used in workflows.
You configure a workflow that contains one or more steps that perform actions on the template attributes. When a user invokes the workflow, the Identity System formats the data entered during the relevant step according to the requirements of the object template schema.
The workflow temporarily stores the template attribute values in the step instance. Once the commit step is performed, the data is written to the target back-end system. The data flow is one-way, so that the Identity System does not continue to store this data once it has been written to the back-end system.
Finally, you must create an Identity Event plug-in to send object template data to the target back-end system.
As described in the previous discussion, you can configure a workflow step that uses template attributes to send non-LDAP data to back-end applications. Attribute values that the user enters as part of a workflow step, once committed, cannot be displayed on a profile page. This is because the Identity System sends data to, but does not retrieve the data from, the target application.
When you configure a workflow that uses an object template, you may want to configure commit steps that write both object template data and LDAP data. This would permit you to use your directory to display the LDAP attribute value on a profile page, and to use the template attribute value to send the data to the back-end application.
Since the flow of data from the Identity System to the back-end application is one-way, the user will not be able to verify the data in the Identity System. The user will need to view the target application or its logs to view the data created in the application from the workflow.
If there is an error writing the data to the back-end system, an Identity Event API plug-in can send a message back to the Identity System user.
|
Note: You cannot commit data for all data sources in one workflow step. You must configure one commit step for each domain. |
An object template file contains schema-like definitions for objects and attributes in XML format. The objects and attributes that you configure in an object template file correspond to values that can be understood by a back-end application to which you want to write data.
All object template files must reside in:
Identity_install_dir/oblix/config/template
where Identity_install_dir is the directory where the Identity System is installed. The file extension for any object template is .tpl.
The Identity Server reads the template file upon startup. If your installation uses multiple servers, you must copy the same template files to each server.
You can define multiple template object classes in a single file or in multiple files. If you create multiple files within the same domain, be aware that the Identity System enforces uniqueness of attributes and classes across files. If an attribute or a class already exists within a domain, the template file is not registered when the Identity Server starts up, and the objects cannot be shown in the System Console.
Similarly, the Identity Server cannot register the template file if it contains any syntax error. Instead, a log entry is generated.
The template file begins with a schema domain statement. The schema domain resolves ambiguity between object classes that have the same names but are used by different data sources, for example, the user object in LDAP and the user object in a back-end application.
The following is an example of a schema domain statement:
ObTemplateDefinition domain="exchange" version="1.0"/>
At startup time, the Identity Server reads the domain statement. For display purposes, template objects and attributes are shown in the Identity System Console in the following format:
attribute.class.domain
where the domain name is taken from the domain statement in the .tpl file.
Note that all domain statements must be unique. If the Identity System detects a non-unique domain, it fails to read the entire .tpl file. Note that the following domain names are reserved and cannot be used in your .tpl file:
MIIS
LDAP
The object template file enables you to define arbitrary name/value pairs. These name/value pairs must match those understood by the target application.
The template definition file is in XML format. The following is an example:
<?xml version="1.0" encoding="iso-8859-1"?>
<ObTemplateDefinition domain="ABC_APPLICATION" version=1.0">
<!-- ObAttributeDefinition -->
<ObAttributeDefinition name="cn" syntax="OB_CIS" maxlen="20"/>
</ObAttributeDefinition>
<ObAttributeDefinition name="sn" syntax="OB_CIS" maxlen="20"/>
<ObAttributeDefinition name="mail" syntax="OB_CIS" maxlen="20"/>
<ObAttributeDefinition name="phone" syntax="OB_CIS" maxlen="20"/>
<!-- ObClassDefinition -->
<ObClassDefinition name="User">
<ObAttributeReference name="cn" required="true">
</ObAttributeReference>
<ObAttributeReference name="sn" required="false">
</ObAttributeReference>
<ObAttributeReference name="mail" required="false">
</ObAttributeReference>
<ObAttributeReference name="phone" required="false">
</ObAttributeReference>
</ObClassDefinition>
<ObClassDefinition name="Group">
<ObAttributeReference name="cn" required="true"/>
<OBAttributeReference name="sn" required="false"/>
<ObAttributeReference name="uniqueMember" required="false"/>
</ObClassDefinition>
</ObTemplateDefinition>
Objects and attributes defined in the object template file appear as follows in the Identity System:
Each object that you define in the .tpl file becomes selectable from the page displayed when you select the following from the Identity System Console:
Common Configuration, Configure Object Class, Add.
The name of the object class as displayed in the Identity System Console is in the format class.domain. The class is taken from the definition that you provide in the .tpl file.
Each attribute that you associate with an object in the .tpl file becomes selectable from the page displayed when you select Common Configuration, Configure Object Class, object class link, Modify Attributes.
The name of the attribute as displayed in the Identity System Console is in the format attribute.class.domain. The attribute name is taken from the definition that you provide in the .tpl file.
In each attribute statement, the syntax element determines the attribute data type that is displayed in Common Configuration, Configure Object Class, object class link, Modify Attributes.
You cannot choose the data type for a template object attribute from the Identity System Console. You must configure the data type in the syntax element of the attribute definition.
Whether this attribute is single- or multi-valued, as seen in Common Configuration, Configure Object Class, object class link, Modify Attributes, is determined by the attribute definition in the .tpl file.
Other characteristics of the attribute, such as the display name and semantic type, are configured from the Identity System Console.
The Identity System enforces the use of only one semantic type for each domain. For example, you can only assign the Login and Password semantic types once each in a domain.
Unlike LDAP attributes, the attributes you configure in the .tpl file are not searchable and cannot be configured as derived attributes.
The elements of the object template file are as follows.
The object template file begins with a list of attribute definitions. These attributes are referenced in the object definitions later in the file:
Table 6-1 Elements of ObAttributeDefinition
| Element Name | Description |
|---|---|
|
name |
Name of the attribute. This corresponds to the attribute name displayed in the Identity System Console. This parameter is required. Length: 32 (max.) Format: [(a-z)|(A-Z)][(a-z)|(A-Z)|(0-9)] |
|
syntax |
This is the attribute syntax. It corresponds to the attribute Data Type in the Identity System Console. This parameter is required. Format:
|
|
cardinality |
The cardinality may be single or multi-valued. This corresponds to an attribute value of single or multi in the Identity System Console. If you set this value to multi, you can re-set it to single in the Identity System Console. However, if you set it to single in the .tpl file, you cannot reset it in the System Console. This parameter is optional. Default: multi unless specified otherwise. Format: [single|multi] |
|
maxlen |
The maximum data length for the attribute value. This parameter is optional. Default: -1 unless specified otherwise. This setting indicates that no maximum length is enforced. Format: -1 or 1 - n where n is an integer that represents a reasonable maximum length. |
Examples:
<ObAttributeDefinition name="c" syntax="OB_CIS" cardinality="single" /> <ObAttributeDefinition name="cn" syntax="OB_CIS" cardinality="single" />
In the .tpl file, a list of object classes occurs after the list of attribute definitions. Each object class contains an ObClassDefinition statement, followed by a list of ObAttributeReference statements.
Table 6-2 Elements of ObClassDefinition
| Element Name | Description |
|---|---|
|
name |
Name of the class. This must be a unique name within the domain. This parameter is required. Length: 32 (max.) Format: [(a-z)|(A-Z)][(a-z)|(A-Z)|(0-9)] |
Examples:
<ObClassDefinition name="User"> <ObClassDefinition name="Group">
You associate an attribute with an object by including the attribute in an AttributeReference statement in the object class definition in the .tpl file. Each ObAttributeReference statement must refer to an attribute defined in an ObAttributeDefinition statement:
Table 6-3 Associations Between Attributes and Objects
| Element name | Description |
|---|---|
|
name |
Name of the template attribute. This parameter is required. The attribute reference must be unique within the object class. The `name' must be the name of an existing attribute definition (ObAttributeDefinition) in this domain. Length: 32 (max.) Format: [(a-z)|(A-Z)][(a-z)|(A-Z)|(0-9)] |
|
required |
Specifies whether the attribute is required or optional in the context of the class definition. This parameter is optional. Default: `false'. Format: [`true'|'false'] |
Examples:
<ObAttributeReference name="cn" required="true"> <ObAttributeReference name="mail" required="false">
The following is an example of an object template file:
<?xml version="1.0" encoding="iso-8859-1"?> <ObTemplateDefinition domain="myapplication" xmlns:dsml="http://www.dsml.org/DSML" xmlns:oblix="http://www.oblix.com/"> <ObAttributeDefinition name="c" syntax="OB_CIS" cardinality="single" /> <ObAttributeDefinition name="cn" syntax="OB_CIS" cardinality="single" /> <ObAttributeDefinition name="department" syntax="OB_CIS" cardinality="single"/> <ObAttributeDefinition name="l" syntax="OB_CIS" cardinality="single" /> <ObAttributeDefinition name="location" syntax="OB_CIS" cardinality="single" /> <ObAttributeDefinition name="mail" syntax="OB_CIS" cardinality="single" /> <ObAttributeDefinition name="ou" syntax="OB_CIS" cardinality="single" /> <ObAttributeDefinition name="uid" syntax="OB_CIS" cardinality="single" /> <ObClassDefinition name="person"> <ObAttributeReference name="c" required="false" /> <ObAttributeReference name="cn" required="false" /> <ObAttributeReference name="department" required="false" /> <ObAttributeReference name="l" required="false" /> <ObAttributeReference name="location" required="false" /> <ObAttributeReference name="mail" required="false" /> <ObAttributeReference name="ou" required="false" /> <ObAttributeReference name="uid" required="false" /> <ObClassDefinition name="organizationalUnit"> <ObAttributeReference name="l" required="false" /> <ObAttributeReference name="ou" required="false" /> </ObClassDefinition> <ObClassDefinition name="locality"> <ObAttributeReference name="l" required="false" /> </ObClassDefinition> <ObClassDefinition name="country"> <ObAttributeReference name="c" required="false" /> </ObClassDefinition> <ObClassDefinition name="computer"> <ObAttributeReference name="cn" required="false" /> <ObAttributeReference name="l" required="false" /> <ObAttributeReference name="location" required="false" /> <ObAttributeReference name="ou" required="false" /> </ObClassDefinition> <ObClassDefinition name="group"> <ObAttributeReference name="cn" required="false" /> <ObAttributeReference name="mail" required="false" /> <ObAttributeReference name="ou" required="false" /> <ObAttributeReference name="uid" required="false" /> </ObClassDefinition> <ObClassDefinition name="role"> <ObAttributeReference name="l" required="false" /> <ObAttributeReference name="ou" required="false" /> </ObClassDefinition> </ObTemplateDefinition>
The Oracle Access Manager Developer Guide describes how to create a plug-in to send data from an Identity System workflow to a back-end application. Keep in mind the following when creating this plug-in:
It is no longer possible to do bulk reactivations using the Identity Event API.
When using IdentityXML and the Identity Event API, note that the only permitted action when sending attributes from the Identity System is Replace All. If you create an IdentityXML statement using Add or Replace, the statement is processed as if you used Replace All.
