3

SIS Security Inventory

2Overview

3Academic Structure

3Institution

3Career

4Program

4Plan

5Sub plan

6Admissions Actions

7Application Centers

8Recruiting Centers

93C Group

10Service Indicators

12Test ID

13Demographic Data

14Mass Change

16Search Match

17Authentication Process

19Primary Permission List

22Query Security

23HR Row Level Security

25eReports

26Segregation of Duties

27ODS

28Prerequisites

29Academic Organization

30Program Actions

32Enrollment Security

34Transcript Type

35Equation Engine

36Student Financials

37Business Unit

37Item Types

38Origin

39Component Interfaces

40Security Views

Overview

There are 2 different groups of users

1) Central. ~ 200 Users.

2) College (external). ~ 900 Users.

The access requirement for the central users are diverse and need to be collected via the user upload spreadsheet.

The college users are similar enough that templates have been created to match the various users types. There are 2 groups of template users:

i. Graduate Professional (GP). There are 17 templates.

ii. Undergraduate Admissions and First Year Experience (UAFYE). 20 templates.

We may be able to bundle these templates into roles.

Notes

The GP and UAFYE templates have been created in HC8CFG 1/2/2008. We will need a custom page to clone a user and all of their associated security.

Academic StructureWave: Alpha

Admin: Centralized

Status: WIPYou 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 systemDefinition Data:

1InstitutionPS_INSTITUTION_TBL1

2CareerPS_ACAD_CAR_TBL10

2ProgramPS_ACAD_PROG_TBL75

2|3PlanPS_ACAD_PLAN_TBL13,000

3|4Sub PlanPS_ACAD_SUBPLN_TBL196

Institution

Definition: PS_INSTITUTION_TBL

Security: PS_SCRTY_TBL_INST

Assignment Strategy

Everybody gets OSUSI

Career

Definition: PS_ACAD_CAR_TBLSecurity: PS_SCRTY_TBL_CAR

Assignment StrategyThe document CONV_OSU_PLAN_XREF.xls contains a mapping of permacun (DEPT) values to careers and plans. We can use this information to map from legacy data.

CONV_OSU_PLAN_XREF.xls

SIS_USER_REPORT_DEPT.xls

Program

Definition: PS_ACAD_PROG_TBLSecurity: PS_SCRTY_TBL_PROG

Plan

Definition: PS_ACAD_PLAN_TBLSecurity: PS_SCRTY_TBL_PLANAssignment Strategy

These should map the same as Careers (see above).

Undergraduate admins dont need minors or secondary majors.

Sub planDefinition: PS_ACAD_SUBPLN_TBLSecurity: ?Where is the security page located?Notes: Brian OBrien is creating a new mainframe report to include all permicun codes and access levels (AXDR 4, ADDR 4 are missing, maybe others).

Im creating a new document that catures all of the rules for assiging academic structure security to college (external) users (1/3/2008).Admissions Actions

Wave: Alpha

Admin: Distributed

Status: DoneBefore you assign security for admissions actions, administrators must set up program actions. Program action codes designate the status of a student in a program from the time he or she is an applicant and throughout his or her academic career. For example, a student must have a program action of Matriculate to become a student, and a program action of Activate in any term in which she wants to enroll. Admission Action security is the process of granting end users the ability to assign these program actions to students.

PS_ADM_ACTION_TBL

PS_SCRTY_ADM_ACTN

Notes: Admission actions have been collected for our template users, and will be collected for all users that dont fit the template.Application Centers

Wave: Alpha

Admin: DistributedStatus: DoneYou secure applicant data through application centers. Access to applicant data is given to a user ID by granting access to specified application centers. Undergraduate Admissions and Law School Admissions are examples of Application Centers.PS_ADM_APPLCTR_TBL

PS_SCRTY_APPL_CTR

Notes: Application Centers have been collected for our template users and will be collected for individuals that dont fit the template.Recruiting CentersWave: Alpha

Admin: Distributed

Status: DoneThe recruiting center helps to identify the prospects and recruiters who belong to a particular recruiting office. Access to prospect data is given to a user ID by granting access to specified recruiting centers. If the user ID is not associated with a particular recruiting center, the user ID cannot access prospect data associated with that recruiting center.

