Oracle User Management

1. What is Role Based Access Control (RBAC)?
2. What is the difference between a Role and a Responsibility?
3. What is the difference between a Role and a Group?
4. What are Function Security and Data Security?
5. Can data security policies be defined for any data information stored in the E-Business Suite schema?
6. Is Data Security different from Oracle Label Security (OLS)?
7. What is a Grant/Permission Assignment?
8. What is the difference between a Permission Assignment and a Role?
9. What is the difference between Menus and Permission Sets?
10. What are Role Categories and why should I use them?
11. What are Role Inheritance Hierarchies? How are these hierarchies created?
12. Are all external groups hierarchy enabled?
13. What is Delegated Administration?
14. How do I define my own delegation policies?
15. What is a Registration Process?
16. Do Registration Processes create RBAC policies?
17. Can I define my own registration processes?
18. Can I define my own registration user interfaces (UIs)?
19. What is the User Management Registration Engine?
20. Does User Management raise Workflow Business Events? How can I leverage these?
21. What is Eligibility?
22. Are Administrator Account Creation Registration Processes available to all Administrators?
23. Where does the registration information go before it is approved?
24. Can I define my own Workflow notifications? Can they be different for different roles?
25. What is the confirmation number that is displayed whenever a request is submitted and what does this mean?
26. What is Oracle Approval Manager and how it is linked to Oracle User Management?
27. Can I define my own approval routing rules?
28. I have different web sites for different countries. Can I route my approval requests depending upon where an account request originated?
29. What is a User Name Policy?
30. How does the Forgot Password work?
31. How do I enable the various features on the Login page?
32. Is Oracle Human Resources required to implement Oracle User Management?
33. What happens when I upgrade to Oracle User Management in 11.5.10?
34. Is my customer a candidate for the Strategic Implementation Program (SIP)?
35. What Oracle Applications leverage Oracle User Management and RBAC in 11.5.10?
36. How can I learn more about Oracle User Management?

1. What is Role Based Access Control (RBAC)?

Role Based Access Control (RBAC) is an ANSI standard (ANSI INCITS 359-2004) supported by the National Institute of Standards & Technology (NIST). With the 11.5.10 release, Oracle User Management has implemented an RBAC model that closely follows this standard.

The RBAC standard supports the mapping of user access control based upon the role that the user plays within the organization rather than upon the user's individual identity. The benefits of implementing RBAC include:

• Reduced cost of administering user access
• Streamlined setup and implementation of security policies
• Structured user access control based upon users' job functions

The RBAC model augments the existing access control model in Oracle Applications by providing additional methods to organize your data security policies and existing function security (via roles). Security privileges in Oracle Applications have up to this point been managed on an individual user basis, with different types of privileges assigned to each user directly. For example, someone in a Support Agent position may have had to be assigned multiple responsibilities and several other types of access privileges in order to perform their job.

By leveraging the RBAC model, users will no longer need to be directly assigned the lower level permissions and responsibilities, as these can be implicitly inherited based upon the roles assigned to the user. Roles can now be defined to consolidate responsibilities and other roles through role inheritance, as well as lower level permissions (functions) and data security policies. This is accomplished through a one-time setup, where all the permissions are assigned to the role. In order to make a mass update in a production system a client only needs to change the permissions or role inheritance hierarchies defined for a role, then all of the users assigned to that role will instantly inherit the new permissions.

TOP

2. What is the difference between a Role and a Responsibility?

Responsibilities can now be considered a special type of role that represents the set of navigation menus contained within an application. Therefore, responsibilities loosely represent an application itself, whereas roles can be used to determine what parts of that application (and data therein) a user has access. This represents a shift in the definition of a responsibility in Oracle Applications. Previously, a responsibility has been used not only to define the application navigation menus, but also to confer privileges and permissions within that application. Using this definition of responsibility, it was often necessary to create several similar responsibilities in order to effectively carve out data and functional security access for a group of users. This has increased the overall cost of ownership as the number of responsibilities has grown.

