Browser version scriptSkip Headers

Oracle® Fusion Applications Security Guide
11g Release 6 (11.1.6)
Part Number E16689-06
Go to Documentation Home
Go to contents  page
Book<br />List
Go to Feedback page

Go to previous page
Go to previous page

Identity Management and Access Provisioning: Explained

Securing Identities and Users: Points To Consider

Provisioning Access: Points To Consider

Role Provisioning and Segregation of Duties: How They Work Together

Identity Management and Access Provisioning: Explained

You provision identities with access through user accounts, roles, and role memberships. Users should have resources and access rights based on their job or position within the enterprise.

User accounts are created as identities and stored in the Lightweight Directory Access Protocol (LDAP) store. Oracle Fusion allows direct integration with any LDAP server. Roles are provisioned by making the identity a member of a group that is the requested role. Roles are automatically provisioned based on the assignment of the employee. Authorized users are provisioned into the Oracle Fusion database as needed.

Resources such as identities or accounts, enterprise roles, and application roles are provisioned and reconciled based on policies.

HCM processes, such as for a new hire or transfer, trigger identity management and access provisioning.

Identity Management

Oracle Identity Management (OIM) is available in Oracle Fusion Applications through integration with Oracle Fusion Middleware. Identity management in Oracle Fusion Application involves creating and managing user identities, creating and linking user accounts, managing user access control through user role assignment, managing workflow approvals and delegated administration. An example of delegated administration is a sales line of business approving access to sales roles, rather than having the IT security manager approve such access.

In addition to using OIM pages in Oracle Fusion Applications, you can provision users with access to functions and data through various product features, such as team definitions in Oracle Projects.

Oracle Fusion Applications and applications not in Oracle Fusion Applications may share OIM for identity management.

Access Provisioning

Oracle Fusion Applications notifies the IT security manager of the account requests, role provisioning requests, and grants to ensure role administration is always documented, authorized and auditable.

Most Oracle Fusion applications use events within applications to start the provisioning activities. Most of these provisioning events are concerned with users that are part of the enterprise that is deploying the application, but there are also many users that may not be part of the deploying enterprise, such as applicants, account managers that work for your suppliers, or project team members that work for consulting agencies.

Role provisioning events occur across the life cycle of your implementation and deployment.

Provisioning additional roles to employees or internal users may cause an segregation of duties (SOD) violation with already provisioned roles. In contrast, provisioning roles to external users such as partners or suppliers is not likely to cause an SOD violation for individuals but may cause an SOD conflict for the host enterprise.

In most cases, Oracle Fusion Applications invokes OIM to handle role requests and role provisioning. The PER_USER_ROLES table stores information about what roles are provisioned to which users.


Use Oracle Identity Management (OIM) to configure audits of provisioning events.


As a security guideline, avoid having users entitled to provision roles from being the same users who are defining those roles.

For more information about Oracle Internet Directory as the Lightweight Directory Access Protocol (LDAP) server, see Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

Securing Identities and Users: Points To Consider

Identity covers all aspects of an entity's existence within the contexts in which it is used. The identity of an enterprise user consists of HR attributes, roles, resources, and relationships.

HR attributes include identifying information about a user that is relatively static and well understood, such as first and last name, title, and job function.

Roles are part of a user's identity and define the user's purpose and responsibilities.

Within identity management, resources define what a user can and does do. In an enterprise, this typically translates into what resources a user has access to, what privileges they have on that resource, and what they have been doing on that resource. Resources can be application accounts or physical devices such as laptops or access cards. The enterprise owns the resources, secures them, and manages access to the resources by managing the user's identity and access.

Relationships establish the portion of user identities that involve organizational transactions such as approvals.

An Oracle Fusion Applications user and corresponding identity are usually created in a single transaction, such as when a worker is created in Human Resources (HR). That transaction automatically triggers provisioning requests for the user based on role provisioning rules.

User accounts for some identities that are not employees, such as partner contacts, may be created in a later transaction using an identity that is already created in the identity store. Supplier contacts are created in the Supplier Model, not HR.


Various locations store identity and user data.

