Securing Data in Project Costing

You can combine PeopleSoft Enterprise PeopleTools security and Project Costing security to implement the best method of data protection for the organization. This chapter provides an overview of PeopleTools security and project security and discusses how to define project security.

Understanding PeopleTools Security

To provide Project Costing users with access to application functions that are essential to performing their jobs, you create security roles and assign them to individual user profiles. Attached to each security role are permission lists which provide access to application pages and processes that are required to perform the job tasks.

This section discusses important PeopleTools components that you use to secure objects and definitions in your PeopleSoft system.

Permission Lists

Permission lists are the building blocks of PeopleTools user security authorization. A permission list grants a particular degree of access to specified PeopleSoft elements such as pages, portals, menus, component interfaces, development environments, signon time periods, administrative tools, personalizations, and so on. Permission lists are specific to a specific set of objects that are necessary to support a unique security role. Security roles might have overlapping—but not identical—access requirements. You typically define permission lists before you define security roles and user profiles.

Project Costing delivers preconfigured sample permission lists that grant access to various pages. These permission lists support the sample functional security roles that are delivered with the application.

Important! If you modify a permission list, you change the access for all users who are assigned to security roles that are associated with the permission list.

See Enterprise PeopleTools 8.46 PeopleBook: Security Administration, "Setting Up Permission Lists."

This table lists some of the delivered sample permission lists that provide access to Project Costing, and typical security roles that are associated with each permission list:

Note. This table contains a subset of the delivered Project Costing permission lists. To view all of the Project Costing permission lists, go to PeopleTools, Security, Permissions & Roles, Permission Lists and search for permission lists that begin with EPPC.

Row-level Security

With row-level support, you can implement security to provide individual users or permission lists with access to a page, but you do not have to provide access to all rows in the table when the page is accessed. This type of security is typically applied to tables that hold sensitive data. For example, you can implement row-level security in Project Costing to restrict access to specific projects.

The PeopleTools security system determines which data permissions to grant to a user by examining the primary permission list and row security permission list. The permission list that the system uses varies by application and data entity, such as employee, customer, or business unit. Project Costing uses the row security permission list value to determine a user's access to projects if you implement permission list-level security.

Note. Row-level security does not restrict the data that is selected by batch processes.

See Defining Row-Level Security.

User Profiles and Security Roles

Security roles are essentially collections of permission lists, which determine the pages that users can access. You can assign one or more permission lists to a security role. The resulting combination of permissions can apply to all users who share those access requirements. However, the same group of users might also have other access requirements that they don't share with each other. You can assign:

• A permission list to multiple security roles.

  Permission lists define access to specific portals and components based on the user's security role.

• A security role to multiple user profiles.

• Multiple security roles to a user profile.

  User permissions are based on the combined permissions that are assigned to all of the user's security roles.

User profiles define individual PeopleSoft users. Each user is unique. The user profile specifies a number of user attributes, including one or more assigned security roles. After you create security roles, create user profiles and associate them with security roles. The values for a user's page access are inherited from the associated security roles.

To set up security roles and user profiles in PeopleTools:

• Create security roles in the Role Maintenance component (ROLEMAINT).

• Assign permission lists to security roles.

• Create user profiles in the User Profile Maintenance component (USERMAINT).

• Assign security roles to user profiles.

See Enterprise PeopleTools 8.46 PeopleBook: Security Administration, "Administering User Profiles."

Project Costing provides sample data that contains several preconfigured security roles based on functional tasks that are typically performed by an employee who is assigned to that security role. Each preconfigured security role comes with access to the set of pages within the application that correspond to the functional tasks of that security role. For example, a project manager can access pages that are used for every project management business process task, but a time and expense administrator can only access pages to enter project time, make resource adjustments, perform expenses integration, perform time and labor integration, and create summary and variance reports.

This table lists three of the sample security roles that are delivered with the PeopleSoft system:

Note. This table contains a subset of sample security roles that you can use in Project Costing. To view security roles, go to PeopleTools, Security, Permissions & Roles, Roles.

Understanding Project Security

At the project level, you can define security in Project Costing as:

• Tree-based security that grants access to projects based on the project tree hierarchy.

• List-based security that grants access to individual projects, regardless of their positions on a tree.

• Team-based security that grants access to projects based on an employee's membership in a project team.

By combining PeopleTools and Project Costing security types, four methods for implementing project row-level security are possible. You can use only one of these methods to secure Project Costing data:

• Team-based security.

• User, tree-based security.

• Permission list, tree-based security.

• Permission list, list-based security.

Additionally, the project security profile further defines security for these four security types. The security profile is associated with a project role, and is the ultimate authority for determining access to project data. When you implement project row-level security, security profiles control read/write access to projects, activities, and transactions. Project team members with the same project security profile have access to the same data.

See Also

Securing Your System

Team-Based Security

Two factors determine access to data in team-based security:

• Membership in the project team.

• Project security profile of the member.

In team-based security, access to a project is limited to people defined as project team members by the project manager or administrator. When you use team-based security, the project manager or administrator is automatically added to the team and granted access to project data.