Oracle Applications follows the Role Based Access Control (RBAC) Reference Model(ANSI INCITS 359-2004)definition of a role as "a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role." Roles can now be defined to determine what applications (responsibilities) as well as what data and functions within those applications a user has access to.

By leveraging the RBAC model, users will no longer need to be directly assigned the lower level permissions and responsibilities, as these can be implicitly inherited based upon the roles assigned to the user. Roles can now be defined to consolidate responsibilities and other roles through role inheritance, as well as lower level permissions (functions) and data security policies. This is accomplished through a one-time setup, where all the permissions are assigned to the role. In order to make a mass update in a production system a client only needs to change the permissions or role inheritance hierarchies defined for a role, then all of the users assigned to that role will instantly inherit the new permissions.

TOP

3. What is the difference between a Role and a Group?

Oracle Applications differentiates the concepts of groups and roles to avoid confusion. As we have stated previously, we use the RBAC Reference Model definition for roles, where "a role is a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role."

Groups represent a general collection of users, and possibly other groups, that are brought together for some purpose, not necessarily for access privileges. There are many different sources of groups within Oracle Applications to date. These include, but are not limited to: Roles and Positions as defined in Oracle Human Resource Application, Group Parties as defined in the Trading Community Architecture (TCA), and Resource Groups as defined in Resource Manager.

Arguably, a group can be brought together for some access control purpose. However, within the context of Application Security, only roles should represent job functions within the context of an organization and thereby imply access rights within that organization. Therefore, for the purpose of Application Security, we maintain the distinction between groups and roles.

One important aspect of the RBAC implementation is the ability to leverage the different groups already utilized within Oracle Applications. For example, Roles and Positions as defined in Oracle Human Resource Application, Group Parties as defined in the Trading Community Architecture (TCA), and Resource Groups as defined in Resource Manager, are integrated with the RBAC model. The groups and the group memberships are maintained through the owning application. Using Oracle User Management, clients can assign permissions to these externally managed groups. In the future, these groups can also be hierarchy enabled, allowing clients to assign roles and responsibilities to the groups through role inheritance. Administration of access privileges will be significantly reduced because roles, permissions and responsibilities will be automatically assigned to users as they change positions or groups within the company.

TOP

4. What are Function Security and Data Security?

The base layer of access control within Oracle Applications is Function Security. Function Security restricts user access to the individual menus and menu options within the system. It can also be used to control access to some specific widget (often, graphical in nature) within a page. Each of these various elements is represented in the system as a function, which is also known as a permission. Using the Order Entry page as an example, Function Security could control whether you have the ability to create a new order, or even access the page.

The next layer of access control within Oracle Applications is Data Security.Working in conjunction with Function Security, Data Security provides additional access control on the data a user can see and what actions a user can perform on that data, within Oracle Applications. Using Data Security, for example, you could control access to the set of orders that an order administrator can update within the Order Management application.

Data Security Policies restricts the actions or operations that can be performed on a specific business object. Data Security Policies can reflect access to:

• All Instances–All instances of an object in essence will represent all rows in the database object. For example, assume that we have an object "inventory item" in the database. Creating a data security policy for all instances of our object would result in providing access to every single inventory item we have catalogued in the database.
• An Instance Set–An instance set is a related set of instances of an object. This corresponds to a set of rows for the database object. The set is specified as a predicate on the attributes of the object. The predicate is expressed as a SQL WHERE clause, and can optionally be implemented as a Virtual Private Database (VPD) policy. Using our object example, an instance set could be constructed to include all inventory items with a shelf life of 7 days.
• A Specific Instance–A specific instance generally corresponds to a single row in the database. A specific instance is generally identified by a primary key value for the object. Using our example, we could enter a unique serial number for the inventory item. This would return one and only one inventory item from the database.

For both Function and Data Security, permissions can be granted in one of three ways. Permissions can be granted to all users (global) in the system, this does not include users who are accessing the system via the Guest account. Permissions can be granted to a specific user. Finally, permissions can be granted to a set of users, for example, all users with the Sales Manager role.