Identity data consists of the following.

In Oracle Fusion Applications, identities and users correspond one to one, but not all identities correspond to a user, and not all users are provisioned with an identity. Some identities stored in HR and Trading Community Model may not be provisioned to user accounts and therefore are not synchronized with Oracle Identity Management (OIM). For example, a contact for a prospective customer is an identity in Trading Community Model but may not be provisioned with a user account in OIM. Some users stored in the Lightweight Directory Access Protocol (LDAP) store may not be provisioned with identities. For example, system user accounts used to run Web services to integrate third party services with Oracle Fusion Applications are not associated with a person record in HR or Trading Community Model. Some identifying credentials such as name, department, e-mail address, manager, and location are stored with user data in the LDAP store.

Importing Users

You can import users or user attributes in bulk from existing legacy identity and user stores.

Your tasks may include the following.

You can reserve a specific user name not currently in use for use in the future, or release a reserved username from the reservation list and make it available for use. Between a user registration request and approved registration, Oracle Fusion Applications holds the requested user name on the reservation list, and releases the name if an error occurs in the self-registration process or the request is rejected. Self-registration processes check the reservation list for user name availability and suggest alternative names.

Provisioning Events

New identities, such as new hires, trigger user and role provisioning events. In addition to user creation tasks, other tasks, such as Promote Worker or Transfer Worker, result in role provisioning and recalculation based on role provisioning rules.

When an identity's attributes change, you may need to provision the user with different roles. Role assignments may be based on job codes, and a promotion triggers role provisioning changes. Even if the change in the identities attributes requires no role assignment change, such as with a name change, OIM synchronizes the corresponding user information in the LDAP store.

Deactivating or terminating an identity triggers revocation of some roles to end all assignments, but may provision new roles needed for activities, such as a pay stub review. If the corresponding user for the identity was provisioned with a buyer role, terminating the identity causes the user's buyer record in Procurement to be disabled, just as the record was created when the user was first provisioned with the buyer role.

Notifications and Audits

Oracle Fusion Applications provides mechanisms for notifying and auditing requests or changes affecting identities and users.

Oracle Fusion Applications notifies requestors, approvers, and beneficiaries when a user account or role is provisioned. For example, when an anonymous user registers as a business-to-customer (B2C) user, the B2C user must be notified of the registration activation steps, user account, password and so on once the approver (if applicable) has approved the request and the user is registered in the system.

User ID and GUID attributes are available in Oracle Fusion Applications session information for retrieving authenticated user and identity data.

End user auditing data is stored in database WHO columns and used for the following activities.

You can conduct real time audits that instantiate a runtime session and impersonate the target user (with the proxy feature) to test what a user has access to under various conditions such as inside or outside firewall and authentication level.

For information on configuring audit policies and the audit store, see the Oracle Fusion Applications Administrator's Guide.

Delegated Administration

You can designate local administrators as delegated administrators to manage a subset of users and roles.

Delegated administrators can be internal or external persons who are provisioned with a role that authorizes them to handle provisioning events for a subset of users and roles.

For example, internal delegated administrators could be designated to manage users and roles at the division or department level. External delegated administrators could be designated to manage users and roles in an external organization such as a primary supplier contact managing secondary users within that supplier organization.

You can also define delegated administration policies based on roles. You authorize users provisioned with specific roles named in the policy to request a subset of roles for themselves if needed, such as authorizing a subset of roles for a subset of people. For example, the policy permits a manager of an Accounts Payables department to approve a check run administrator role for one of their subordinates, but prohibits the delegated administrator from provisioning a budget approver role to the subordinate.


You activate or change credentials on users by managing them in Oracle Identity Management (OIM)

Applications themselves must be credentialed to access one another.

Oracle Fusion Applications distinguishes between user identities and application identities (APPID). Predefined application identities serve to authorize jobs and transactions that require higher privileges than users.

For example, a payroll manager may submit a payroll run. The payroll application may need access to the employee's taxpayer ID to print the payslip. However, the payroll manager is not authorized to view taxpayer IDs in the user interface as they are considered personally identifiable information (PII).