Project managers and administrators can grant access to a project by assigning members to the project team. Being a project team member in a team-based security system, however, does not necessarily grant access to any project data. The user must be a team member and have a project role with a security profile that permits access to project data.

Viewing Security Data

There are two different views of the same security data:

• The Project Definitions - Team page lists all members of a project team with each team member's project role and security profile.

• The Project Security page lists all projects for which the user is a team member, and the member's security profile for each project.

Copying a Team-Based Project

You can copy team members and their security profiles when you copy projects.

User, Tree-Based Security

Three factors determine access to data in user, tree-based security:

• Access to a tree node (project).

• Position of the node on the tree.

• Project security profile.

You specify the project tree on the Project Security page that the system uses for controlling project security. Grant each user access to nodes on this project tree to define the projects to which the user has access. The user's security profile defines the degree and type of access that the user has to project data.

PeopleSoft delivers the PROJECT_BU tree structure for use in creating project security trees for row-level security.

Restricting and Allowing Access to Child Projects

With tree-based security, users have the same degree and type of access to the child projects of the selected project. Denying access to a project (node) on a project tree can also deny access to all of its child projects.

To restrict access to a parent project, but allow access to specific child projects:

1. Select a security profile that has No Access to the project for the parent project.

2. Select a security profile that has Read/Write or Read only access to the project for each child project.

To allow access to a parent project, but restrict access to specific child projects:

1. Select a security profile that has Read/Write or Read only access to the project for the parent project.

2. Select a security profile that has No Access to the project for each child project.

Note. The default security for new trees is No Access. To implement minimal security, grant users access to the top node on each tree so that all of the nodes below it are accessible.

Permission List, Tree-Based Security

Three factors determine access to data in permission list, tree-based security:

• Permission list—defining access to folders and content references in portal navigation.

• Tree-based—defining access to projects based on their inclusion in, and position on, a tree.

• Project security profile—defining the degree of project data access and the access type.

Users with access to a permission list can access projects that belong to a tree that is attached to that permission list. All users with the same row security permission list have the same project access when you use permission list-level security. You can assign only one security profile to the permission list for each project. The degree of access to project data and the access type are defined by either the security profile that is assigned to a project on the tree, or the security profile for the parent project. You can attach a project tree to more than one permission list.

Restricting and Allowing Access to Child Project Costing

When security is defined for a parent project, all child projects inherit the same permission as the parent.

To restrict access to a parent project, but allow access to specific child projects:

1. Select a project security profile that has No Access to the project for the parent project.

2. Select a project security profile that has Read/Write or Read only access to the project for each child project.

To allow access to a parent project, but restrict access to specific child projects:

1. Select a project security profile that has Read/Write or Read only access to the project for the parent project.

2. Select a project security profile that has No Access to the project for each child project.

Note. The default security for new trees is No Access. Therefore, you must set up project tree security to provide access to any trees. To implement minimal security, grant access to the top node on each tree that you create so that the nodes beneath it are accessible.

See Also

Securing Your System

Permission List, List-Based Security

Three factors determine data access in permission list, list-based security:

• Permission list—defining access to folders and content references in portal navigation.

• List-based—defining access to individual projects selected from a list of projects, not from a tree.

• Project security profile—defining the degree of project data access and the access type.

Users with access to a permission list can access projects that are attached to that permission list. Projects are selected from a list of existing projects instead of from a tree. All users with the same row security permission list have the same project access when you use permission list-level security. You can assign only one security profile to the permission list for each project. The degree of project data access and the access type are defined by the security profile for the combination of permission list and project. You can attach a project to more than one permission list.

When permission list, list-based security is defined, users:

• Have access only to specific folders and content references that are defined by their permission lists.

• Have access only to specific projects that are attached to their row security permission list.

• Are limited to the amount of project data and type of access based on the assigned security profile for that permission list and project combination.

Viewing Security Data

If you use permission list, list-based security, the Security by Permission List page appears in the Project General component (PROJECT_GENERAL). This page shows all of the permission lists to which the project is attached, and provides the project manager or administrator with a view of all permission lists that have access to their projects.

Copying Security Definitions

Security definitions are copied when you create a new project using the Project Copy utility. Access to the new project is restricted to the type of access allowed by the source project. Tree-based security rules are not copied.

See Also

Securing Your System

No Project Security

You can decide not to implement row-level security for projects. When you select No Security on the Security Options page:

• All components are accessible.

• All projects are accessible from Tree Manager.

• All projects appear in project prompts.

You can enforce security to restrict time and expense charges to projects even if you don't implement row-level security for projects. Select an option at the business unit or project level to enable only team members to charge time to projects and activities.

See Defining Project Options.

Project Security Profiles

The project security profile is a subset of the project role, and is the final authority for determining access to projects, activities, and transactions. Project team members with the same project role have the same security profile and access to the same data.

The security profile defines a user's access type—no access, read-only, or read and write permission—to project data. The profile defines access to transactions based on analysis groups. After you define an access type and analysis groups for a project security profile, all users or permission lists that are attached to the profile acquire that access type.

