11g Release 1 (11.1.2)
Part Number E16689-02
Contents
Previous
Next
|
Oracle® Fusion
Applications Security Guide 11g Release 1 (11.1.2) Part Number E16689-02 |
Contents |
Previous |
Next |
This chapter contains the following:
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
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.
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.
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.
Employees, contingent workers, internal users
Hiring
Self-service role requests
Transfers, moves, and reorganization
Termination
Suppliers, partners, external users
Registering account managers and support representatives
New role request, such as joining a new partner program
Change in procurement policy triggers reevaluation of role membership
Prospective supplier requests user account during supplier registration or existing supplier requests accounts for additional employees
Parent organization's program structure changes and creates need for role revocation or creation of additional roles
Scheduled role provisioning request triggers role provisioning at a future effective date and time
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.
Note
Use Oracle Identity Management (OIM) to configure audits of provisioning events.
Tip
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.
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.
HR person records
Oracle Fusion Trading Community Model party records
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.
You can import users or user attributes in bulk from existing legacy identity and user stores.
Your tasks may include the following.
Create users in bulk
Update specific attributes for all users, such as postal code
Link users to HR or Trading Community Model persons
Monitor progress of the import process
Correct errors & re-import
Export users in bulk
Import and export users using a standard plain text data interchange format like Lightweight Data Interchange Format (LDIF)
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.
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.
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.
Setting up sign-in audit
Using the application monitor
Notifying of unsuccessful sign ins
Sign-in audit reports
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.
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.
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.
Tip
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.
Provision to users only those job roles that are not inherited by data roles you could provision instead.
Tip
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 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.
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
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.
Note
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.
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 Trading Community Model
Interface Staging
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.
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.
|
Status |
Conflicts |
Current State |
|---|---|---|
|
SOD_CHECK_IN_PROGRESS |
Unknown |
Request sent to AACG and waiting for response |
|
SOD_REMEDIATION_IN_PROGRESS |
Conflict found |
AACG detected violations and remediation is in progress |
|
SOD_CHECK_APPROVED |
No conflict found |
No SOD violations found |
|
SOD_CHECK_REJECTED |
Conflict found |
AACG detected violations that cannot be remediated |
|
SOD_REMEDIATION_APPROVED |
Conflict found |
AACG detected violations that are approved |
|
SOD_REMEDIATION_REJECTED |
Conflict found |
AACG detected violations that are rejected by approver |
In the absence of an SOD exception, OIM provisions all relevant users.
Note
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.
AACG may respond with the following.
Roles may be provisioned to the external user or its employees because no SOD conflict is found
SOD conflict is found and request is denied because the relevant SOD policy is to be strictly enforced and no exception approval should be allowed
SOD conflict is found and the exception to the policy is allowed, so the request goes through additional processing, such as an approval process.
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.
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.
Organizational hierarchies
Multiple mandatory and optional approvers
Rerouting and approval delegation
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.
Approve the request as it is
Reject the request
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
The SOD remediation tasks are assigned based on the role being requested.
If the role requested is Chief Financial Officer, the SOD remediation task is assigned to the IT Security Manager role.
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.
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.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