Calling applications use application identities (APPID) to enable the flow of transaction control as it moves across trust boundaries. For example, a user in the Distributed Order Orchestration product may release an order for shipping. The code that runs the Pick Notes is in a different policy store than the code that releases the product for shipment. When the pick note printing program is invoked it is the Oracle Fusion Distributed Order Orchestration Application Development Framework (ADF) that is invoking the program and not the end user.

Provisioning Access: Points To Consider

Various considerations affect how your enterprise provisions access.

You can migrate role memberships, such as from test to production. However, such a bulk Lightweight Directory Access Protocol (LDAP) import sacrifices the automatic control of role assignments that are provided by role provisioning rules when user data changes.


As a security guideline, maintain role memberships through role provisioning rules. Human Capital Management (HCM) role provisioning rules define what HR Person or CRM Party criteria are associated with roles. Supplier Portal provisioning rules apply to users provisioned through the Supplier application.

When upgrading to a new release of Oracle Fusion Applications, you only need to migrate users and users' role memberships if the LDAP server changes..

Access provisioning task flows are either administered or self service. Administered provisioning requires you to initiate requests and manage users on behalf of users and the enterprise. In self service provisioning, users initiate the provision requests.

Administered Access

Provision to users only those job roles that are not inherited by data roles you could provision instead.


As a security guideline, provision the data roles that grant access to a specific set of instances within a business object, based on the user being provisioned.

For example, when provisioning the Accounts Payables Manager job role to a user in the US business unit, you select the Accounts Payables Manager US data role, which grants access to person, payroll, location, and position in that dimension.

Self Service Access

Self service access provisioning in Oracle Fusion Applications generates approval requests. You may configure provisioning requests to be automatically approved for certain roles. For example, when a line manager requests roles on behalf of a new hire.

Oracle Identity Management (OIM) supports self registration flows where users expect access as soon as the registration is complete. If the user has not been registered or the required roles have not been provisioned to the user, the self registration attempt triggers a role provisioning request.

Oracle Fusion Applications supports image-based authentication in self-registration scenarios.

Request Management

Duty roles cannot be requested and should not be provisioned on a role request. Role requests adhere to segregation of duties policies.

Passwords are stored in Oracle Identity Management (OIM) based on OIM password policies.

For information about configuring user attributes and password policies, see the Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager

Role Provisioning and Segregation of Duties: How They Work Together

Segregation of duties (SOD) checks occur when roles are assigned to users. The checks are based on Oracle Application Access Controls Governor (AACG) policies. The Oracle Identity Management (OIM) integration includes predefined routing rules for remediation in the Manage IT Security business process.

External users such as suppliers or partners need to be provisioned with roles to facilitate access to parent company interfaces and data. The process by which such provisioning requests are approved in Oracle Fusion Applications helps explain the request flows and possible outcomes.


In Oracle Identity Management (OIM), external users means users who are not specific to applications, such as enterprise roles or the absence of entitlement to access an application.

The figure shows the role provisioning request flow. OIM uses AACG to check segregation of duties violations.

The image shows the flow from Fusion
Supplier or Partner Relationship Management (PRM) application through
the HRMS SPML client, Oracle Identity Management, and the segregation
of duties exception approval workflow based on Approval Management
Service (AMX) rules to the global applications worklist of approvers.


A supplier or partner requests admission to a program using an implementation of the Supplier Portal Submission. The submission is captured in one or both of the following tables in advance of approving or rejecting the supplier or partner.

Oracle Fusion Applications collects the employee names for the supplier or partner company at the time the company submits its request to join the program so that all employees accessing Oracle Fusion Applications on behalf of the supplier or partner are provisioned.

AACG in the Oracle Governance, Risk and Compliance Controls (GRCC) suite is certified to synchronize with the policy and identity stores for all pillars or partitions of Oracle Fusion Applications and integrated with the Oracle Fusion Applications security approach to roll up entitlements (by means of duty roles) to the roles that are provisioned to internal users. SOD policies can be defined and enforced at any level of authorization. For external users, SOD policies use attribute information stored in the Trading Community Model tables.

