6 Customizing Self-Registration, User Profile Management, and Service Accounts

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:

Files to Modify
Customizing Self-Registration Options
Customizing Self-Initiated Profile Management Options
Customizing Service Accounts

Files to Modify

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 Design Console.

Customizing Self-Registration Options

This section explains how to customize the self-registration functions of your Oracle Identity Manager Administrative and User Console.

Specifying Whether Self-Registration is Allowed

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.

Defining Custom Fields for the User Information Pages

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 the FormMetaData.xml file, in the  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 .
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 Design Console 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.

Defining the User Self-Registration Page

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.

Specifying Whether Approvals are Required for Self-Registration

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.

Customizing Self-Initiated Profile Management Options

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.

Specifying Fields that Users May Edit in Their Profiles

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.

Specifying Whether Approvals Are Required for User-initiated Profile Changes

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.

Specifying the Fields That the Approver May Edit or Override

Open the FormMetaData.xml file.
Locate the section called ProfileModificationApprovalForm.
Set the editable parameter to TRUE for each of the fields you want to enable users to edit.
Save and close the file.

Customizing Service Accounts

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.

Service Account Behavior

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.

Converting Accounts

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:

tcUserOperations.changeFromServiceAccount
tcUserOperations.changeToServiceAccount

Service Account Alerts

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.

Moving Service Accounts

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.

Service Account Flag APIs

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.