|Oracle Projects Fundamentals|
Part Number E13581-04
This chapter discusses the various security structures used by Oracle Projects: project security, responsibility–based security, and organizational security.
This chapter covers the following topics:
Oracle Projects uses an integrated set of security mechanisms to control function and data access within Projects applications. These mechanisms are:
Oracle Projects provides several integrated security mechanisms to help you define user access to organization, project, and resource information, as well as a variety of Oracle Projects functions. These mechanisms are all based on function security, which is the foundation of Oracle Applications security.
Using these integrated security mechanisms, you can define Oracle Projects security at the following levels:
Responsibility level, across projects.
Project level, using project roles.
Organization level, using predefined organization authority roles.
Note: You can override Oracle Projects security by using the security client extension.
The strategy you use to secure data in Oracle Projects depends on how your company manages projects and the levels of access you want to provide to your users. Before you set up your security features, take time first to consider the types of users you have and the levels of data and function access that you think they should have. This chapter is designed to help you determine how you want to set up security for your enterprise.
All the security mechanisms of Oracle Projects are built on function security. Responsibility-based security, project security, and organization security all determine the sets of functions that are available to users. Function security controls which of those functions the users can perform.
For detailed information about function security in Oracle applications, see Overview of Function Security, Oracle Applications System Administrator's Guide.
For a list of Oracle Projects functions that can be controlled using function security, see Function Security in Oracle Projects, Oracle Projects Implementation Guide: Appendix A
A menu defines the list of functions that are available to a responsibility. You use menus to assign groups of functions to either responsibilities or roles. Menus can include submenus to organize large groups of functions.
You can only assign one menu to a responsibility or role at a time. The only exception to this rule applies when you use role-based security by project status. In this case you create separate function menus for each project status and then assign each of these menus to an individual role.
For more information about menu usage in responsibility-based security, see Responsibility-Based Security.
For more information about menu usage in role-based security, see Using Project Security.
For more information about role-based security by project status, see Role-Based Security by Project Status.
For more information about creating function menus, see Project and Organization Security, Oracle Projects Implementation Guide.
The multiple organization access control (MOAC) feature enables users to enter and process transactions in two or more operating units without switching responsibilities.
You must define a security profile in Oracle HRMS and assign it to the profile option MO: Security Profile at the responsibility level to provide multiple operating unit access to a responsibility. You can use individual operating units and/or organization hierarchies with organizations classified as operating units while defining the security profile. Users associated with responsibilities that have been set up in this manner can enter and process transactions in multiple operating units without changing their responsibility.
If the MO: Security Profile option grants a responsibility access to an operating unit that does not have Oracle Projects implemented, then that operating unit will not be displayed in the operating unit list of values on the Projects windows or pages. However, the operating unit list of values in the Implementation Options window will display all the operating units that the user has access to. You can implement Oracle Projects for that operating unit here.
Whenever you make changes to the security profile in use, including the addition or deletion of operating units, you must subsequently run the Security List Maintenance process (PERSELM) in Oracle Human Resources.
The MO: Operating Unit or the MO: Security Profile profile options determine the list of operating units the user has access to for a responsibility.
When you have access to more than one operating unit based on the operating units assigned to the MO: Security Profile profile option, you can define the MO: Default Operating Unit profile option. This profile option determines the default operating unit that will be displayed in the Operating Unit field.
If the MO: Security Profile profile option is not defined, then the operating unit assigned to the MO: Operating Unit profile option is used as the default operating unit.
If the MO: Security Profile profile option is defined, and a responsibility has access to only one operating unit through this profile option, users with that responsibility will see that operating unit as the default operating unit.
Note: The MO: Operating Unit profile option was used in earlier versions of Oracle Projects that did not include Multiple Organization Access Control. When you set the MO: Security Profile option for a responsibility, it overrides the MO: Operating Unit value. But if you do not set any value for MO: Security Profile option, you still need to define MO: Operating Unit profile option.
The following table shows examples of how the operating unit field will be populated if the MO: Operating Unit, MO: Security Profile, and MO: Default Operating Unit profile options are either set with values or left blank.
|MO: Operating Unit||MO: Security Profile||MO: Default Operating Unit||Operating Units Displayed|
|No||Yes (Vision Services, Vision Services R&D, Vision Project Manufacturing)||Yes (Vision Services)||Default OU =Vision Services. Other OUs = Vision Services R&D, Vision Project Manfacturing|
|No||Yes (Vision Services)||No||Default OU = Vision Services|
|Yes (Vision Services)||No||No||Default OU = Vision Services|
|Yes (Vision Services R&D)||Yes (Vision Services, Vision Services R&D, Vision Project Manufacturing)||Yes (Vision Project Manufacturing)||Default OU = Vision Project Manufacturing, Other OUs = Vision Services, Vision Services R&D|
|No||Yes (Vision Services, Vision Services R&D, Vision Project Manufacturing)||No (not present in security profile. For example in Progress S&L)||No Default OU. All OUs = Vision Services, Vision Services R&D, Vision Project Manufacturing|
The first row in the table can be explained as follows. The MO: Operating Unit profile option is not set, but the MO: Security Profile profile option is set for the operating units, Vision Services, Vision Services R&D, and Vision Project Manufacturing. Similarly the MO: Default Operating Unit profile option is set for the operating unit Vision Services. In this example, the operating unit field will be populated with Vision Services as the default value. However, you will also find Vision Services R&D, and Vision Project Manufacturing operating units in the list of values.
Under responsibility-based security, a user's login responsibility determines which functions the user can perform. Each responsibility limits user access to information within the operating unit(s) with which it is associated, by setting either the MO: Operating Unit profile option or the MO: Security Profile profile option. By setting the MO: Security Profile profile option, you can enter and process transactions in two or more operating units, without changing responsibilities. You assign functions to menus and the menus to responsibilities. Therefore, the responsibility of a user determines what functions the user can perform.
For detailed information about responsibility-based security, see Responsibility-Based Security, Oracle Projects Implementation Guide.
With the following profile options, users can be granted access to projects and resources without having a direct relationship with either of them::
PA: Cross Project User -View: Enables users to view all project information. . It gives view access to all projects across all the operating units.
Note: In Forms applications, it gives view access to projects in the operating units the responsibility has access to.
PA: Cross Project User - Update: Enables users to update all project information. This applies only to the operating units the responsibility has access to through the MO: Operating Unit profile option or the MO: Security Profile profile option.
PA: View All Project Resources: Enables users to view resource information for all resources across multiple operating units. This profile option is typically enabled for people who use Oracle Project Resource Management to staff and schedule resources for projects. For more information, see the Oracle Project Resource Management Implementation Checklist: Oracle Projects Implementation Guide.
Note: Users whose responsibilities are associated with a cross business group access security profile can view and update project and resource information across all business groups in your enterprise. For more information, see Security Profiles, Oracle Projects Implementation Guide.
For more information about providing additional profile options in conjunction with responsibility-based security, see: Defining Additional User-Level Security, Oracle Projects Implementation Guide.
You can use project security to add several layers of security to the basic responsibility-based security structure. Project security involves project roles and project access levels. Security access to project information can also be affected by issue and change management as well as project status reporting functionality.
This section provides an overview of these aspects of project security. It also explains how you can use the Project Security Extension to override project security.
Note: The elements of project security discussed in this section apply only to the portions of Oracle Projects applications that use the HTML architecture of the Oracle Applications Framework. Oracle Projects functionality using non-HTML architecture relies solely upon responsibility-based security.
Role-based security enables you to control access to functions on a project based on the role the user plays on a project team. Under role-based security, menus are assigned to roles. The access assigned to a role is available to the user for the duration of the user's role on the project.
Roles that have menus assigned to them are considered to be secured roles by the system. Unsecured roles--roles without a menu assignation--use the responsibility menu to determine their security access.
Role-based security provides more flexibility than responsibility-based security because it is project-specific. Users can play different roles on different project teams. This means that the function access granted to the user can be different for each project.
For example, you can assign a user a project lead role for Project A in the first half of the year and a consultant role on Project B for the second half of the year. Because the two roles are associated with different menus, they can have completely different role-based security access.
Responsibilities, on the other hand, control access at the application level. They give users a broad range of function access that can extend across organizations, resources, and projects. They are not designed to provide function security access at the individual project level.
Note: Role-based security overrides responsibility-based security for individual users. The system applies responsibility-based security to users that have not been assigned project roles, as well as to users that have project roles without corresponding function menu assignations.
For more information about responsibility-based security, see Using Responsibility-Based Security.
For more information about function security and function menus, see Function Security: The Building Block of Oracle Projects Security.
A project role is a collection of default information about a team member on a project, such as competencies, job information, and security. You create project roles to represent the typical team member roles needed for projects within your organization. Examples of project roles include project manager, project administrator, database administrator, and consultant. Each role can have a different set of competencies, job information for forecasting and menu to control security access to projects.
For more information about roles, see Defining Project Roles, Oracle Projects Implementation Guide.
You use role controls to control usage of a role. Role controls can also control users' ability to view project labor costs.
The following predefined controls are available:
Allow as Project Member: enables the role to be a project member. You can select this role at the time of adding key members and team members to a project.
Allow as Task Member
Allow as Contract Member: this role is enabled if you have a license for Oracle Project Contracts. For more information, see Oracle Project Contracts Implementation Guide.
Allow Scheduling: enables users with this role to create scheduled resource assignments on projects
Allow Labor Cost Query: enables users to view the raw labor cost details
You can assign as many of these controls to a given role as necessary. Because you assign roles to users at the project level, you must, at a minimum, assign the Allow as Project Member role control to each role.
Note: The Allow as Task Member role control is not enabled.
When you set up role-based security for a role by associating it with a menu, you can optionally include an additional layer of security control based on project status. This additional security layer enables you to use the status of the project as another way of determining access to specific functions related to that project. For example, you can give project managers the ability to update assignment rate information for projects while they are in the sales pipeline with a "submitted" status, and then prevent them from updating that information after those projects are approved. Once the projects are approved, your project's financial managers should own the ability to update that information.
When you use standard role-based security, you define one security menu for each role. The security menu controls function security for all projects, regardless of their project status.
When you use role-based security by project status, you can define multiple security menus for each role: one menu for each project status value. This enables you to control function security by both role and project status. You can use either the system project status values or a set of user-defined project status values.
You are not required to define a security menu for every project status value. If a project status value does not have a menu associated with it, the system uses the security menu associated with the role.
You set up role-based security by project status at the role level, on an individual role-by-role basis. This functionality enables you to set up role-based security by project status for some roles and not others.
You can additionally use access levels to control who can search for and view projects and project templates. You set access levels for projects and project templates on the Basic Information page. If you have the appropriate authority on a project you can set one of the following access level values for it:
Secured: Indicates that the project is secured. The project can be viewed only by users with either secured or unsecured roles on the project and by users with organization authority roles. Users with responsibilities that give them view all projects or update all projects access can also access secured projects.
Enterprise: Indicates that the project can be viewed by any user in your enterprise, regardless of their role, responsibility, project assignment, or organization authority. A guest role menu determines what enterprise project information users can view. Your implementation team can modify the guest role menu to increase or decrease the amount of access users have to enterprise project functions.
You can use the UPG: Update Project Access Level concurrent program to update the access level of several projects at once.
For more information about setting up basic project information, see Project Information..
For more information about the UPG: Update Project Access Level program, see Processes.
Oracle Projects' issue management functionality and change management functionality can provide another kind of security access to functions. With issue management and change management, users with appropriate authority, such as super users, users with organization authority, and project managers can create issues and changes and designate owners for them. These owners can in turn oversee the progress, resolution, and closure of issues and changes.
For more information about issue management, see Overview of Issue Management, Oracle Project Management User Guide.
For more information about change management, see Using Change Management, Oracle Project Management User Guide.
The Project Security extension enables you to override the default security and implement your own business rules for project and labor cost security.
The Project Security extension only applies to the non-HTML architecture of Oracle Projects applications. It does not apply to Oracle Applications Framework functionality.
For a detailed description of the project security extension, see: Project Security Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.
Organization authority enables you to specify security access for users at an organizational level when their position requires them to oversee all of the projects or resources within one or more organizations. Organization authority can provide access to all projects, all resources, all forecasting, or all utilization information for the specified organization, depending upon the type of organization authority you choose.
You must specify each organization for which a user has organization authority and then specify what type of authority the user gets for those organizations.
Note: Organization authority does not acknowledge organizational hierarchies. For example, if a user has resource authority over a top organization, then the user does not automatically have resource authority for all organizations subordinate to the top organization. You must specify each organization for which a user has resource authority.
The following table lists describes the four available types of organization authority and describes the information access they provide:
|Project Authority||Enables a user to perform all functions on all projects in the organization.|
By default, the function security menu for Project Authority is the same as the function security menu for the Project Manager role. Your implementation team can update the Project Authority menu according to the needs of your enterprise.
The difference between Project Authority and the Project Manager role is that the project manager must be assigned to a role on each project within the organization. Project Authority can be assigned to a user just once to cover all projects within an organization.
|Resource Authority||Provides security access that is similar to the access provided by the Resource Manager role.|
Enables a user to perform tasks, such as nominate candidates, create and approve candidates, and view resource utilization for all resources throughout the entire organization.
|Utilization Authority||Enables a user to calculate and view utilization for all of the resources in the organization.|
Each organization authority is associated with a predefined menu. When you grant a user any type of organization authority, you are giving that user the function security associated with that menu for the specified organization. Organization authority is essentially role-based security at the organization level.
For more information about defining authorities and primary contacts, see Organizational Authority: Oracle Projects Implementation Guide.
To access multiple operating units without switching responsibilities, you need to define a security profile and assign it to MO: Security Profile profile option.This security profile is defined at the responsibility level.
For more information about providing multiple organization access, see Providing Multiple Organization Access.
Oracle Projects calls a security check process when a user attempts to perform an action. This process searches for the appropriate permissions to allow the user to perform the requested action.
Security Check Example
As shown in the figure Security Check Example, the logic of the security check process is as follows:
When a user attempts to perform a function in Oracle Projects, the system starts by checking to see if the function is related to a project.
If the function is related to a project, the system moves to Step 2.
If the function is not related to a project, the system moves to Step 5.
If the function is related to a project, the system checks whether the user has a role on the project.
If the user has a role on the project, the system moves to Step 3.
If the user does not have a role on the project, the system checks the access level of the project.
If the project's access level is set to Enterprise, the user is given the predefined secured guest role on the project and the system moves to Step 3.
If the project's access level is set to Secured, the system checks whether the user has organization authority over the organization to which the project belongs or cross-project access at the responsibility level.
If the user has access to the secured project the system moves to Step 6.
If the user does not have access to the secured project the user cannot perform the action.
If the user has a role on the project, the system checks whether the user has a secured role on the project. A secured role is a role that is associated with a function security menu.
If the user has a secured role on the project, the system moves to Step 4
If the user does not have a secured role on the project, the system moves to Step 6.
If the user has a secured role on the project, the system checks whether or not the user's role-based security access is associated with project status.
If the user's role-based security is associated with the project status, the system determines whether the security menu associated with the current project status includes the function required to perform the action.
If the menu includes the function required to perform the requested action, the user can perform the action.
If the menu does not include the function required to perform the action, the system moves to step 6.
If the user's role based security is not associated with the project status, the system moves to step 5.
The system checks whether the function security provided by the user's role enables the user to perform the action.
If the user's role-based function security menu includes the function required to perform the requested action, the user can perform the action.
If the user's role-based function security menu does not include the function required to perform the action, the system moves to step 6.
The system checks whether the user has appropriate function security through organization authority to perform the action.
If the user has appropriate function security, the user can perform the action.
If the user does not have appropriate function security, the system moves to step 7.
The system checks whether the user has appropriate function security through the user's assigned responsibility.
If the user has appropriate function security, the user can perform the action.
If the user does not have the appropriate function security, the user cannot perform the action.
Note: Issue management, change management, project status report functionality, and other Oracle Projects features can provide users temporary access to certain functions that overrides the rules of the security check.
Oracle Projects provides public APIs that enable you to define rules to control the update of data which is imported to Oracle Projects from an external system. For information on this topic, see: API Controls, Oracle Projects Implementation Guide.
Copyright © 1994, 2010, Oracle and/or its affiliates. All rights reserved.