PS_ADM_RECRCTR_TBL

There are 3 in DEVP

PS_SCRTY_RECR_CTR

Notes

Every user can not have all of them. Must be secured.

Recruiting Centers have been collected for our template users and will be collected for individuals that dont fit the template.

3C Group

Wave: Alpha

Admin: Centralized

Status: WIPPS_GRP_3C_TBL

PS_OPR_GRP_3C_TBL

After you define the groups you tie them to

a) Communication Categories

b) Checklist Codes

c) Comment Categories

Users can have multiple 3C groups, so there could be different 3C groups for each of the 3 types. Currently there are 13 groups. Is that enough for production?

Assignment Strategy

Megan email 11/28/2007: We (the Admissions team) still need to work on setting up the 3C security portion of this. Hopefully once we have this set up, we will be able to define a mapping between department (on the SPOM) and 3C group.Service IndicatorsWave: Alpha (partial)Admin: CentralizedStatus: DoneService indicators provide the ability to grant or limit access to services for an individual. There are both positive and negative service indicators. Examples of negative service indicators include no check cashing privileges, enrollment verification or transcript holds, and denied registration for classes. Service indicator security controls which service indicators a user can remove or place on students.

Definition table:

PS_SRVC_IND_CD_TBL

Reason:

PS_SRVC_IN_RSN_TBL

Security table:

PS_SCRTY_TBL_SRVC

Row Level Security Issue:The department prompt on the Reason code page will not be available to users unless they have the appropriate Security by Dept Tree security:

All Data Security permission lists get Security by Dept Tree: OSU level.

Notes: In Alpha wave users will need to view service indicators only. Legacy system is still system of reference in Alpha. Only the Deceased SI is required for Alpha wave (Megan email 12/2/2007).Test ID

Wave: Alpha

Admin: DelgatedStatus: DoneThe ability to see test scores. This could be entry exams as well a placement test for math and language etc. User ID based security for test IDs now ensures users access and process only the test data for which they have permission.

PS_SA_TEST_TBL

PS_SAD_TEST_SCTY

Low Risk.

Notes:None of the external users need TESTID security. For central users the security data will be collected on the spread sheet. Megan sent a short list of valid TESTIDs to choose from (11/28/2007).Demographic Data

Wave: Alpha

Admin: CentralizedStatus: DoneWith DDA security, you can mask the display of national ID and birth date data in search records, prompt records, and on the Bio/Demo Data and the Relationships pages if these pages have display-only security. You can mask the entire fields or the first five characters of the national ID field or the year of the birth date field. You can apply masking to one, both, or neither field. This security is tied to a users Primary Permission List.PS_RUNCNTL_MSK_CFGPS_PERS_MSK_CFG

This data is stored in a run control table. The AE Job MSK_CFG updates PS_PERS_MSK_CFG

Notes Give each user the Primary Permission Lists that corresponds with the requested search match security (SSN full, partial, none).

If a high number of primary permission lists evolve we may need to create a page to create them of the fly.

Mass Change

Wave: Alpha

Admin: CentralizedStatus: WIP.

User Profile Management

Mass change is also used for other functions in the system. Security is controlled by the users Primary Permission List.

Batch processes for the creation of applicant accounts and the adding/removing of roles as the student matriculates.

Definition: PS_MC_TEMPLATESecurity: PS_MC_OPR_SECURITY

Assignment Strategy The Admissions Team will handle the setup of the mass change process for the creation of applicant accounts.

If the applicant already has an account (they are an employee) then the applicant role will be added to their existing account. The Data Security Team will not touch the Mass Change related roles on any account.

After the applicant matriculates they will need the student role. The Student Records Team will handle the setup and configuration for that batch process.

The Data Security Team will make sure the roles and template accounts are properly defined.

Per Megan Dugan:

The delivered Mass Change definitions that we will use include:

1. Application Prog Update Select

2. Communication - Delete Temp

3. Userprofile Applicant

I believe that other modules will be using Mass Change functionality as well. Im not sure how to indicate this in CFG or how to communicate this business requirement to the Security Team.Question: Will users require these mass change definitions or only BATCHID?

