Whitepaper Function Security in Oracle Projects 13-AUG-12

Oracle White Paper Updated, August 2012 Function Security in Oracle Project Management Function Security White Paper Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Function Security in Oracle Projects Executive Overview ........................................................................... 2 Introduction ....................................................................................... 2 Glossary ............................................................................................ 3 Function Security ........................................................................... 3 Menus ........................................................................................... 3 Responsibility-Based Security ....................................................... 3 Project Security ............................................................................. 3 Organization Authority ................................................................... 4 Cross Project Access .................................................................... 4 Roles ............................................................................................. 4 Role Controls ................................................................................. 4 Using Function Security ..................................................................... 5 Access Levels ................................................................................... 6 Using Role Based Security ................................................................ 6 Granting Organizational Authority ...................................................... 7 Recommended Practice for Role Based Security on a Project .......... 8 Security Checking ............................................................................. 9 Troubleshooting ............................................................................... 11 Function Security in Oracle Projects 2 Executive Overview Oracle Project Management is an effective and comprehensive set of tools used by customers around the world to manage medium to large-scale projects. Securing user access to project information and the ability to perform project activities is a critical step in your implementation. When deploying Oracle Project Management (Oracle Projects or “OP”), you can restrict users from performing selected functions based on their system responsibility, their project role or their role or responsibility in your organization. Seeded roles and responsibilities make it easy for you to setup new responsibilities and roles that you can assign to new users. This whitepaper is intended to help you determine the best way to setup and use OP security functions and describe how they are used to define access for responsibilities and roles. You can also find useful information describing how to setup and use OP in the standard User and Implementation Guides. Introduction In addition to the standard eBusiness Suite responsibility based security model, Oracle Projects provides a role based security model to help you define user access to organizations, projects and resource information and to perform project related activities. These definitions are based on the configuration of function security menus that you assign to a role or responsibility. Security functions can be assigned at the following levels:  Operating Unit; based on user responsibility  Project; based on project role  Organization; based on organization authority rules Before you set up your security definitions, consider the types of users who will access your system, the data they need access to and the project activities for which they are responsible. Function Security in Oracle Projects 3 Glossary Function Security Security definitions in Oracle Projects are based upon secured functions. 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. Menus A menu defines the list of functions that are available for a responsibility or role. Use menus to assign groups of functions to a system responsibility or project role. Menus can include submenus to organize large groups of functions. Unless you implement role-based project security based upon project status, you can only assign one menu to a responsibility or role. When you use role-based security by project status, you create separate menus for each project status and then assign each of these menus to a project role. Responsibility-Based Security Responsibility-based security applies at the operating unit level and can provide access across suite-wide products or projects. The responsibility tied to a user’s log in determines the menu that is available to the user and thereby 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. When you set the “MO: Security 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. Project Security You can use project security to expand a user’s access based upon a user’s project role and access level. Project security does not replace or override any values defined for a responsibility. 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 Function Security in Oracle Projects 4 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. Organization Authority 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. You do not have to assign roles to users with organizational authority. You can grant view or update access based to a user and then assign the appropriate menu. The user will have view or update access to all projects in the organization for the functions assigned in the selected menu. Organization authority does not acknowledge organizational hierarchies and you must specify each organization over which the user has authority regardless of where the organization is in hierarchy. Cross Project Access When a user needs to have full access to all projects for viewing or updating, you can grant them Cross Project Access. By setting the profiles “PA: Cross Project User – View” or “PA: Cross Project User – Update” you can grant access to projects without having direct relationship with any project or organization. This enables the users to view or update all projects information across all the operating units. Roles 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. Role Controls You setup role controls to determine how the role can be used to control security. The following predefined controls are available:  Allow as Project Member: This option enables the role to be used to define a project member. You can select this role at the time of adding key members and team members to a project. Function Security in Oracle Projects 5  Allow as Task Member: This option enables the role to be used to define a task member. You can select this role at the time of adding key members and team members to a project. You must set the profile option “PA: Task Managers must be Project Members” to ‘Yes’ in order to enable this option.  Allow as Contract Member: This role option is enabled if you have licensed Oracle Project Contracts. For more information, see Oracle Project Contracts Implementation Guide.  Allow Scheduling: This option enables the role to be used for scheduling resource assignments on projects.  Allow Labor Cost Query: This option enables the role to view the raw labor cost details in project expenditure inquiries. You can enable more than one control to a role. 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. Using Function Security Function security controls the activities users can perform on a project. The functions are organized into menus and you associate menus to responsibilities, roles or you grant them to a user when assigning Organizational Authority. By associating a responsibility and a role to a user or granting them Organizational Authority, you grant the activities or privileges of the functions in the menu to the user. The security functions are organized by functional areas. Some of these functions include:  Budgeting and forecasting  Costing  Financial structure  Page layout  Project  Workplan Function Security in Oracle Projects 6 Refer to the Oracle Projects Implementation Guide, Function Security, Appendix A for full list of functions that you can control using function security. Access Levels In addition to controlling access to functions, you also control the level at which a user can access the projects in your organization. If you grant a user Cross Project Access, the user has the highest access level and can view or update all projects in all operating units. You can grant view access, update access or both by setting one or both of the following profile options:  PA: Cross Project User – View  PA: Cross Project User – Update The next level of authority is Organization Authority. If you grant a user the Project Authority type of Organization Authority, the user has access to all projects in the specified organization for the functions assigned to the menu selected (by default the Project Manager menu is assigned). You do not have to assign roles to users with organizational authority. The third level of access is based on the menu you assign to the user’s responsibility. All functions assigned to the menu associated to a user’s login responsibility can be performed on projects associated to the operating unit. This access cannot be restricted by the user’s role on the project, so you should only grant responsibility access for the common functions to be performed by any user with the selected responsibility. The lowest level of access is based on the role the user performs for a specific project. When you assign a role based security menu, users must have a role on a specific project to perform the assigned functions . You can also assign menus based on project status, so users can only perform the functions in the menu based on the project’s status. Using Role Based Security User responsibilities control access at the application or site level and you manage responsibilities using the standard Oracle security model. Responsibilities 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. Function Security in Oracle Projects 7 Role-based security provides you the ability to refine your security definitions beyond the security defined by a responsibility because it is project-specific. Because you can define a role for a user that is specific to a project, the function access granted to the user can be different for each project. For example, you assign a user a Project Lead role for Project A where they perform a variety of functions that only the Project Lead can perform. You also assign the same user as a Consultant on Project B. The user will not be able to perform the Project Lead functions for Project B. Roles can be secured or unsecured. Roles with assigned menus are considered secured roles since the menu determines the activities the user can perform on the projects to which they are assigned. Unsecured roles are simply roles you use to describe the project team. Unsecured roles are not associated with a menu and the security function menu is derived only from their system responsibility. Role based menus cannot be used to generate the actual user interface page/tab structure. The interface page/tab structure is always and only controlled by menus attached to the users’ responsibility. Role-based security definitions have precedence over responsibility-based security definitions for granting access to 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. However, role-based security definitions do not restrict access to the security function menu assigned through the responsibility. Role-based security definitions can only broaden the menu of security functions for a user with the defined role. For example, if the Project Team Member responsibility is given access only to view the workplan in the security function menu but the Team Member role is given both view and update workplan security functions in the Team Member menu the user will have the ability to update the workplan. If the Project Team Member responsibility is given access to both view and update security functions, but the Team Member role is only given view access, the user will be able to update the workplan since the privilege is granted to their responsibility. Granting Organizational Authority Organization Authority is similar to role based security access at the organization level. It can provide access to all projects, resources, and utilization information for the specified Function Security in Oracle Projects 8 organization. You must specify each organization for which a user has authority and then specify what type of authority the user has for those organizations. You use the Organization Authority page to grant authority to a user and assign a menu to define the approved functions. Oracle Projects provides three types of Organization Authority: Project Authority – This type of authority enables a user to perform functions on all projects in an organization, such as project definition, staffing, workplan creations, and financial planning. By default, the function security menu for Project Authority is the same as the function security menu for the Project Manager role, but the menu can be modified. Resource Authority – Enables a user to view and update information for all resources in an organization. For example, with resource authority you can assign resources to any project in an organization. Utilization Authority - Enables a user to calculate and view utilization for all of the resources in the organization. Recommended Practice for Role Based Security on a Project You should only provide Organization Authority or Cross Project Access to users when their role requires them to perform functions across all projects in an organization or all projects in your system. Otherwise, when you setup responsibilities, you should only grant security functions that all users with that responsibility can perform. Then use the role-based security definition to give additional access to users based on their project role. For example, you may decide that the Project Manager, John Smith, regardless of which project he is assigned, should have the following functions (included in the Project Functions area in the Function Security List from the Oracle Projects Implementation Guide, Appendix A):  Mass Update Batches  Projects: Page Layout List  Project Creation  Projects: Project Overview Function  Projects: Enter and Maintain Projects  Projects: Project Request List  Projects: Edit Attachments  Projects: Project Search  Projects: Add Attachments  Projects: Relationships Function Security in Oracle Projects 9  Projects: View Attachments  Project Sets: Create and Delete  Project Retention Inquiry  Projects: Project Sets: Update All  Project Home Tab  Projects: Project Sets: Set as Shared  Project List Button  Projects: Set Project Access Levels  Project List: View Summarization Columns So, in the responsibility for Project Manager assigned to John Smith, you would create a menu including these functions. When John Smith signs in as Project Manager, he would be able to perform any of these functions for any project in his operating unit. However, you may not want to grant John Smith the ability to view billing information or approve project billing invoices for all projects, so you would not include the following functions (from the Project Functions area) in the Project Manager responsibility menu:  Project: Financial: Billing  Project: Financial: Billing Approve Invoice  Project Funding Inquiry Query project funding and billing activity For Project A, John Smith requires the ability to review and approve invoices and view funding activity in addition to the standard Project Manager functions, but he does not require this ability for Project B. So, you would create two separate team roles:  Project Manager with Billing Authority which would have the role-based menu assigned that includes the 3 functions listed above  Project Manager with No Billing Authority which would have the role-based menu assigned that does NOT include the 3 functions listed above. Then you would assign John Smith to Project A with the role Project Manager with Billing Authority and to Project B with the role Project Manager with No Billing Authority. Based upon his responsibility, Project Manager, and his team role on Project A, Project Manager with Billing Authority, John Smith would be able to work on a project and also view and approve invoices. For project B, he would only have the functions granted by his responsibility, Project Manager. Security Checking Function Security in Oracle Projects 10 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. The process chart below describes how the security functions are used to determine user access. Refer to the Oracle Projects Fundamentals User Guide, Section 13 for more information and a description of how each step is evaluated. Security Check Process Function Security in Oracle Projects 11 Troubleshooting Question: Why can’t my project manager access a project workplan? Answer: If the project manager is not granted the security function for viewing a workplan in the menu associated to his or her login responsibility, then the security function must be granted through the user’s role menu and the user must be setup in that role on the project. Question: Why does the unlock structure function not worked for budgeting when assigned to a user. Answer: After the function ‘PA_UNLOCK_ANY_STRUCTURE’ is assigned to a user, that user can now unlock budget versions locked by other users. Question: The project manager was able to change the project status even though the “Grant” check box was disabled on the security function. Answer: Disabling the “Grant” checkbox does not restrict the function on the user’s security menu. To restrict the function, it must be deleted or removed from the menu. Question: Why is role-based security not reflected when using Microsoft Project Integration? Answer: Role-based security was enhanced to use with MSP Integration for the function Projects: View Labor Cost Rates by modifying the security check for function PA_LABOR_COST_RATES_VIEW. See Bug 6135219. Question: Why doesn’t role-based security apply on the Resource Summary page under the Reporting tab? Answer: Role-based security was corrected in Resource Summary page after fixing bug 7192736 to check security in the view_labor_costs_new in PA_SECURITY package. Question: Copy plan version not working for project role-based security. Answer: When using project role-based security the copy plan version amounts in the financial plans should populate the plan types list of values after code added to check the user privilege is called after getting the project id. See Bug 10635040. Question: Role-based security not working when checking the Grant flag. Answer: For role-based security, the Grant option has no effect or functionality. \ Function Security in Oracle Project Management August 2012 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com Copyright © 2012, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered trademark licensed through X/Open Company, Ltd. 0410