Examples of permission assignments that include a data scope in Oracle User Management are:

1. All Instances: Reset Password for <All Users>
2. An Instance Set: Reset Password for Users in <My Organization>
3. A Specific Instance: Reset Password for <John Doe>

Where the data scope is defined within brackets (< >).

TOP

5. Can data security policies be defined for any data information stored in the E-Business Suite schema?

Although administrators can define a data security policy for any data that is stored in the E-Business Suite, the individual E-Business Suite applications must enforce the data security policies. Oracle Applications that leverage Oracle Data Security will enforce the data security policies.

TOP

6. Is Data Security different from Oracle Label Security (OLS)?

Yes. Data Security restricts the access to the individual data that is displayed on the screen once that user has selected a menu or menu option. This is managed through Data Security policies. Oracle Label Security allows database administrators to enforce row level access control within database tables, based on sensitivity labels and clearances. It can be used within the eBusiness Suite to enforce label-based data access control policies on eBusiness data.

Refer to the Metalink Note 234599.1 for information on how to enable Oracle Label Security in the E-Business Suite.

TOP

7. What is a Grant/Permission Assignment?

Permission Assignments reflect the access granted to users through roles. Oracle Applications additionally refers to permission assignments as Grants. Permission assignments may be granted in one of two ways. Permission assignments can provide access to a limited set of data or they can provide access to some set of an application's functionality.

Oracle Applications refers to permission assignments that deal with business objects as Data Security or Data Security Policies. We often refer to these types of permission assignments as "constrained". You should use data security when you want to secure an aspect of a specific business object. For example, you want to limit access to a set of books whose author is Mark Twain.

Oracle Applications refers to permission assignments that deal with some set of an application's functionality as Function Security. We often refer to these types of permission assignments as "unconstrained". You should use function security when you want to secure an aspect of a menu, page or other widget within the application. For example, you want to provide access to a set of administrative menus to a select group of users.

When creating permission assignments, Oracle Applications refers to the subject of the assignment as the grantee. The grantee defines who is being granted access. The grantee can be one of three types:

1. A role or group – this includes all users who are assigned this role or group
2. A specific user – for example, Joe Smith
3. All users (global) – this applies to all users of the system, except the Guest account

TOP

8. What is the difference between a Permission Assignment and a Role?

The Role Based Access Control (RBAC) Reference Model defines permission as "an approval to perform an operation on one or more RBAC protected objects." In the past, we have been referring to a permission as a function, which are operations performed on objects. Examples are: Invoke Service Request Form, Update Order, Approve Expense Report, Query Customers.

We bundle permissions into Permission Sets, which are then granted to users or roles through Permission Assignments. Permission Assignments, therefore, reflect the access granted to users or roles. Permission assignments may be granted in one of two ways. Permission assignments can provide access to a limited set of data or they can provide access to some set of an application's functionality.

TOP

9. What is the difference between Menus and Permission Sets?

We bundle up permissions into Named Sets, which can be defined for two purposes: as Menus and/or Permission Sets. Each Named Set can also contain other Named Sets.

Menus are defined for navigation purposes and group User Interface (UI) pages into functional areas. Users access Menus by selecting Responsibilities. Each menu item maps to a permission which optionally may be granted to the user as part of the menu / responsibility assignment. Menu items that are not granted as part of the menu / responsibility assignment will not be rendered unless the user is granted the permission separately.

Permission Sets are granted to users or roles independently of menus / responsibilities. Permission Sets are granted to users in order to enable menu items and other operations (functions) that should not be available to all users assigned a given menu / responsibility. Permission Sets are granted to users or roles through Permission Assignments, or what in Oracle Applications we have been referring to as Grants.

TOP

10. What are Role Categories and why should I use them?

Role Categories provide a useful classification method for administrators using roles and responsibilities. Administrators can create categories to bundle roles and responsibilities so searching for the various roles and responsibilities is easier. Oracle User Management ships the following role categories: Security Administration and Miscellaneous.

