Securing Your Academic Institution

This chapter discusses how to:

• Secure access to student data.

• Secure academic structure.

• Secure academic organizations.

Securing Access to Student Data

To set up student data security access, use the Security Views component (ES_SECURITY_TBL), the Security Views Update component (RUNCTL_SRSECVWU), and the Security View Change Audit component (SECURITY_AUDIT).

You can secure a user’s access to pages that contain student information.

This section provides an overview of security for access to student data, lists prerequisites (including delivered security views), and discusses how to:

• Set component security.

• Run the Security Views Update SQR process (SRSECVWU) and report.

• Specify search parameters for security view changes.

• Review security table audit information.

• Review security detail audit information.

• Set advisement report security.

Understanding Security for Access to Student Data

The Component Security feature provides the option to impose security on selected components, based on a student’s institution, career, program or plan. You set the specific security level on the Security Views page. The security level determines which search record (or security view) is used when the user attempts to access the component. Select No Security to retain the original search records that are delivered with the system. The security views delivered with this feature enable the system to verify that the user has access to the appropriate institution, career, program, or plan to view, update, or add data relating to a student’s record.

The security level becomes effective only after you run the Security Views Update process. This process exchanges the original search record with one of the delivered security views for a component (if you select the Global Security option) or a specific menu item. In the latter case, the component search record is overridden only on the specific menu item with one of the security views. Consequently, you can impose different levels of security for components that are accessed using different navigation paths.

After you have created security views for the institution and applied views for components that you want to secure, you can use the Security View Change Audit component to view the details of any changes to those settings. For example, you can view the user ID, date of action and action taken, and the security level settings for a particular component. You can see when the security view was created, updated, or deleted, and you can view the state of the record before and after a change. A check box on the Search Criteria page controls how the system returns values that match the selection criteria.

Note. This feature should not be used to update search record security for self-service features.

Here’s how to secure access to student data:

1. Identify and define levels of security for a component on the Security Views page.

2. Update security definitions by running the Security Views Update process on the Security Views page.

3. (Optional) Perform an audit of changes to security in the Security View Change Audit component.

Prerequisites

Before you implement component security, identify people at the institution who have both technical and functional expertise and who can review this feature. Although the Component Security feature is functional in application, it is quite technical in design and implementation. The individuals assigned to evaluate, incorporate, and support this feature must not only understand the way staff and faculty interact with student-centered components at the institution, they must also have a solid understanding of table structures, security views, and page caching. A working knowledge of managing version control and PeopleSoft lock records is also useful.

Begin the review process by thoroughly investigating delivered security views for all tables. To do this, run the Security Views report with the Report Only option selected. Notice in the report that the majority of delivered component security views are not set at the global level but at the menu item level. Also most of the delivered views are limited to PeopleSoft Enterprise Academic Advisement, PeopleSoft Enterprise Recruiting and Admissions, PeopleSoft Enterprise Campus Community, and PeopleSoft Enterprise Student Records. Every delivered security view is set to a value of None. This means that no security is implemented (other than standard preexisting people search filters) until you modify this setting for every component that you want to secure. Familiarize yourself with the five levels of security that are available, and decide which levels work for the components at the institution.

Upon review of the delivered security views, evaluate and set the security-level settings for all components. Again, all delivered component views have the security level None, so you must update this value and assign data in the Security Views fields accordingly. You can modify these settings at any time, but you must run the Security Views Update process to activate the changes.

Note. PeopleSoft delivers security views setup data for some Financial Aid components and most of the Campus Community components within the new Campus Community student-only menus. These secure views restrict access to student data for specific user IDs by institution, career, program, and plan. Note that applying component security is optional, and applies only to schools that set up security for Financial Aid, Campus Community, and Enrollment Services tasks.

See Applying Demographic Data Access Security.

The table below lists the default settings for the Financial Aid components that have security views. These are the default component settings delivered on the Security Views page. All components in the table display the following security settings:

• Security Level = No Security

• Global Security = Yes (selected)

Component names with an asterisk (*) also display the following security setting: Exclude Add Searchrecord = Yes (selected)

The table below lists the default settings for the Campus Community components in the student-only menus that have security views. These are the default component settings delivered on the Security Views page. All components in the table display the following security settings:

• Security Level = No Security

• Global Security = No (not selected)

• Exclude Add Searchrecord = No (not selected)