Project security profiles are keyed by tableset ID and can be different for each business unit. For example, a security profile for business unit 1 can grant access to a greater level of data than the same security profile in business unit 2. You can also create different project security profiles for different projects.

This table lists examples of project security profiles and their typical functions:

Process Flow

To implement row-level security in Project Costing:

1. Create project security profiles on the Security Profile page.

2. Create project roles, and associate them with security profiles, on the Project Role page.

3. Define the type of security to be implemented, based on the needs of the enterprise, on the Security Options page:

   • Team-based security.

   • User, tree-based security.

   • Permission list, tree-based security.

   • Permission list, list-based security.

4. Implement the type of security selected.

Defining Project Security

To set up project row-level security, use the following components:

• Security Profile (PROJ_SEC_PROFILE).

• Row Level Security Options (SECURITY_OPTIONS)

• Project Security (SEC_PROJECT).

This section discusses how to:

• Create project security profiles.

• Define team-based security.

• Define user, tree-based security.

• Define permission list, list-based security.

• Define permission list, tree-based security.

Pages Used to Define Project Security

Creating Security Profiles

Access the Security Profile page.

Security Profileand Description	Enter a security profile name and description. If you create a unique security profile for each project role, you can enter a security profile name that matches the project role name. If you create a security profile to associate with multiple roles, you can enter a generic security profile name.
Access to Project and Access to Activity	Select an access type. Available options are No Access, Read only, or Read/Write.
Analysis Group	Enter one or more analysis groups to grant the security profile access to transactions with analysis types that belong to these groups. Granting access to transactions automatically permits read and write permissions, and the ability to add and delete rows, unless the analysis type is defined as a secured analysis type.

Secured Analysis Types

You can control the transactions that users can modify by setting up secured analysis types. Transaction rows for secured analysis types appear as read-only on the Transaction List page. Users cannot add or delete transaction rows that belong to secured analysis types, unless the page is opened in the Correct History mode, in which case editing is allowed.

To secure analysis types:

1. Associate the analysis types that you want to secure with a single analysis group.

2. Enter the analysis group in the Secured Analysis Types group box on the Installation Options - Project Costing page.

Note. Users with access to the Transaction List page in Correct History mode can modify transactions with secured analysis types.

See Also

Defining Project Costing Installation Options

Defining Team-Based Security

To implement team-based security:

1. Access the Security Options page.

2. Select User ID Level Security in the Type of Security group box.

3. Select Project in the Secured Fields group box.

4. Select Use list in the Proj Security Type (project security type) field.

5. Save the page.

If Project Costing is installed the system grants security access to projects based on the project team. Use the Project Security page to view a list of all projects for which the user is a team member.

If Project Costing is not installed:

1. Access the Project Security page for a user.

2. Enter the business unit and project ID of the projects to which you are providing access.

3. Select the security profile for the selected user in this project.

4. Save the page.

Defining User, Tree-Based Security

To implement user, tree-based security:

1. Access the Security Options page.

2. Select User ID Level Security in the Type of Security group box.

3. Select Project in the Secured Fields group box.

4. Select Use tree in the Proj Security Type field.

5. Save the page.

6. Access the Project Security page for a user.

7. Enter the tree business unit, tree name, and tree effective date for the tree that you are securing.

8. Select the project ID (tree node) in the User Role in Projects grid to define the security for the selected user.

9. Select the project role of the selected user in this project.

10. Save the page.

Defining Permission List, List-Based Security

To implement permission list, list-based security:

1. Access the Security Options page.

2. Select Permission List Level Security from the Type of Security group box.

3. Select Project in the Secured Fields group box.

4. Select Use list in the Proj Security Type field.

5. Save the page.

6. Access the Project Security page for the permission list for which you are defining security.

7. For users who have access to the selected permission list, select the business unit and project ID to which you are providing access.

8. Select the project role of the permission list in the selected project.

9. Save the page.

Note. Permission list, list-based security can be defined from either the Project Security page or the Security by Permission List page that are accessible from the Project General component when permission list, list based security has been implemented. On the Project Security page, define security to multiple projects based on a permission list. On the General Information - Security by Permission List page, define security for a single project. Typically, this is done by a project manager or administrator who has access to the Project General component. The General Information - Security by Permission List page is visible only if the Security Options page is set up for permission list, list-based security, and only if Project Costing is installed.

Defining Permission List, Tree-Based Security

To implement permission list, tree-based security:

1. Access the Security Options page.

2. Select Permission List Level Security from the Type of Security group box.

3. In the Secured Fields group box, check Project.

4. Select Use tree in the Proj Security Type field.

5. Save the page.

6. Access the Project Security page for the permission list for which you are defining security.

7. Enter the tree business unit, tree name, and tree effective date for the tree that you are securing.

8. Select the project ID (tree node) that is being secured in the Operator Class Role in Projects grid.

9. Select the project role of the permission list in the selected project.

10. Save the page.