Search Match

Wave: Alpha

Admin: CentralizedStatus: DoneSearch/Match enables you to define criteria to check for duplicate or multiple ID records. Search result codes specify the data which is returned in the grids on the Search Results page for the potential matching IDs that it finds. You can define field-level security for fields that you consider sensitive. For example, you might allow some users to see the full birth date, but restrict other users to see only the year (or nothing at all), depending on the Primary Permission List in their user profile.The exceptions link ties SM security to a Primary Permission list.PS_HCR_SM_RSLT_EXC

Security tab.

HCR_SM_RESULT(page)

Notes:Create specific roles for each level of SSN masking (SM_SSN_FULL, SM_SSN_PARTIAL, SM_SSN_NONE). The request form will have a field to specify the level of access for each user.

The birth data masking will not need to be specified; it will be the same as SSN

Full = MM/DD/YYYY

Partial = MM/DD/****

None = **/**/****

Authentication Process

Wave: Alpha

Admin: CentralizedStatus: WIP.Web Sever 1

Shibboleth enabled

Tuned for Admins.

SIS admins will authenticate with RSA.

Students can login here, but they wont know of the URL.(Redirect students to web server 2?)Web Server 2

Shibboleth enabled

Tuned for Students (small cache size).

Students will authenticate with their name.n (Kerberos).

Redirect Admins to Web Server 1.

Web Server 3 Not Shib enabled

Current HR users & native PS authentication

Web Server 4 ?Buckeye link users

Shib enabled

Signon PeopleCode. Redirect Admins to Web Server 1

Dont allow HR users to authenticate with Kerberos ID (No_Kerberos_Auth role).

Any user who requires RSA will have the RDA_Required role. Removing that role allows the user to login with Kerberos only.

LDAP Store password for Applicants. (email + LDAP password to authenticate)

Applicant passwords come from Mass Change batch process. The temporary table must be preserved for LDIF file.

Notes Users who are both students and employees will be held to their employee login restrictions and signon times. Mitch says the signon times will be the same for students and admins.

Do all users have an active kerberos ID?

We need to configure HC8SEC to use Shib.

We want to use Shib for prerequisite entry in February.

Primary Permission List

Wave: Alpha

Admin: CentralizedStatus: WIPControls based on primary permissions list.

1. Demographic Data (Masking the SSN and DoB).

2. Search Match result views (SSN and DoB).

3. Student Financials (Item Types)

4. Student Enrollment (Self Service Enrollment Access ID)

5. Definition Security (Trees)

6. Mass Change. (Not Used).

? What HR controls are tied to PPL ?

Since every user only gets one primary permission list, we will need to create many permutations of the various controls. A naming standard will be adopted that makes the security behind each of the primary permission lists self evident. Each byte of the name will represent one of the controls, and a unique character will be assigned to each of the control values.

The level of security required for each control will determine the number of primary permission lists we need to maintain. If there are a great number of them, and we anticipate new ones in the future, then we will need a utility for creating them.

Demographic Data.

There are 3 levels of access for masking the SSN. The Date of Birth masking wont require its own byte, it can be tied to the SSN masking byte.

CharSSNDoB

0Fully MaskedMasked

4Last 4 digits viewable.Masked

9All 9 digits viewable.Viewable.

Search Match

The ability to control which fields are displayed on a search match is only relevant to the sensitive data, in this case the SSN and DoB. There doesnt seem to be a reason to separate the masking of the SSN on pages (Demographic Data) and the masking of SSNs in search match. Therefore, we can use the same byte as Demographic Data for Search Match.

Note: See Search Match section. This control will be administered by roles.

Student Financials (Item Types)

In addition to item types there are 6 other controls that can be tied to the primary permission list.

1. Setid

2. Business Unit

3. Credit Card/Check

4. Company

5. Institution Set

6. Origin

It may not be necessary to secure any of these by primary permission list. Are there any users that require access to pages with credit card data, but should not see credit card numbers?

Item types: Items are placed on a tree and secured either by nodes on the tree or individual items. We can represent each unique group of items by a unique letter.

Item types can be optionally controlled by primary permission list. They can also be controlled by individual users.

Student Enrollment

Controlled by primary permission list for students only. Enrollment security for administrators is tied to their userid.

Access IDs. Controls What and when. When you can enroll, drop with permission, etc. It also controls the overrides that are available.

Access Groups. Controls who (which groups of students an administrator can enroll).

The primary permission list can only be tied to Access IDs, not groups. That makes sense because students can only enroll themselves, so there is no need to control which groups of students are available.

Question: How many different Access IDs will need to be assigned to students?

Guess: Undergrad, Grad, Law, Medicine

Definition Security

Controls which trees can a user update.

Security Admin: OS_QUERY_TREE

Configuration Mgnt: All trees.

?: Academic structure tree.

Data Permission Lists

Page: SCRTY_TABL_DEPT

High level node (OSU)

(Service Indicator Reasons dept prompt)

Alphabet Soup Approach

Primary PL IndicatorPrimary PL IndicatorDemographic Data MaskingStudent Enrollment Access IDDefinition SecurityMass Change

PP0UAA

4GQC

9LSU

MNN

N

Search Match

0No digits visible

4Last 4 digits visible

9All digits visible

Item Types (optional on PPL).

A?

B?

NNone

Student Enrollment Access IDs

UUndergraduate

GGraduate

LLaw students

MMedical students

NNone

Definition Security

AAll Trees

QQuery trees

SAcademic structure tree

NNo trees.

Mass Change

AApplication Prog Update Select

CCommunication - Delete Temp

UUserprofile - Applicant

NNone

Query Security

Wave: Alpha

Admin: Centralized

Status: WIPOverview: There will be a Public and Restriced role for each of the 5 modules for a total of 10 roles. The roles will all be prefixes with READ.

1. READ_AD_PUBLIC

2. READ_AD_RESTRICTED

3. etc. . .

The OS_QUERY_TREE will have a node that corresponds to each of the 10 roles above. Records that are placed in the restriced access groups (nodes) will be removed from every other node in every other query tree so that the restricted node becomes the sole means of access to that record. A record can be in more than one restriced node, however.

The public nodes will contains records that are not sensitive, but are required for query and are missing from the delivered query tree for that module.

Ten new permssion lists will be created to hold the query security for the new roles. The public permission lists will receive the high level node of the PeopleSoft delivered query tree for that module and the public node in the custom OS_QUERY_TREE for that module. The restricted permssion lists will just have the restricted node in OS_QUERY_TREE for that module.

Ten new Oracle roles will be created for each of the query roles above. A process will be run that syncronizes the Oracle roles with the PeopleSoft roles.

Notes

11th role: PSAMDIN PSURLDEFN : Contains FTP server passwords.

Issues We need to identify which tables need to be restricted.

HR Row Level Security

Wave: Alpha

Admin: Centralized

Status: Done.

In order for HR users to be able to create student employees they need to be able to open student records. For that, they need the POI security. Put this on WEBALL (or turn off that security).

On/Off Switch:

Definition: PS_SCRTY_TYPE_TBL

Security: PS_SJT_CLASS

insert into PS_SJT_CLASS

select rowsecclass, SCRTY_SET_CD, SCRTY_TYPE_CD, SCRTY_KEY1, SCRTY_KEY2, SCRTY_KEY3

from PS_SJT_CLASS a,

psoprdefn b

where rowsecclass != ' 'minusselect * from PS_SJT_CLASS;

Notes

Add the POI Type to WEBALL. Run SJT process.eReportsWave: AlphaAdmin: Centralized

Status: WIPGlenn Donaldson has said that Hyperion will be used for SIS Alpha wave.We will create 10 new folders, a Public and Restricted folder for each module. New access groups will be created for each of the 10 folders and those access groups will be assigned to the appropriate permission lists.

Issues

Who will let us know which access groups (Hyperion Folders) go with which permission lists?

Who will assign the reports to the 10 folders? We want to make sure they (Bill?) are on the same page with us on this.

Segregation of Duties

Wave: AlphaAdmin: Centralized

Status: WIPCan we identify which SIS duties need to be segregated, or is that too much burdon on the Application Team?ODS

Wave: Alpha

Admin: Centralized

Status: WIPData Warehouse

1. Collect query security information for SIS (tables by module).

2. Collect user names for table groups. Can this be mapped from current ODS?

3. Map table names to ODS tables.

There are 2 Data Warehouse environments.

1. DWMART

2. ODS

This security is only for Query access.

HCOSU will have PS Query and Oracle.

DWHCRPT will have Oracle accounts only

DWDMOSU is an Oracle only environment (no PS).

Hyperion will have every HCOSU user. Access levels will be controlled by a users access groups which will be tied to permission lists. There will be 10 SIS folders, a Public and Secure folder for each of the 5 modules.

Glenn will provide information on which users are in each of the 3 groups.

Query security will be controlled by 10 basic groups in each environment. Each of the 5 modules will have a Restricted and Public group. Only sensitive tables will be placed in the Restricted groups. Glen Donaldson will provide the list of tables (about 750 in all).

Note: No row level security in ODS.

Prerequisites

Wave: Pre Alpha

Admin: Centralized

Status: WIPAbout 200 users will need access to (a yet to be named autonomous PeopleSoft system) to setup course prerequisites in February. The effort will begin Feb-25 (Training) August.Shibboleth (Kerberos) authentication requiredA new environment will be setup for this effort. Send them a list of who can create prerequisites now.

Create college user accounts

2/18/08 Provide security support during training2/25/08 - 3/10/08Academic Organization

Admin: CentralizedRow level security requires that administrators 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 the University. Definition Data:

ACAD_ORGANIZATION tree.

Security Table:

PS_SCRTY_TBL_ACAD

Level 1Level 2Level 3

OSUSIARTS_SCIARTS_COL

ASC_E_DEAN

BIO_COL

HUM_COL

MPS_COL

SBS_COL

EXTENDEDLIMA_CAMP

MANSF_CAMP

MARN_CAMP

NEWRK_CAMP

HEALTH_SCIDEN_COL

MED_COL

NUR_COL

Large impact on course catalog

Need to go to D node for user security.

After you make a change to the academic organization tree you have to run the process that updates the tree node numbers based on the tree structure. We will need to collect this information outside of the User Definition Worksheet.

Assignment Strategy

Map from fiscal ID.Program ActionsProgram actions control how a student moves through the University.

A program action is a change to a persons program data. An action reason indicates why a particular program action was taken, or offers a further description of the program action. For example, you can record that an applicant has withdrawn an application for an academic program. The reason you enter could be After Decision or Before Decision. Program Action security controls which actions a user can apply to a student.

PS_PROG_ACTION_TBL

PS_SCRTY_PROG_ACTN

How many program actions will there be? Can everybody have them all?

Enrollment Security

Enrollment security controls when access windows close for various enrollment activities. It is tied the student's permission lists.Student Records Chapter 8-4

Enrollment Security.

Controls when access windows close for various activities.

Access IDs. Controls What and when. When you can enroll, drop with permission, etc. It also controls the overrides that are available. Access Groups. Controls Who (which groups of students an administrator can enroll). Access IDs can be tied to Access Groups.

Controlled by primary permission list for students only. Enrollment security for administrators is tied to their userid.

The primary permission list can only be tied to Access IDs, not groups. That makes sense because students can only enroll themselves, so there is no need to control which groups of students are available.

PS_TIME_PERIOD_TBL

PS_ENRMT_OVRD_TBL

Access IDs

The What & When

PS_ENRL_ACCESS_STD

Access Groups

The Who

Create an enrollment group.

The security can be at the Institution, (Career or

Program or

Plan)

And Student Group level.

Grant either an access group or an access id to the user (academic advisor)

PS_OPR_DEF_TBL_CSPS_ENRL_ACCESS_GRP

PS_ENRMT_OVRD_TBL

Question: How many different Access IDs will need to be assigned to students?

Guess: Undergrad, Grad, Law, Medicine

How is it done now?

Transcript Type

PS_TRANSCRIPT_TYPE

PS_SCRTY_TSCRPT

Equation Engine

Unbelievably bad security design.

The Equation Engine is a powerful tool that enables you to develop a variety of formulas that can be used to identify a specific student population, establish the assignment of an award, provide a calculated value, or provide a customization point in a process. Equation Engine security controls which EE programs a user can run, and it is administered on the main User Profile security page. Security is controlled by trees and profile types.

ProfileTypeCorresponding TreeDescription

EQDEQTN_TBAUTH_TREEControls access to equation engine data

EQNEQTN_IDAUTH_TREEControls access to equations

EQSEQTN_SQAUTH_TREEControls access to callable SQL

EQXEQTN_XTAUTH_TREEControls access to external cobal code.

The primary tree seems to be EQTN_IDAUTH_TREE which controls which equation engine programs a user can run. (Does the user need access to the sql in the EE as well to run it?)

These trees are currently empty and need to be defined. All(?) of the equation engine programs are in the public node at the top of the tree. Everybody has access to the public nodes without having to be granted the access. The nodes placed in these trees become available within the opralias field for the corresponding profile type. Granting access to a node does not grant access to child nodes. Users can only have one node per profile type (i.e. Tree).

Every user can be granted one node on the tree, and only one node. Once a user is granted access to a node on the tree they gain access to the equation engine programs in that node but they loose access to everything in the public node.

It wont help to create extra trees, because the nodes are granted as Access Types in the usermaint component. This is like an emplid type, and just as a user can have only one emplid, they can have only one equation engine profile type. There are 5 types, but only 4 are being used. Nobody should have access to create equation engine programs in production because it is basically a SQL tool. Its dangerous to the data because users would be testing their SQL in production, and its a security issue because users can create ad hoc update SQL statements.

Plan Get rid of Public equations

Top node in tree will have all equations.

Lower nodes will have progressively fewer equations.

Maybe only 3 levels of nodes will be necessary.

Student Financials

PS_INSTALLATION_SF

PS_SEC_VIEW_NAMES

SF CategorySecurity Table

Business Unit PS_SEC_UNITSF_OPR

Company PS_SEC_COMPANY_OPR

Credit Card and Bank Account PS_SEC_CC_OPR

Institution Set PS_SEC_ISET_OPR

Item Type PS_SEC_ITEM_OPR

Origin IDs PS_SEC_ORIGIN_OPR

SetID PS_SEC_SETID_OPR

Student Institution SetPS_OPR_DEF_TBL_CS

Business Unit

Every primary permission list needs to be added here. Can every user have OSUSI as the Business Unit?

Item Types

Item types are the basic work unit of the Student Financials application. Each item type defines and describes a unique action. Item type security controls which item types a user can apply to students.

Definitions

ITEM_TYPE_TBLSecurity

PS_SEC_ITEM_OPDATAPS_SEC_ITEM_OPR

Administer by userid

Defined in tree.

There are over 5,000 item types.

Tree Name = ITEM_TYPE_TREEOrigin

Origins represent sources of charges or payments used during group posting. Origin security limits the number of users who can view and update the transactions with which an origin is associated.

Definition:

PS_ORIGIN_TBL

Security:

PS_SEC_ORIGIN_OPR

00001 Financial Aid

00002 Lockbox

00003 Housing

00004 Fees & Deposits

00005 Payroll Deduction

00006 Office of Internat'l Affairs

00007 Ohio Attorney General

00008 Traffic and Parking

00009 Library

00010 UNITS

00011 Web PaymentsComponent Interfaces

Component interfaces allow external systems to insert/update/delete data in PS components just as if the data was being manipulated via the PIA. All PeopleCode fires. The user account that invokes the component interface does not require a permission list that has page access to the component. Therefore, it is not safe to grant every user every component interface. A savvy user could invoke CIs to directly manipulate the system.

Which CIs should be tied to which permission lists?

This is low risk and will not be restricted for the Alpha wave roll out.Security Views

Component security is the process of adding row level security functionality to particular pages. It is a process of design and development and is quite technical in design and implementation.This is really a setup page.

PS_ES_SECURITY_TBL

PS_ES_SECURITY_DTL

1 of 46

M:\PeopleSoft\SIS\Module_Security\SIS_Security_Inventory.doc6/18/2008