• No Security View = STUDENT_SRCH

• Institution Security View = CC_STU_INS_SCTY

• Career Security View = CC_STU_CAR_SCTY

• Program Security View = CC_STU_PRG_SCTY

• Institution Security View = CC_STU_PLN_SCTY

Refer to the following book to learn more about how the system renders Application Designer menus through the portal.

See Enterprise PeopleTools PeopleBook: PeopleSoft Application Designer

The table below lists the default settings for the Enrollment Services components that have security views. If there is no menu or Application Designer Bar Name listed, then the value for Global Security = Yes (selected).

Refer to the following book to learn more about how the system renders Application Designer menus through the portal.

See Enterprise PeopleTools PeopleBook: PeopleSoft Application Designer

The components below display the following security settings: Exclude Add Searchrecord = Yes (selected):

• ACAD_PLAN

• ENRL_REQUEST

• LOAN_ORIG

• REVIEW_USER_EDITS

• STUDENT_MILESTONE1

You can create additional security for components not included in the PeopleSoft-delivered set, using one of two methods:

• If the component already uses one of the search records listed in the table above, add the component using the Security Views page and enter all of the corresponding views in the Security Views group box.

  Use the table as the template.

• If the component uses a search record other than the ones listed above, you can create modified security views for institution, career, program, and plan security.

  Add the component using the Security Views page and enter all of its corresponding modified views in the Security Views group box.

Pages Used to Secure Access to Student Data

Setting Component Security

Access the Security Views page. When you search for existing values before entering this page, you can search by Institution Security View.

Note. Adding components to the Security Views page does not automatically secure them. After you have specified all necessary components and views on the Security Views page, run the Security Views Update process to implement the settings.

When a user attempts to access one of the components that you specify, the system checks the user’s security for the institution, career, program, or plan to verify that the user has permission to access the student data using the component. In some cases, the navigation is also verified.

Note. Adding components to the Security Views page does not automatically secure them. After you have specified all necessary components and views on the Security Views page, run the Security Views Update process to implement the settings.

Component

Component Security Setup

Security Level

Security Views

All of the security view settings delivered with the PeopleSoft system are provided as initial settings that you can alter to fit specific business needs before running the Security Views Update process.

The fields for delivered component name security views are populated with the appropriate security view (search record) based on the institution, career, program, plan or no security setting in the Security field. Use of a particular view is determined by the selected security value. You can select any security value, based on your needs, and the corresponding security view is used. All of the security views fields prompt against all security records in the database, including records that you have modified.

You must enter a security view value for the corresponding level specified in the Security field. For example, if you specify Program Level Security in the Security field, then you must enter a value in the Program Security View field.

Note. Components based on search records other than PEOPLE_SRCH are delivered with settings different from those described here for Institution Security View, Career Security View, Program Security View, and Plan Security View.

SQL Statements to Find Component Occurrences

You can use these Structured Query Language (SQL) select statements to find out the global and specific occurrences of a particular component:

• To identify components that have multiple menu paths, use this SQL Select statement:

  SELECT PNLGRPNAME, MENUNAME, BARNAME, ITEMLABEL FROM PSMENUITEM 
  WHERE PNLGRPNAME = 'COMM_SUMMARY_PERS'

• To determine if a search record exists at the menu level, you can use either the PeopleSoft Application Designer Menu Item Properties page, or this SQL Select statement:

  SELECT PNLGRPNAME, SEARCHRECNAME FROM PSMENUITEM
  WHERE PNLGRPNAME = 'ACAD_PLAN'

  If a search record exists, the search record at the component level has no effect here. Consequently, the page is secured at the menu level using this search record.

• To identify the search record at the component level, you can use either the PeopleSoft Application Designer Component Properties page, or this SQL Select statement:

  SELECT PNLGRPNAME, SEARCHRECNAME FROM PSPNLGRPDEFN
  WHERE PNLGRPNAME = 'ACAD_PLAN'

  If a search record does not exist at the menu level, the search record at the component level is used to access and secure the page.

Running the Security Views Update Process and Report

Access the Security Views Update page. After you assign new security views to Financial Aid or Campus Community components, you must re-run the Security Views Update process to accommodate the new views.

