Home‎ > ‎Oracle Identity Manager‎ > ‎Manage Identity‎ > ‎

Oracle Identity Manager Profile

OIM User Profile is user's account in OIM and is used to represent the user within the OIM data model. The OIM User Profile consists of the following
  1. Attributes
  2. Roles
  3. Accounts
  4. Administration Roles

User Profile Attributes

OIM User profile comes with a large number of out of box attributes that can be leveraged to map the real world user to OIM view of the user.
. In addition to that, OIM provides the ability to add new attributes to support additional fields of choice called custom attributes (also called UDF- User Defined Attribute). 

Configuration Management

The User Profile Attributes are configured and managed through the sysadmin console available at http://<server>:14000/sysadmin (System Entities -> User).
Create UDF in OIM

The user must have the Administrator (TODO: Check list) access level to perform the changes as part of the sandbox. The sandbox can then be exported/imported to other environment to migrate the changes.

Under the hood

The user profile attributes are represented in different ways across the three tiers of the OIM i.e. database, Middleware and User Interface.

In database, the User Profile is primarily represented by the USR table. Not all the attributes in the table are just used by User Profile and not all the user's attributes are part of this table. Please refer to Database Schema Documentation/Data Dictionary (available on https://support.oracle.com by searching for respective DOC ID - 11gR2 PS2 (Doc ID: 1612983.1), 11gR2 PS1 (DOC ID: 1541858.1) for more details about the how the different tables are used.

The middleware i.e. OIM APIs leverage the data model defined in the Metadata Service Repository (TODO: Add link explaining the details) to identify the attributes and associated configuration that must be used to validate and store the user details. This data model is stored in /file/User.xml and contains the details about each attribute (and its type, whether it is required, searchable, Category, encryption type, visibility, size, multi-value, bulk updates). This information is leveraged by the core APIs and the front-end systems to display fields, validate the data and store it appropriately in database.

The front end leverages the ADF to generate and display the details to the end-user. In this regard, it leverage specific pages and customizations associated with Cart Details (/oracle/iam/ui/catalog/pages/cart-details.jsff) and more specifically (/oracle/iam/ui/runtime/form/view/pages/userCreateForm.jsff) which is embedded in the Cart Details page. This page can be located in the(TODO: Add the detail)

Special Attributes

Most of the attributes in User Profile are not leveraged internally by OIM and is primarily for tracking the user details. But there are some attributes that are leveraged for tracking various details associated with password, account lifecycle and so on. 

Configuration Management

