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 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 purpose.

For the self-registration process, you must determine:

Whether or not 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 or not approvals are required for self-registration?

For user-initiated changes to the user profile, you must determine:

Which fields the user may edit in their own profile?
Whether or not approvals are required for user-initiated profile changes?
Which fields the approver may edit or override?

This chapter discusses the following topics:

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

6.1 Files to Modify

To customize self-registration and self-editing of profiles and service accounts, you edit this file:

OIM_HOME\xellerate\config\FormMetaData.xml

In addition, you must edit the relevant records within the Oracle Identity Manager Design Console.

6.2 Customizing Self-Registration Options

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

6.2.1 Specifying Whether Self-Registration is Allowed

To specify whether or not self-registrations is allowed:

Log in to the Design Console.
Access the System Configuration form by navigating to the Administration directory.
Query to find the Is Self-Registration Allowed? property.
Set the value of the Is Self-Registration Allowed? property to TRUE to allow users to self-register. To disallow users from self-registering, set the value of this property to FALSE.
Save the changes.

6.2.2 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 Design Console.
Access the User Defined Field Definition form by navigating to the Administration directory.
Query to find the Users form.
Create a user-defined field, for example, a social security number.

See Also:
The "Adding a User-Defined Field to an Oracle Identity Manager Form" section of the Oracle Identity Manager Design Console Guide for information about creating a user-defined field
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" />
```
In this format:
- 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 by using the Design Console. User-defined fields are prefixed with USR_UDF_. Therefore, if you type in SSN in the Design Console, then 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 enter when you use the Design Console to create a field definition.
Save the changes to this file.

After you create a custom field and define it, you can use it in a page definition.

6.2.3 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>
```
In this format:
- 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 can omit this attribute.
Save the changes to this file and close it.

Note:
To remove a field from the self registration page of the Administrative and User Console, remove the row from the <Form name="SelfRegistrationUserForm"> section that represents the field.

6.2.4 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 nonconditional 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 present on the User Self-Registration page.

6.3 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 can be edited by the users within their profile, whether or not approvals must be obtained to allow these edits, and if so, which fields the approver can update.

6.3.1 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 ProfileModificationUserForm section.
Set the editable parameter to TRUE for each of the fields that you want to enable for the users to edit.
Save and close the file.

6.3.2 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 nonconditional 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 nonconditional tasks.
Ensure that no fields on the profile update-related approval pages are set as required that are not present on the Modify Account Profile page.

6.3.3 Specifying the Fields That the Approver May Edit or Override

To specify the fields that the approver might 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 of the users to edit.
Save and close the file.

6.4 Customizing Service Accounts

Service accounts are general administrator accounts, such as admin1 and admin2, which are used for maintenance purpose. 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.

6.4.1 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. It uses the same resource object, provisioning processes, and process or object forms as a regular account. 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, which means the provisioning process for the service account will not be canceled, 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 or enable actions. Therefore, when a user is deleted, the Service Account Alert task functionality is triggered.
When the user gets disabled, the resource will not be disabled, which means the 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 APIs can be used to transfer a provisioned service account resource, for example a provisioning process and a process form entry, from one user to another. When this happens, the Service Account Move task functionality is triggered.

6.4.2 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

6.4.3 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.

6.4.4 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 predefined response code is attached.

The API method for moving a Service Account is tcUserOperationsIntf.moveServiceAccount.

6.4.5 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.