Oracle® Identity Manager Administrative and User Console Customization Guide Release 9.0 Part Number B32145-01 |
|
|
View PDF |
This chapter explains how to customize the self-registration process for creating user accounts, and how users edit their account profiles in the Oracle Identity Manager Administrative and User Console. It also explains how to customize service accounts, that is, general administrator accounts shared by several users and used for maintenance purposes.
For the self-registration process, you can customize:
Whether self-registration is allowed
Which fields can be used during the registration process
Which fields are displayed, and which are mandatory when a user is self-registering
Whether approvals are required for self-registration
For user-initiated changes to the user profile, you can customize:
Which fields the user may edit in their own profile
Whether approvals are required for user-initiated profile changes
Which fields the approver may edit or override
This chapter contains these topics:
To customize self-registration, self-editing of profiles, and service accounts, you edit this file:
<XL_HOME>\xellerate\config\FormMetaData.xml
In addition, you must edit the relevant records within the Oracle Identity Manager Java Client.
This section explains how to customize the self-registration functions of your Oracle Identity Manager Administrative and User Console.
To specify whether self-registrations is allowed:
Log in to the Oracle Identity Manager Design Console.
Access the System Configuration form by navigating to Administration, then to System Configuration.
Query to find the Is Self-Registration Allowed?
property.
Set the value to TRUE
to allow users to self-register, or to FALSE
to disallow users from self-registering.
Save the changes.
On the user self-registration and profile pages of the Console, there are several fields already defined for user information. You can create custom fields for users to enter information when they are self-registering or editing their profiles.
Note: The default system fields on the self-registration pages are listed in theFormMetaData.xml file, in the <!-- User Self Registration and User Profile Modification section --> section |
To create custom fields for the user self-registration page:
Log in to the Oracle Identity Manager Design Console.
Access the User Defined Field Definition form by navigating to Administration, and then to User Defined Field Definition.
Query to find the Users form.
Create a user-defined field, for example, a social security number, as explained in the Oracle Identity Manager Design Console Guide.
Save and close the User Defined Fields form.
In a text editor, open the Oracle Identity Manager FormMetaData.xml
file, and locate the section <!-- User Self Registration and User Profile Modification section -->
.
To define the attribute, add an entry for it in the following format:
<Attribute name="identifier" label="field_label" displayComponentType="datatype" map="database_column" />
where
identifier
is the name used to specify this field when you define a page.
field_label
is the word displayed to the user next to the field in the Administrative and User Console.
datatype
is the data type of the field displayed in the Console.
database_column
is the database column name, specified when you created the field definition using the Design Console. User-defined fields are prefixed with USR_UDF_
, so if you typed in SSN
in the Design Console, this value is USR_UDF_SSN
. For example:
<Attribute name="USR_UDF_SSN" label="SSN" displayComponentType="TextField" map="USR_UDF_SSN" />
Note: This is the same information you entered when you used the Java Client to create a field definition. |
Save the changes to this file.
Once you have created a custom field and defined it, you can use it in a page definition.
You can specify which fields are displayed, and which are required when users self-register. To display a custom field, you must reference it in the section of the FormMetaData.xml
file for the self-registration user page. This is explained in "Defining Custom Fields for the User Information Pages".
To define the user self-registration page:
Open the FormMetaData.xml
file.
Locate the section called <Form name="SelfRegistrationUserForm"
>. This section contains the definition of the User Self Registration page. To add a field to the page, add a reference to the field in a new row in the following format:
<AttributeReference optional=true/false>identifier</AttributeReference>
where
identifier
is the name you specify in the definition section of the file.
optional
specifies whether a field is required or optional. Setting optional
to false
makes the field required, and true
makes it optional.
For example, to add a new required field with the identifier, USR_UDF_SSN
, add the following line:
<AttributeReference optional="false">USR_UDF_SSN</AttributeReference>
Note: The default value is true, so if a field is required, you may omit this attribute. |
Save the changes to this file and close it.
Note: To remove a field from the self registration page of the Console, remove the row from the<Form name="SelfRegistrationUserForm"> section that represents the field. |
To specify that approvals are required for self-registration, ensure that the User Registration approval process contains at least one manual non-conditional task.
To specify that approvals are not required for self-registration:
Ensure that the user registration approval process does not contain any non-conditional tasks.
Ensure that no fields on the registration-related approval pages are set as required that are not also present on the User Self-Registration page.
See Also: "Defining Custom Fields for the User Information Pages" to find which section of theFormMetaData.xml file to edit |
Note: By default, Oracle Identity Manager does not present the Organization and Role fields to the user when they are self-registering. Values for these fields are required to register a user. As a result, the values of these fields must be set on the request, under the User Information branch, by an administrator or approver. |
By default, all users, once registered, are able to edit their own profile information. You can control which fields within their profile they can edit, whether approvals must be obtained to allow these edits, and, if so, which fields the approver can update.
To specify the fields that users can edit in their profiles:
Open the FormMetaData.xml
file.
Locate the section ProfileModificationUserForm
.
Set the editable
parameter to TRUE
for each of the fields you want to enable users to edit.
Save and close the file.
To specify that approvals are required for user-initiated profile changes, ensure that the User Profile Edit approval process contains at least one manual non-conditional task.
To specify that approvals are not required for user-initiated profile changes:
Ensure that the User Profile Edit approval process does not contain any non-conditional tasks.
Ensure that no fields on the profile update-related approval pages are set as required that are not also present on the Modify Account Profile page.
See Also: "Defining Custom Fields for the User Information Pages" for the section ofFormMetaData.xml file to edit |
Service accounts are general administrator accounts—for example, admin1
and admin2
—that are used for maintenance purposes. They are typically shared by a set of users. Usually these accounts enable a system, as opposed to a user, to interact with another system. The model for managing and provisioning service accounts is slightly different from normal provisioning.
Note: Oracle Identity Manager provides only back-end support for service accounts and they can be managed only through APIs. |
Here are some features of service account behavior:
Service accounts are requested, provisioned, and managed in the same way as regular accounts. A service account is similar to a regular account, in that it uses the same resource object, provisioning processes, and process/object forms. It differs from a regular account by a flag. This flag is set by the user requesting the resource, or by the administrator directly provisioning the resource.
During its lifecycle, a service account can be changed to a regular account, and a regular account can be changed to a service account. When either change occurs, Service Account Changed task functionality is triggered.
When a user is deleted, the resource is not revoked (the provisioning process for the service account will not be cancelled), causing the undo tasks to trigger. Instead, a task should get inserted into the provisioning process in the same way Oracle Identity Manager handles disable/enable actions. The Service Account Alert task functionality is triggered.
When the user gets disabled, the resource will not be disabled (tasks of effect Disable should not be inserted into the provisioning process for the service account instance). Instead, the Service Account Alert task functionality is triggered and a task gets inserted into the provisioning process.
Explicitly disabling, enabling, or revoking a service account instance either directly or through a request is managed in the same way as for regular accounts.
Oracle Identity Manager API can be used to transfer a provisioned service account resource—for example, a provisioning process, process form entry, and so on—from one user to another. When this happens, the Service Account Move task functionality is triggered.
You can change a regular account to a service account or change a service account to a regular account. In either case, the Service Account Change task is inserted within the provisioning process and becomes active in the Tasks tab of the Process Definition. Any adapter associated with this provisioning process is executed. If there is no adapter, then a predefined response code is attached.
The relevant APIs for this functionality are:
When any lifecycle event occurs for the user to whom the service account is linked, the Service Account Alert task is inserted into the provisioning process of that service account instance. You can use this task to initiate the appropriate actions in response to any disabling event that occurred for the user.
An alert task is inserted when a user is disabled or deleted. In these cases, this is the only action that happens to the service account instance.
An alert task is not inserted for events directly on the service account—for example, when a service account is explicitly disabled.
You can transfer ownership of a service account from one user to another. When you do this, the provisioning instance shows up in the resource profile of the new owner, and no longer in the resource profile of the old user. The Service Account Moved task is inserted into the provisioning process of the resource instance after the account is moved. Any adapter associated with this provisioning process is executed. If there is no adapter, then a pre-defined response code is attached.
The API method for moving a Service Account is tcUserOperationsIntf.moveServiceAccount
.
The following API methods set the flags associated with service accounts:
tcRequestOperations.addRequestObject
tcRequestOperations.setRequestObjectAsServiceAccountFlag
tcUserOperations.changeFromServiceAccount
tcUserOperations.changeToServiceAccount
tcUserOperations.provisionObject
tcUserOperations.moveServiceAccount
tcObjectOperations.getServiceAccountList
The names of the flags are indicative of the function of each flag.