Security is critical for the implementation of Student Administration (SA). All access to areas of SA needs to be controlled through the use of PeopleSoft (PS) security. This is done as not all users require access to certain types of data nor require access to all functions within PS.
PeopleSoft introduces many new features for security. These features will allow for tremendous flexibility and, if needed, control of all SA modules (Admission, Student Records, Student Financials and Financial Aid).
A security definition refers to a collection of related security attributes created using Maintain Security in PeopleTools. The three main PeopleSoft security definition types are:
In addition to the access maintained via PeopleTools Maintain Security, Student Administration also delivers application security. Application security restricts the data a user can attach to a student – the values that appear in prompts. It does not restrict the students a user can view. Access to the following is controlled by application security:
Academic Institution Program Action
Institution/Career 3C Group
Academic Program Service Indicator
Academic Plan Enrollment
Academic Organization Transcript Type
As well, all students (approximately 20,000 active students a term) will need access to the PS Self-Service Learner Services component. Students will use self-service to pre-enroll for classes, add/drop classes, view class schedules, view grades, etc. Faculty and Instructors will need access to PS Self Service Learning Management menus. The current proposal for administering self-service security is to use LDAP/Directory for controlling access. As delivered, the directory would be used to identify those who have access to any category of self-service and the single self-service class would be used to allow a so-designated self-service user to access all self-service menus. [It should be noted that access to menus and access to data are not synonymous – a student would see the Learning Management menus (the menu structure supporting faculty/instructors), but as a result of PeopleSoft security would not have access to any data via those menu items.] It is still unclear at this time if there will be a need to use Guest IDs to allow prospective student access to PS Self Service. The number of these individuals could be as high as 150,000.
Finally, row level security restricts the students a user has the ability to take actions on and view. Security views would need to be created (semi-modifications to PeopleSoft – they are views that PS intends the customer to create) and processes run to activate row level security.
In addition to the PS transactional system, security access to the Reporting Data System (RDS) is required. Access to the RDS is requested in the same manor as the PS transactional system although individuals that have access to the PS transactional system do not necessarily require access to the RDS. Access to the RDS is also controlled by Roles; however the roles used to control this access are different than those used in the PS Transactional system. Example of a role is SXRRGRM - Student Reporting Records Grades/Model or SXRRNGM - Student Reporting Records No Grades/Model
During deployment, we will need to determine each task (i.e., create a new course) and which pages and actions need to be attached to each permission list to accomplish that task. A template should be used to make this process simpler to complete and to create documentation for the Security team that will set up and administer security. In addition, the SA teams will need to determine the required roles and how they map to each permission list. Finally, we will need to determine the specific application security and/or row level security needs of the users and map those accordingly.
Also during the deployment phase, permission lists, roles, user ID’s and passwords will need to be created. Once PeopleSoft SA is in production, the support for security continues to be important. Throughout the year, changes are made on a regular basis – new users are added, existing users change jobs so access needs to be modified or deleted, etc.
CIT has an established process in place as a result of the HR/Payroll and Contributor Relations (CR) projects. This includes a coding scheme for roles and permission lists. Sarah Christen (and her backup Karla Sharpsteen) are responsible for establishing and maintaining permission lists, roles, and user ID’s. They do not maintain application security.
The production process will be as follows:
Security ensure that access to data, functions and sensitive information is limited to those that require access to perform their duties at the university whether it be a student using self service to access his/her account or staff member needing to create a course.
Users will only have one user ID. Multiple roles will allow for the different tasks the user must complete.
Cornell will not use the delivered functional permission lists and roles. PeopleSoft delivers those as an example of how to set up security.
CIT and the PS SA Security Lead will work as a team to administer security for PeopleSoft SA.
The security setup will be thoroughly tested to ensure that only the desired pages and rows of data can be accessed for each role and user; permissions lists and roles will be reviewed on a regular basis for accuracy, appropriateness and completeness
The security setup will be thoroughly tested to ensure that not only pages can be accessed, but that processes can be run, queries can be run and developed, etc.
The SA Security Lead is ultimately responsible for assuring correct access to the PS system so that individuals have access to only the data they require to perform their duties. The Security Lead will work closely with the Subject Matter Experts (SME) to identify potential Roles, Permission List and any Application Security. They will then be actively involved in the testing of these to ensure that they function as expected with expect results. The Security Lead will also work closely with the University Security Administrator to create the initial set of Roles and Permission List that will be used to begin testing. Through the testing process the University Security Administrator will be ask to modify and tweak the Roles and Permission List until they have been thoroughly tested and a final list of Roles, Permission List and Application Security have been created. At that time and in preparation of a phased implementation into Production the University Security Administrator will create the User Profiles, Roles and Permission List in Production. And the Security Lead will setup any Application Security that was identified.
Security is integrated into all other areas of the PS system that an individual might require access to. As well Security is key in Testing, Training, Self-Service. Modifications (who has access to it), Interfaces (what data is available through it) and Reporting for example. Individuals will require various levels of access to data within the PS system. Security will allow each individual to have the required access without also giving additional access they are not entitled to.