TOP

11. What are Role Inheritance Hierarchies? How are these hierarchies created?

Roles can be included in Role Inheritance Hierarchies. When roles are inherited through role inheritance hierarchies, the various permissions and responsibilities that are assigned to those roles are also conferred to the user.

The Oracle Applications RBAC model supports what is referred to as General Role Hierarchies, which means that any role can have multiple superior and sub-role relationships.

Role Inheritance Hierarchies are created in the Roles & Role Inheritance user interface in the Oracle User Management application. Administrators can nest roles using the Add Role feature. This nesting results in the inheritance of the sub-role by the superior role. This is also true when the administrator is creating role inheritance hierarchies for groups from other source systems (such as Resource Groups as defined in Resource Manager).

TOP

12. Are all external groups hierarchy enabled?

No. In order for administrators to leverage the different groups already utilized within Oracle Applications (such as, Roles and Positions as defined in Oracle Human Resource Application, Group Parties as defined in the Trading Community Architecture (TCA), and Resource Groups as defined in Resource Manager), the owning applications must support the incremental synchronization of their group membership with the Workflow Directory. Additionally, the owning applications should register their group with the Workflow Directory as hierarchy enabled. Once this occurs, clients can assign roles and responsibilities to the groups through role inheritance.

TOP

13. What is Delegated Administration?

Delegated Administration provides traditional System Administrators the ability to delegate some of the user management privileges to people who are closer to the actual end users of the system. These local administrators should be able to manage a subset of the user population, and only the set of access privileges relevant to their functional area.

Access control in Oracle Application allows administrators to be designated at any level, internally within the enterprise as well as externally. Clients could internally designate administrators at division or even department levels, and then delegate administration of external users to people within those (external) organizations.

TOP

14. How do I define my own delegation policies?

Delegation policies are defined as data security policies. The set of data policies that are defined as part of delegated administration are known as the Administration Privileges.

Administration Privileges determine what users and roles the delegated administrator can manage. There are three aspects to administration privileges: roles, users, and organization. Each privilege is granted separately, yet the three work in conjunction to provide the complete set of abilities for the delegated administrator. These privileges can be defined along with the role definition in the Role & Role Inheritance user interface in Oracle User Management.

TOP

15. What is a Registration Process?

Registration Processes enable organizations to provide end-users with a method for requesting various levels of access to the system, based on their eligibility. They also simplify an administrator's job by providing streamlined flows for account maintenance and role assignments. Registration processes also allow you to specify approval routing rules, notifications, identify verification and eligibility criteria, where desired.

Oracle User Management supports three types of Registration Processes:

1. Self-Service Account Requests—provides a method for persons to request a new user account. For example, a customer may need to register before they can purchase an item from an online store. Once the person has completed the registration process, they will have a user account as well as the necessary role(s) needed to access some portion of the website where they registered. This type of registration process also offers identity verification, which confirms the identity of the requester (via an email notification that requires a response) before the registration request is processed. If the recipient does not reply within a predetermined amount of time the request will be automatically rejected.
2. Requests for Additional Access—Oracle User Management provides an Access Request Tool that enables existing users to request additional roles. Users can only request the additional roles that have been defined as appropriate based on their current roles. For example, you can configure Oracle User Management so that all users with 'Employee' role are eligible to sign up for a 'Sales Representative' role, while customers are not eligible to sign up for this role. However, everyone can sign up for iRecruitment for job postings. An administrator assigning a role to a user is essentially fulfilling a registration request on behalf of the user, thereby invoking a Request for Additional Access Registration process, if defined.
3. Account Creation by Administrators—provides administrators (including delegated administrators) the ability to create user(s). Each account creation registration process can be made available to select administrators.

Registration processes have several advantages. They streamline the registration process for both end users requesting new or additional access, as well as for administrators. They enable applications to use the same infrastructure to meet their varied registration requirements giving you a uniform administration experience across all applications in the suite.

You can define specialized registration processes (including separate user interfaces) that capture specific information required as part of your organization's policies.