Important! The first time all users log on to the system after you run the Security Views Update process, all PeopleTools data pertaining to pages is recached. Consequently, you should run this process at the same time that you run other major maintenance processes, rather than immediately before a heavy traffic period for the institution. Recaching pages slows initial page access for users. In addition, if you erroneously delete or modify security, it is better to discover the error during a system lull than during a peak admission, billing, or registration period.

The Security Views Update process allows you to move from menu-specific security view settings to global settings without the risk of creating inaccurate search record data. Specifically, the process:

• Removes the menu component search record override.

• Enables the system to use the component search record that was updated by the SQR.

Important! Do not run the update process until you are satisfied with all of the security views data, including the security views data delivered by PeopleSoft. Before you run the process, review all of the security views data settings thoroughly—paying close attention to the Exclude Add Searchrecord and Global Security options.

Specifying Search Parameters for Security View Changes

Access the Search Criteria page.

Component	Enter the component object name to be audited for security. This field is required.
User ID	Enter the user ID that you want to audit. Leave this field blank to have the system retrieve all values for this field.
Start Date	Enter the earliest date to be audited. Leave this field blank to have the system retrieve all values for this field.
End Date	Enter the latest date to be audited. Leave this field blank to have the system retrieve all values for this field.
View Changes Only	Clear this check box to have the system return all records with the action Insert, Before, After, or Delete. Select this check box to prevent the system from returning records with the action Before. This option controls before-and-after results. If you want to see only the values after the change, then select this check box. If you want to see the both the before and after values, then clear this check box.
Search	After you have entered the selection criteria, click this button to return audit data to the Security Table page and the Security Detail page. To modify the data that the system returns, update the selection criteria and click this button again. Note. When you click this button, the retrieval process begins and the system displays the first page with data (either the Security Table page or the Security Detail page). If no changes have been made to the table, the system displays the Security Detail page.

Reviewing Security Table Audit Information

Access the Security Table page.

User ID	Displays the user ID of the person who made changes to the Security View table. For rows where the action is Delete, no user ID appears because the system does not track the user ID of the person who deletes a record. When deletions occur, the character string ******** appears in the User ID field.
Date/Time	Displays the date and time when the changes to the Security View table were made.
Action	Values are: Insert: Indicates that the user inserted a new row in the database. Delete: Indicates that the user deleted a row from the database. Before: Indicates an image of the record before it was updated. After: Indicates an image of the record after it was updated.
Component	Displays the component that you selected as part of the search criteria.
Excl Add Srchrc (exclude add search record)	Displays the status of the Exclude Add Searchrecord option on the Security Views page. The values Y for selected and N for cleared indicate the status of the check box.

Reviewing Security Detail Audit Information

Access the Security Detail page.

Important! To record the security changes that the Security View Audit functionality audits, the IT team must first install and execute delivered SQL trigger files.

The installation guides on Customer Connection provide more information about this topic.

Note. Column order may vary by implementation. All columns may not be visible. Use the horizontal scroll bar on the page to view all available columns.

Component Tab

Security Tab

Access the Security tab.

Gbl Scrty (global security)	Displays the status of the Global Security check box on the Security Views page. The values Y for selected and N for cleared indicate the status of the check box.
Security	Displays the option entered in the Security field on the Security Views page. Options are: NON (no access): No Access was entered on the Security Views page. INS (institution): Institution Level was entered on the Security Views page. CAR (career): Career Level was entered on the Security Views page. PRG (program): Program Level was entered on the Security Views page. PLN (plan): Plan Level was entered on the Security Views page.
No Security	Displays the view entered for the component in the No Security View field on the Security Views page.
Inst Security (institutional security)	Displays the view entered for the component in the Institution Security View field on the Security Views page.
Career Security	Displays the view entered for the component in the Career Security View field on the Security Views page.
Program Security View	Displays the view entered for the component in the Program Security View field on the Security Views page.
Plan Security	Displays the view entered for the component in the Plan Security View field on the Security Views page.

Setting Advisement Report Security

When the administrator uses the Request Advisement Reports page, the Generate Report Requests page, the Print batch Reports page or the Purge Report Results page, the type of advisement reports that can be accessed is specified on this page.

Access the Advisement Report Security page

Enter a report type for which the combination of user ID and academic institution can access.

Securing Academic Structure

To set up academic structure security, use these components: Academic Institution Security (SCRTY_TABL_INST), Institution/Career Security (SCRTY_TBL_CAREER), Academic Program Security (SCRTY_TABL_PROG), and Academic Plan Security (SCRTY_TBL_PLAN).

