Introducing Security for Your System

This chapter provides overviews of application security and security vocabulary and discusses how to specify row-level security options.

Understanding Application Security

PeopleSoft applications use the capabilities and flexibility of multilevel security to provide an efficient, effective security solution. When you manage an environment with shared data, you need a security system that protects data at various access levels. You also need the flexibility to define the most effective and efficient path to that data across business groups, tables, departments, pages, and so forth. PeopleSoft uses an approach that enables you to set up data access at different entry points within the system.

Security access falls into three categories:

• Network security.

• Database security.

• PeopleSoft application security.

Network security controls the overall point of entry into system hardware and software. Database security narrows the scope of user access to information. Application security enables you to control access down to the level of an individual field.

Most system users typically have access to a defined set of functions, pages, or fields that enable them to perform their jobs. Examples of such users are:

• Auditors who must review inquiry pages and generate reports.

• Users who run PeopleSoft business processes.

• Management information systems staff members who configure and maintain pages and records.

In PeopleSoft applications, you have full control over security definitions and how they fit together. The security options that you enter create a matrix that enables or blocks user access to data through a series of authorizations. Users pass through several levels of authorizations before the system grants them access to any subset of the data.

Important! Creating security for prompt values or rows of data is not the same as giving security access to pages, which you do in PeopleTools. Giving users access to pages by using PeopleTools is required in addition to the security setup discussed in this chapter.

Understanding Security Vocabulary

Make sure that you understand the security terms and functions for each level of the system:

Specifying Row-Level Security Options

This section provides an overview of row-level security and discusses how to:

• Maintain row-level security.

• Set up row-level security views.

• Define row-level security for users.

See Also

PeopleTools PeopleBook: Security Administration

Understanding Row-Level Security

To establish security within the PeopleSoft application, decide what level of security to establish throughout the system, which key fields to secure, and whether security will be handled through user IDs or roles. Security can restrict individual users or roles from specific rows of data that are controlled by such key fields as setID and business unit. You can also limit user access to a specific subset of rows. For example, user ID security can allow the law school to access only the item types assigned for the law school. Or, if you have a group of staff in the registrar's office, you can add them all to a role and use role security to enforce the appropriate limits on their system access. A user may be assigned to one or more roles, providing considerable flexibility to access necessary resources. As a result, a user who is linked to more than one role can use the menu items assigned to any of those roles. Some security attributes—such as row-level security—cannot be defined by combining roles. Only one role can be used for this purpose. In PeopleTools, Maintain Security, you designate row-level security for a user by selecting a role. The row-level security attributes for the role that you select then become the security attributes for that user.

Because various combinations of security are possible, it is important to understand the effects of row-level security when you use this mix of system security options and roles:

You must set up which users or roles have access to specific business units, setIDs, and any other key fields that the application requires. For example, you might permit access to only one business unit for a certain role of users.

When a user in this role enters data, the system requires a business unit because this is the primary key for data related to the business unit. The available selections on the prompt list for this user include only the business units for which the user has been granted authority. What appears in the prompt list is data that has been filtered through one or more levels of security.

Maintaining Row-Level Security

The number of users assigned the same level of security should be a key factor in determining whether the type of security should be based on user ID or role maintenance. If thousands of users have identical access requirements, then exploring roles is a good idea. By assigning users to a single role, subsequent changes in access requirements for these users can be made once rather than multiple times.

Setting Up Row-Level Security Views

Business units and tableset IDs are maintained in edit tables and can be used as primary keys throughout the system. When a field uses an edit table to select values, you are limited to selecting only the values that have already been defined for that edit table. PeopleSoft row-level application security, when activated, enables you to specify values from the edit table, so that only those Values are: available in a particular view. Think of views as a means to access data horizontally across more than one table. Views are Structured Query Language statements that filter out data rows whose key Values are: not needed as valid access parameters. The result is that users who are authorized to access setIDs or business units see only a subset of the values from these edit tables. After these views are set up, you can specify which users or roles can access the pages that contain secured field values. Within each page, you can also hide specific fields from a particular role.

See Also

PeopleTools PeopleBook: PeopleCode Language Reference, "PeopleCode Built-in Functions"

Defining Row-Level Security for Users

After you select security options and set up security view names, you are ready to define the actual secured field values used by each user or role. When you secure key fields in the application, the page that you use depends on which level of system security you select. If you select user-level security, you utilize user security pages. If you select role-level security, you use the permission list security pages.