Each registration process comprises the following information:

• The type of registration.
• The role(s) assigned after the user successfully completes the process.
• A description of the purpose of the registration process.
• An optional registration user interface for collecting account or additional information.
• A workflow for approval, confirmation, rejection, and identity verification notifications.
• The Approval Management Transaction Type. A transaction type represents a set of approval routing rules that are interpreted at runtime.
• The set of users that are eligible to sign up for additional access (only applicable for Request for Additional Access Registration Processes).
• If identify verification is required (only applicable for Self-Service Account Requests). Identity verification confirms the identity of a requester before the registration request is processed. An email notification is sent to the submitting email address. If the recipient does not reply within apredetermined amount of time the request will be automatically rejected.
• The set of local administrators that should be able to register people and/or create users through the Account Creation by Administrators Registration Process.

Oracle User Management ships the following registration processes as examples for customers:

• Individual User Registration (UMX_EXT_INDIVIDUAL) – This registration process allows external individuals (consumers or any other person with no specific relationship to or representation of a business entity) to self-service register for a user account. The registration process type for this registration process is Self Service Account Request.
• External Organization Contact (UMX_EXT_ORG_CONTACT) – This registration process could be used by administrators to register new people / users representing External Organizations (Suppliers, Customers, etc). The registration process requires the administrator to have been granted Organization Administration Privileges. The registration process type for this registration process is Account Creation by Administrators.
• Employee Registration (UMX_EMPLOYEE) – This registration process allows internal employees already entered in the HR system to self-service register for user accounts. Employees identify themselves using their email address and employee number. User Names will be assigned based on the user name policy (out of the box: email address). The registration process type of this registration process is Self Service Account Request.

Oracle User Management additional ships the Account Creation for Existing Person (UMX_USER_4_EXISTING_PERSON) registration process for use in the User Administration pages. All administrators desiring to create user accounts for existing people in the system can use this registration process. The registration process type of this registration process is Account Creation by Administrators.

TOP

16. Do Registration Processes create RBAC policies?

Yes. According to the National Institute of Standards and Technology (NIST) "an RBAC policy is based on the functions or the actions that a user is allowed to perform within the context of an organization" (ANSI INCITS 359-2004). Registration Processes create Role Assignments, which are equivalent to RBAC policies, as these Role Assignments control the actions or access for a user.

TOP

17. Can I define my own registration processes?

Yes. For each of the registration process types, Oracle User Management provides the ability for customers to create their own registration processes per their own business requirements.

TOP

18. Can I define my own registration user interfaces (UIs)?

Yes. Oracle User Management supports the ability to createregistration user interfaces for collecting account or additional information. Clients can associate a different set of registration UIs with each registration processes they create.

TOP

19. What is the User Management Registration Engine?

The Oracle User Management registration engine controls all registration processes. The registration engine leverages Oracle Workflow in order to define the business logic that drives the registration process once a request has been submitted. The workflow process controls:

• Raising business events associated with registration events
• Providing temporary storage of registration data
• Processing identity verification
• Enforcing username policies
• Integrating with Oracle Approval Management for the approval routing rules
• Creating user accounts
• Reserving/releasing usernames
• Assigning the appropriate roles
• Maintaining the registration status
• Launching notification workflows, as defined

TOP

20. Does User Management raise Workflow Business Events? How can I leverage these?

Yes. Oracle User Management raises Workflow Business Events in the following cases:

• When a role is requested.
• When an account is requested.
• When an account or role is approved.
• When an account or role is rejected.
• A special business event for the owner of the registration process to write the registration information to the appropriate schemas.

All information retrieved in the registration process and the registration context such as application ID, role code, and registration service code, are included when these events are raised. Clients can subscribe to these Workflow Business Events and leverage the information gathered as desired. For more information on subscribing to Workflow Business Events, refer to Metalink Note #139745.1.

TOP

21. What is Eligibility?