Securing the academic structure involves setting up security for academic institutions, academic institution and academic career combinations, academic programs, and academic plans. It is important to set up security for academic institutions individually and jointly with academic careers because not all pages are keyed by both academic institution and academic career, and not all careers are available for every Institution.

This section provides an overview of academic structure security and discusses how to:

• Set security for academic institutions.

• Set security for institution and career combinations.

• Set security for academic programs.

• Set security for academic plans.

See Also

Designing Your Academic Structure

Defining Programs, Plans, and Subplans

Enterprise PeopleTools PeopleBook: Security Administration, "User Profiles”

Understanding Academic Structure Security

You secure the academic structure by user ID. Give each user ID access to the academic institutions, academic careers, academic programs, and academic plans that the user needs to work with in the system.

Here’s how to assign academic structure security to a user:

1. Define high-level institution security on the Academic Institution Security page.

2. Define career security by institution on the Institution/Career Security page.

3. Define academic program security on the Academic Program Security page.

4. Define academic plan security on the Academic Plan Security page.

Pages Used to Secure Academic Structure

Setting Security for Academic Institutions

Access the Academic Institution Security page.

Setting Security for Institution and Career Combinations

Access the Institution/Career Security page.

Setting Security for Academic Programs

Access the Academic Program Security page.

Academic Program

For the selected academic institution and academic career combination, enter the specific academic programs that the user ID can access. If a user ID is associated with more than one institution and career combination, enter program information separately for each combination.

Setting Security for Academic Plans

Access the Academic Plan Security page.

Academic Plan

For the selected academic institution, enter the specific academic plans that the user ID can access. If a user ID is associated with more than one academic institution, enter academic plan information separately for each user ID and academic institution combination.

Securing Academic Organizations

To set up academic organization security, use the Update Security – Acad Orgs component (RUN_SA505) and the Academic Org Security component (SCRTY_TABL_ACAD).

This section provides overviews of academic organization security trees, security versus organizational structures, and creation of new security trees and discusses how to:

• Update the security tree.

• Granting and restricting access in the security tree.

Understanding Academic Organization Security Trees

Online security is a critical issue in any organization. Because most data in Campus Solutions is confidential, you must specifically designate the data that users can see. To do that, you use an academic organization security tree, which is a security structure that graphically represents the hierarchies of organizational units in an institution. With the security tree, you can view and update the reporting relationships among units and grant and deny user access to data. You can also track changes over time by creating new trees with different effective dates. To set up data security, you create security trees that are based on hierarchies of organizational entities. Using PeopleSoft Tree Manager, you can build a new security tree showing organizational entities such as universities, institutions, and academic departments.

The primary advantage of using a hierarchy for academic organization security is that you do not have to define access rules for every organizational entity. Consequently, updating security access is faster than it would be if you had to update user access for each entity. And with a hierarchy, you can more easily deny access to a particular entity.

Each academic organization that you add to the academic organization security tree has a unique identifier—the academic organization code—which you create on the Academic Organization Table page.

After you create the academic organization security tree, you run the Update Security-Acad Orgs process that links the effective date of the tree structure with the Academic Organization Security table, in which you grant user access to academic organizations. This ensures that the security rules use the tree with up-to-date academic organization hierarchies. You then run the Tree Auditor process to crosscheck the Academic Organization table and the security tree to ensure that the academic organization data matches.

Use the Academic Organization Security table to grant or restrict user access to academic organizations. When you grant users access to an academic organization, you automatically grant them access to data in any academic organization that reports—directly or indirectly—to that academic organization, unless you selectively restrict access to a specific organization.

When you use the security structure that is delivered with Campus Solutions, you grant and deny user access to academic organization data using the same user IDs and roles that the system administrator creates.

See Also

Designing Your Academic Structure

Enterprise PeopleTools PeopleBook: PeopleSoft Tree Manager

Enterprise PeopleTools PeopleBook: Security Administration, "User Profiles”

Understanding Security versus Organizational Structures

Though you use the organizational structure as the foundation for the data security structure, the two structures are not—and should not be—the same. The primary difference between the organizational structure and the data security structure is that you continue to maintain inactive academic organizations in the security structure. You must do this so that users can retrieve historical data associated with the inactive academic organizations.

Unlike an organization chart, a security tree has these characteristics:

• One security tree can be in effect at a time.

  Historical security is irrelevant to user access.

• Inactive academic organizations always appear in security trees.

  Otherwise, data in defunct academic organizations would be inaccessible.

To use trees for reporting purposes to accurately reflect an academic organization chart at a particular point in time, do not use the academic organization security tree. Instead, create a separate academic organization tree. As the organization changes, you can create new effective-dated versions of the academic organization tree. Then, you can easily create queries that extract data from hierarchies, which accurately reflect the academic organization structure at a fixed point in time.

In the steps described for creating an academic organization security tree, it is assumed that you have a hierarchy using academic organizations from the Academic Organization table to grant and deny access to user IDs. This is the structure delivered with Campus Solutions, and it works well if you use the academic organization structure as the basis for the security structure—that is, users should view only specific portions of data, in certain organizational chunks, and the organizational entities are hierarchical.

Note. Base the security structure on current security needs. For example, you might have only a few users using Campus Solutions for the first six months of implementation. Consequently, you would not need to set up complex security hierarchies at that point. With a simple security hierarchy, you achieve enhanced system performance. When security needs change—for example, when more users begin using the system—you can easily adapt the security structure.

Understanding the Security Tree Creation Process

PeopleSoft Tree Manager offers a powerful visual means to build a security hierarchy for all organizational entities. A tree hierarchy is a quick, graphical method of granting and restricting user access to data in Campus Solutions. You do not have to perform regular audits to prevent circular or conflicting relationships among units, as you do with code-based security. The security hierarchy prevents such relationships from occurring in the first place.

You retain the logical groupings of the hierarchy, such as institutions and academic departments, by representing them as levels in the academic organization security tree. The groupings represent a security hierarchy, but they do not have to match the organizational chart.

You use levels and academic organizations to create a hierarchy of security access. For example, users who can access information for UNIV (university) can access information for all academic organizations in the institution. On the other hand, users who are granted access to information in ENGR (engineering) can access information for only the School of Engineering.

The example below shows a completed academic organization security tree:

Academic organization security tree example

From within PeopleSoft Tree Manager, you can view and update existing academic organization data, and you can create new academic organizations. Double-click an academic organization to open the Academic Organization Table page, which contains data for that particular academic organization.

You organize a tree by adding or moving limbs. Whenever you must change the security hierarchy for academic organizations, make a new effective-dated copy of the tree and move limbs to other locations. This practice makes the maintenance of organizational security easier and more accurate. When you add an academic organization to the tree, PeopleSoft Tree Manager links to the Academic Organization table, where you review specific information on the academic organization.

Creating a New Tree

Here are the steps to create a new security tree:

1. Define the tree structure.

   Identify the page definitions, record definitions, and fields for the underlying database tables where tree data is stored.

2. Define the tree for ACAD_ORGANIZATION on the Tree Definition page.

3. (Optional) Specify organizational levels.

4. Define security for academic organizations on the Academic Org Security page.

See Also

Defining Academic Organizations

Enterprise PeopleTools PeopleBook: PeopleSoft Tree Manager

Pages Used to Secure Academic Organizations

Updating Security Trees

Access the Update Security – Acad Orgs page.

Important! Because only one academic organization security tree can be in effect at any particular point in time, be sure to run this process only on the date that the new tree takes effect—not before. For example, if the new security tree has an effective date of January 1, 2005, you should run this process on January 1, 2005. The system uses whatever tree has an effective date closest to—but not greater than—the date that you enter in the As Of Date field.

Granting and Restricting Access in Security Trees

Access the Academic Org Security page.

Enter the highest academic organization in the hierarchy that the user ID should be able to access. Insert rows to add academic organizations or to restrict access to a particular academic organization lower in the hierarchy.

Academic organization security is based on the hierarchy in the academic organization security tree. The academic organization that you identify here must be a node on the academic organization security tree. Granting access to one node of the academic organization tree also provides access to all child nodes for that organization. To restrict access to a child node, select the academic organization that you want to secure and set the access code to No Access.

Example 1

This security setup would grant the user ID access to all academic organizations under the Biology and the Chemistry nodes in the security tree:

Example 2

This security setup would grant this user ID access to all academic organizations under the PeopleSoft University node, except any that fall under the School of Medicine or Law School node:

The School of Medicine and Law School are excluded because the access code is set to No Access.