OIM and the SPML Client

Enterprise business logic may qualify the requester and initiate a role provisioning request by invoking the Services Provisioning Markup Language (SPML) client module, as may occur during onboarding of internal users with Human Capital Management (HCM), in which case the SPML client submits an asynchronous SPML call to OIM. Or OIM handles the role request by presenting roles for selection based on associated policies.

OIM recognizes the role provisioning request and initiates a call to AACG.

OIM apprises the SPML client of the current state of the role provisioning request as SOD_CHECK_IN_PROGRESS.

OIM stores the SOD check result as part of OIM audit data.

OIM apprises SPML client of the current state of the SPML request. The provisioning is either still in progress with segregation of duties being checked, or conflicts were found. If conflicts exist, AACG rejects the request and notifies the application.



Current State



Request sent to AACG and waiting for response


Conflict found

AACG detected violations and remediation is in progress


No conflict found

No SOD violations found


Conflict found

AACG detected violations that cannot be remediated


Conflict found

AACG detected violations that are approved


Conflict found

AACG detected violations that are rejected by approver

In the absence of an SOD exception, OIM provisions all relevant users.


When a partner user is provisioned, all employees of the partner enterprise are provisioned. SOD checks occur when an external user requests to join a program, because SOD policies operate across Oracle Fusion Applications, not at the individual level. Supplier or partner company user requests are not approved if there is an SOD conflict against the supplier company.

OIM provides AACG with the details of SOD exception approval workflow. AACG audits the outcome for use in future detective controls and audit processes.

Oracle Application Access Controls Governor

AACG may respond with the following.

Supplier or Partner Relationship Management responds to an SOD exception by updating Trading Community Model tables with the current state. An enterprise may elect to implement a landing pad that offers external users a means of addressing the SOD problem by providing more information or withdrawing the request.

SOD violation checking occurs during role implementation and provisioning, and can be turned on or off if AACG is provisioned and enabled as part of the Oracle Fusion Applications deployment.

Segregation of Duties Exception Resolution or Approval Workflow

Depending upon status, OIM kicks off an auditable SOD exception resolution workflow. Resolution can be conditional based on approval or requirements such as contracts being met.

If one of the paths for exception resolution is to get an approval, then the SOD exception resolution drives the approval using AMX. Standard AMX rules, not business rules, resolve the approval for the SOD exception, including the following.

The approver resolution uses AMX Rules Designer to access various user attributes and organizational hierarchies managed in Oracle Fusion Applications repositories. This information is typically not available in OIM or the LDAP identity store repository. Enterprises can define additional approval rules using AMX Thin Client.

The SOD Exception Approver gets a notification through supported channels that a new request is awaiting approval. The approver signs in to the global SOA federated worklist application that aggregates all pending worklist items for the user from all Oracle Fusion applications and logical partitions or pillars of applications. The SOD exception approval tasks show up in the same list.

The SOD exception approval task shows the details of the SPML request and SOD Provisioning results in a page rendered by OIM. The approver may take one of the following actions.

If the approver approves the request, OIM sends an SOD_REMEDIATION_APPROVED status to the SPML client.

If the approver rejects the request, OIM sends an SOD_REMEDIATION_REJECTED status to the SPML client. The provisioning request is considered completed with a failure outcome and the external users is notified. Oracle Fusion Applications updates the Trading Community Model tables with the rejected status

Remediation Task Assignments

The SOD remediation tasks are assigned based on the role being requested.

  1. If the role requested is Chief Financial Officer, the SOD remediation task is assigned to the IT Security Manager role.

  2. If the SOD violation results from a policy where the SOD control tag is the Information Technology Management business process and the control priority is 1, the SOD remediation task is assigned to Application Administrator role.

  3. In all other scenarios, the SOD remediation task is assigned to the Controller role.

For more information about configuring audit policies, see the Oracle Fusion Applications Administrator's Guide.

For information on managing segregation of duties, see the Oracle Application Access Controls Governor Implementation Guide and Oracle Application Access Controls Governor User's Guide.