Existing users may request additional role(s) through the Oracle User Management Access Request Tool (ART), depending on their eligibility. The ART is accessible from the Preferences menu. Eligibility defines what Roles a user can request and is defined in the Request for Additional Access Registration Process. For example, employees can be eligible to sign up for a 'Sales Representative' role, while customers will not be eligible to sign up for this role. However, everyone can sign up for iRecruitment for job postings.

TOP

22. Are Administrator Account Creation Registration Processes available to all Administrators?

No, not all Administrator Account Creation Registration Processes are available to all administrators. While administrators can benefit from these registration processes, designed to streamline the process of creating and maintaining user accounts, each registration process must be granted to the appropriate set of administrators.

TOP

23. Where does the registration information go before it is approved?

For all registration processes Oracle User Management provides a mechanism to store the registration data in a pending state until the request is approved. This data is available to the workflow notifications used for sending approvals, to Approval Management transactions, and to the business logic that writes the information in the final destination tables. Oracle User Management accomplishes this by using event objects that are part of the Workflow Business Events infrastructure.

TOP

24. Can I define my own Workflow notifications? Can they be different for different roles?

Yes. As part of defining a registration process, clients can define their own workflow notifications and link these to the role specified in that registration process. The notifications defined can be different for each registration process.

Notifications include:

• Approver notifications
• Approval confirmation notifications
• Rejection notifications
• Identify verification notifications

Oracle User Management launches the notification workflow associated to the registration process whenever the Oracle Approval Management rules engine determines that an approval is required. The approver can review the information submitted in the registration process, make changes, and provide additional information if required. Any changes or additional information provided are passed to Oracle User Management for further processing. For example, with requests for iSP (Internet Supplier Portal) access, additional information about site and contact restrictions for the requester could be provided by the approvers. Information entered by previous approvers, including comments, are available to subsequent approvers. Oracle User Management provides sample notification workflows that customers can use directly or can extend based on their requirements.

TOP

25. What is the confirmation number that is displayed whenever a request is submitted and what does this mean?

Once a request has been submitted via a registration process a confirmation number will be provided. This confirmation number (ITEM_KEY) represents the number of the workflow process for that request. Using this number, the requestor and administrators can track the request status and view any additional information, as provided.

TOP

26. What is Oracle Approval Manager and how it is linked to Oracle User Management?

Oracle Approvals Management is a highly extensible approvals rules engine that allows customers to simply and effectively define business rules that determine transaction approvers. Customers can devise simple or complex rules. The defined rules are stored in a central repository to facilitate management and sharing between business processes. The rules engine has been designed with flexibility and performance as the key cornerstones of its architecture.