These attributes, due to their nature, change over time. I am not aware of any documentation that discusses these in detail. At the same time, the following pointers was used to develop this list
  1. Scheduled Task documentation - The documentation on the various out of box schedulers available as part of Oracle Product Documentation (Refer to section Predefined Scheduled Tasks in chapter Managing the Scheduler of Administrator's Guide to Oracle Identity Manager) refer to these attributes that are leveraged by the out of box scheduled task.
  2. UserManagerConstants - There is a class called oracle.iam.identity.usermgmt.api.UserManagerConstants which is used in a lot of internal Oracle code. This class has a lot of ENUMS that are of interest. One of the enum AttributeValues refers to the values that seem to be leveraged in writing some of the code. This gives some idea about the attributes that are of interest within OIM.
  3. User's Guide for Oracle Identity Manager 11gR1 This document has a complete list of the attributes associated with that release. I am not aware of any other documentation in future release that have the details at this level.

 #  Attribute Name  Internal Name  Attribute Values Details 
1  User Status  usr_status
Disabled Until Start Date 
 Leveraged to figure out the account status. This drives
  1. the operations that can be performed on the account. 
2 usr_key  usr_key Number  This is primarily key id for the user in the system. It is used to correlate the user across all the other components/systems within the system. 
Organization  act_key Number  Organization associated with the user drives the following aspects with in OIM
  1. Access to applications, entitlements, users(request) - Authorization policies
  2. Applicable Password Policy
  3. Specific certification use-case
With OIM 11gR2PS2 
4Organization lov_ds_act_key TextThis is a UI component which is not typically referred to in back end code. I think this translation is typically handled automatically in UI in the CatalogAM implementation. 
5 User Login usr_login String  This is used by users to login to the OIM. This is expected to be present for the corresponding user to be able to login to OIM to perform operations. Starting with 11gR2 PS1 this is not a mandatory/required field.
6 User Manager
usr_manager_key Number   The user's manager is an important role within OIM which can leveraged to drive approval and certification. In addition to that being a manager may be used to define specific privileges to a user within the system (e.g. request for people for whom you are manager).

This play an important role in the certification, proxy (you can set your manager as proxy), email notification (typically notifications are sent to user's manager by default), etc.
7Manager lov_ds_usr_manager_keyTextThis is a UI component which is not typically referred to in back end code. I think this translation is typically handled automatically in UI since the pre-process handler seems to have the right detail.
8 Password can not change  usr_pwd_cant_change  String  
9 Password must change usr_pwd_must_change  String ?? 
10 Password never expires  usr_pwd_never_expires  String  
11 Password Expiry date usr_pwd_expire_date  Date   
12 Password Warning Date  usr_pwd_warn_date  Date   
13 Access Policy Update  usr_policy_update  String  ?? 
14 Account Status usr_locked String (Lookup)  0 (unlocked)
1 (locked)
Primarily used to identify a Locked OIM User. Typically a locked user is not allowed to login to system. Also would be used by Automatically Unlock User Scheduled task.

AFAIK this does not have any impact on any user process. 
15Automatically Delete On usr_automatically_delete_onTextThe date on which user must be deleted. This information is used by Delayed Delete User Scheduled task to identify which user it should be deleting. In addition to that if this value is set, then Disable/Delete User After End Date scheduled task will not delete the user.
The value can be set explicitly using code OR it will be set by DeleteUserActionHandler (Event Handler for User Delete) by adding the value of 
XL.UserDeleteDelayPeriod system property to today's date.
16Deprovisioned Date usr_deprovisioned_dateTextDate on which the user has been "de-provisioned" by the system.
This date in conjunction with Provisioning Date is used by Access Policy Engine to check whether access policy is evaluation must be performed for user. Please note that new version of code do not seem to use this data and primarily focus on "Active" (i.e. not disabled, deleted, disabled until start date, rejected) and "usr_policy_update" to identify if access policy must be performed. (TODO: Need more
RevokeResourcesOnDeProvisionedDate Event handler (User MODIFY) triggers revocation of all the user's resources if User's Deprovisioned Date is set.
The value is set by Set User Deprovisioned Date scheduled task that runs by default on daily basis and sets Deprovisioned Date to today's date if the corresponding DEPROVISIONING DATE date is less than todays date.
17Deprovisioning Date usr_deprovisioning_dateTextDate that can be set on the user to trigger the deprovisioning of the user accounts. This is user editable field and should be used to trigger setting of deprovisioned date (See above).

The two separate dates allow disconnection of the two processes.

In addition to that Deprovisioning Date forms an important part of
User's start date < provisioning date < de-provisioning date < end date validation process.
18Design Console Accessusr_typeTextThis is a legacy user attribute that used to differentiate users in to "Identity Only", "End User" and "End-User Administrator". 

As far as I know, this is probably used in authentication queries to ignore "Identity Only" users i.e. "Identity Only" users can not login to web application and are only managed through the system.

I have not seen any pattern that leverages the "Design Console Access" anywhere to restrict user's access to design console BUT the User Pre-process handler does convert a boolean value for this attribute into Text value of "End User" OR "End-User Administrator" based on value of "Design Console Access" being false or true respectively.
19Display Nameusr_display_nameText/StringUsed in a lot of places to identify the user.

There may be some internal undocumented requirement to have unique value since a lot of UI elements use "display name" for display purpose BUT I have not seen any attempt in code to enforce this.

Please note that Display Name if not provided is automatically generated using UserMgrUtil.generateSingleFullName in ReconUserDisplayNameHandler Event Handler (User CREATE, MODIFY). The code does not make any attempt to generate unique display name.
20End Dateusr_end_dateText/DateDate till which OIM User profile is effective. This is a user input field.

Besides the standard start date < provisioning date < de-provisioning date < end date, system tries to do additional validations around other items created or assigned to user. Examples are Proxy User assignment creation (proxy end date < end date), Entitlement assignment (valid to date < user end date)

In addition to that Disable/Delete User After End Date job uses the end date to delete all the users past end date.
21Identity Statususr_status/usr_disabledLookup / TextTwo internal attributes are mapped to Identity Status.

Mostly used to ensure that Deleted users are not getting considered for various queries and assignments. Also, most of automated things happen for "Active" status.

Typical change of value is "Disabled until start date" [only if user is created with future start date] --> Active --> Disabled --> Deleted.
Not sure how Rejected comes into picture.
22LDAP DN/Organization/Organization Unitusr_ldap_dn, usr_ldap_organization, usr_ldap_organization_unitTextPrimarily used by LDAP Sync capability of OIM
23Localeusr_localeLookupDrives locale specific display details for user. Specially used in generation of display name, selection of email notification templates, and so on. 

Disqus for Google Sites