| Oracle® Identity Manager Administrative and User Console Customization Guide Release 9.0 B25943-01 |
|
 Previous |
 Next |
| Oracle® Identity Manager Administrative and User Console Customization Guide Release 9.0 B25943-01 |
|
Previous |
Next |
This section describes 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.
For registration, you are able to customize:
Whether self-registration is allowed
Which fields are available to 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 are able to customize:
Which fields the user may edit in their own profile
Whether approvals are required for user initiated profile changes
What fields the approver may edit or override
This chapter includes the following topics:
<XL_HOME>\xellerate\config\FormMetaData.xml
In addition, you must edit the relevant records within the Oracle Identity Manager Java Client.
This section describes how to customize the self-registration functions of your Oracle Identity Manager Administrative and User Console.
To specify whether self-registrations is allowed, do the following:
Log in to the Oracle Identity Manager Java Client.
Access the System Configuration form (Xellerate Administration > System Configuration).
Query to find the Is Self-Registration Allowed? property.
Set the value to TRUE to allow users to self-register.
Set the value to FALSE to disallow users from self-registering.
Save the changes.
There are several fields already defined for user information. These fields are used on the user self-registration and profile pages of the Administrative and User Console. You can create custom fields for users to enter information when they are self-registering or editing their profiles.
|
Note: The default system fields that are available for use on the Self-Registration pages are listed in the<!-- User Self Registration and User Profile Modification section --> section of the FormMetaData.xml file |
To create custom fields for the user self-registration page:
Log in to the Oracle Identity Manager Java Client.
Access the User Defined Field Definition form (Xellerate Administration > User Defined Field Definition).
Query to find the Users form.
Create a user-defined field (for example, social security number). For instructions on how to define user-defined fields, refer to the Oracle Identity Manager Design Console Guide.
Save and close the User Defined Fields form.
Open the Oracle Identity Manager FormMetaData.xml file in a text editor and locate the section called
<!-- User Self Registration and User Profile Modification section -->.
To define the attribute, add an entry for it in the format:
<Attribute name="identifier" label="field_label" displayComponentType="datatype" map="database_column" />
where
identifier is the identifier used to specify this field. This is the name used to specify this field when you define a page.
field_label is the word displayed next to the field in the Administrative and User Console (what the user sees).
datatype is the data type of the field displayed in the Administrative and User Console.
database_column is the database column name, specified when you created the field definition using the Java Client. User defined fields are prefixed with USR_UDF_, so if you typed in SSN in the Java Client, 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 are self-registering. To display a custom field, you must reference it in the section of the FormMetaData.xml file for the self-registration user page (see the Defining Custom Fields for the User Information Pages section).
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 is used to specify 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 Oracle Identity Manager Administrative and User Console, remove the row from the<Form name="SelfRegistrationUserForm"> section that represents the field. |
To disable approvals for self-registration, ensure that the User Registration approval process does not contain any non-conditional tasks. Ensure that all fields required to register a user are present on your User Self-Registration page. This means that you must make sure that there are no fields set as required on the registration-related approval pages that are not also present on the User Self-Registration page. Refer to the Customizing field configuration section of this document for the section of FormMetaData.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 in order 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. |
To enable approvals for self-registration, ensure that the User Registration approval process contains at least one manual non-conditional task.
The procedures in this section allow you to customize how users can edit their own profiles. By default, all users, once registered, are able to edit their own profile information. Oracle Identity Manager provides you with the ability to control which fields within their profile they are able to edit, whether approvals must be obtained in order to allow these changes and, if so, what fields the approver may update.
To specify the fields that users can edit in their profiles:
Open the FormMetaData.xml file.
Locate the section called ProfileModificationUserForm.
Set the editable parameter to TRUE for each of the fields you wish to allow users to edit in their own profile
Save and close the file.
If you wish to disable approvals for user-initiated profile changes:
Ensure that the User Profile Edit approval process does not contain any non-conditional tasks.
Ensure that all fields required for a user to update their profile are present on your Modify Account Profile page. This means that you must make sure that there are no fields set as required on the profile update-related approval pages that are not also present on the Modify Account Profile page. Refer to the Customizing field configuration on pages section of this document for the section of FormMetaData.xml file to edit.
If you wish to enable approvals for user-initiated profile changes, ensure that the User Profile Edit approval process contains at least one manual non-conditional task.
Service accounts are general administrator accounts (for example, admin1 and admin2), which are used for maintenance purposes and are typically shared by a set of users. Usually these accounts are used to allow one system (rather than 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 the same as regular accounts. A service account is no different from a regular account, in that it uses the same resource object, provisioning processes, and process/object forms. It is distinguishable from a regular account only by a flag. This flag gets set by the user making the request for 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 any of these changes occurs then Service Account Changed task functionality is triggered.
When the user gets deleted, the resource will not be revoked (the provisioning process for the service account should not get cancelled), causing the undo tasks to fire. Instead, a task should get inserted into the provisioning process (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 should 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 (directly or through a request) is managed in the same way as for regular accounts.
Oracle Identity Manager API can be used to transfer (move) a provisioned service account resource (provisioning process, process form entry, and so on) from one user to another. When this happens, the Service Account Move task functionality is triggered.
A user (administrator) can change a regular account to be a service account or change a service account to be a regular account. If any of these changes occur, then the Service Account Change task will be inserted within the provisioning process (becoming active in the Tasks tab of the Process Definition). Any adapter associated with this provisioning process will be executed. If there is no adapter, then a predefined response code will be 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. A user (administrator) can use this task to initiate the appropriate actions in response to any disabling event that occurred for the user.
Qualifying lifecycle events for a user are the user being disabled or the user being deleted. In these cases, the only action that happens to the service account instance is the service account alert task being inserted.
This behavior is not followed for events directly on the service account (like explicitly disabling a service account).
A user (administrator) can transfer ownership of a service account from one user to another. This translates into the provisioning instance showing 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 will be executed. If there is no adapter, then a pre-defined response code will be 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.