For additional information about Oracle Approval Management, please refer to the Oracle Approval Management Implementation Guide available on Metalink (#227391.1).

TOP

27. Can I define my own approval routing rules?

Oracle User Management integrates with Oracle Approval Management, which provides a central repository for all of the business rules that determine transaction approvers. Using Oracle Approval Management, organizations can create complex rules with priorities, conditions, and various attributes.

For additional information about Oracle Approval Management, please refer to the Oracle Approval Management Implementation Guide available on Metalink (#227391.1).

TOP

28. I have different web sites for different countries. Can I route my approval requests depending upon where an account request originated?

User Management provides support for displaying different registration links on the login page based upon which mid-tier the login page is accessed through. The registration link can contain additional parameters that are not known at design time, such as the country code. These additional parameters can be used later during the registration process. Using the country code example, a registration process could route the approval requests to the appropriate approver. Therefore, all people who request an account from Norway will be routed to a Norwegian account approver.

Please refer to question #31 for information on how to include these additional parameters in the registration link provided on the applications login page.

TOP

29. What is a User Name Policy?

Oracle User Management supports the ability to define a policy that generates user names based on custom rules. These rules are defined in an Oracle Workflow, Oracle User Management: User Name Policy. The default shipped with Oracle User Management uses the e-mail address of the user as the user name. The User Name Policy feature is a synchronous workflow process that can easily be customized. You can modify the workflow process to generate usernames based on any information captured in the registration flows or stored in the E-Business Suite.

TOP

30. How does the Forgot Password work?

Oracle User Management includes a "Forgot Password" feature that can be used by local users (users whose passwords are not managed in the Oracle Internet Directory LDAP server) to request a password reset. The Forgot Password feature requires Identity Verification; the owner of the user account must confirm via email that the password should be changed.

The Forgot Password feature is implemented via Oracle Workflow, Oracle User Management: Password. Clients can customize the workflow messages that are sent to the end user as part of the password reset.

TOP

31. How do I enable the various features on the Login page?

Oracle Applications provides the ability to include several optional attributes in the login page. The attributes are as follows:

• Username Hint
• Password Hint
• Cancel Button
• Forgot Password Link
• Register Here Link
• Language Images
• Sarbanes Oxley Text

These attributes are controlled via a single profile option, "Local Login Mask" (FND_SSO_LOCAL_LOGIN_MASK).

In order to display one of more of these optional attributes on the Login page, add the numeric values of all desired attributes and then set the value of the profile option to that value.

The following list details the numeric values for each of the attributes:

• Username Hint = 01
• Password Hint = 02
• Cancel Button = 04
• Forgot Password Link = 08
• Register Here Link = 16
• Language Images = 32
• Sarbanes Oxley Text = 64

If a client wanted to display the password hint and forgot password attributes on the login page, then the profile value should be set to 10 (02+08). In order to display just the language images, set the profile value to 32, which is the default.

Oracle User Management provides supportfor displaying different registration links on the login page based upon which mid-tier the login page is accessed through. Customers can set the server level profile option, "UMX: Register Here Link: Default Registration Process" (UMX_REGISTER_HERE_REG_SRV) to specify different destinations for the registration link.

The registration link can also contain additional parameters that are not known at design time. These parameters can be used at any stage of the registration process. For example, to route approval requests (see question #28). Customers can set the server level profile option, "UMX: Register Here Link: Default Registration Parameters" (UMX_REGISTER_HERE_REGPARAMS) for this purpose.

Customers can additionally specify some parameters used to control the rendering of the registration user interface, such as what menu should be displayed throughout the registration flow. The server level profile option, "UMX: Register Here Link: Default Html Parameters" (UMX_REGISTER_HERE_HTMLPARAMS) can be set for this purpose.

TOP

32. Is Oracle Human Resources required to implement Oracle User Management?

No. Oracle Human Resources Management is not required in order to implement Oracle User Management.

TOP

33. What happens when I upgrade to Oracle User Management in 11.5.10?

All new features provided by Oracle User Management are available as optional features when upgrading to 11.5.10. Customers can choose to leverage any or all of these features as desired.

If you do not wish to leverage the roles functionality, you can still leverage many of the key Oracle User Management features. You do not have to uptake the new roles functionality if you wish to leverage the following features in Oracle User Management in release 11.5.10:

• Administer Users via the User Administration user interfaces
• Registration Processes
• Delegated Administration
• Self-Service Requests
• Approvals

TOP

34. Is my customer a candidate for the Strategic Implementation Program (SIP)?

Oracle User Management is currently soliciting nominations for candidates to be Strategic Implementation Program (SIP) partners. This program strives to ensure a smooth implementation of an E-Business product for a group of key strategic customers.

The ideal candidate would possess the following:

• Ready to install and utilize Oracle User Management with 11.5.10
• Valid Oracle Support contract
• Consulting and account team participation
• Willing to participate in reference activities
• Executive commitment (Customer & Oracle)
• Additional SIP requirements (see SIP)

Please contact your Oracle representative for additional information about this program.

TOP

35. What Oracle Applications leverage Oracle User Management and RBAC in 11.5.10?

Oracle User Management was introduced in the 11.5.10 release. Oracle Applications currently are in the process of leveraging the Oracle User Management features, including the Role Based Access Control feature, for future release.

TOP

36. How can I learn more about Oracle User Management?

For more information on the Oracle User Management, please contact: umx_us@oracle.com.

TOP