Ohio State SIS Security Inventory

SIS Security Inventory
Overview..............................................................................................................................2
Academic Structure.............................................................................................................3
Institution.........................................................................................................................3
Career...............................................................................................................................3
Program............................................................................................................................4
Plan..................................................................................................................................4
Sub plan...........................................................................................................................5
Admissions Actions.............................................................................................................6
Application Centers.............................................................................................................7
Recruiting Centers...............................................................................................................8
3C Group.............................................................................................................................9
Service Indicators..............................................................................................................10
Test ID................................................................................................................................12
Demographic Data.............................................................................................................13
Mass Change......................................................................................................................14
Search Match.....................................................................................................................16
Authentication Process......................................................................................................17
Primary Permission List....................................................................................................19
Query Security...................................................................................................................22
HR Row Level Security.....................................................................................................23
eReports.............................................................................................................................25
Segregation of Duties........................................................................................................26
ODS...................................................................................................................................27
Prerequisites.......................................................................................................................28
Academic Organization.....................................................................................................29
Program Actions................................................................................................................30
Enrollment Security...........................................................................................................32
Transcript Type..................................................................................................................34
Equation Engine.................................................................................................................35
Student Financials..............................................................................................................36
Business Unit.................................................................................................................37
Item Types......................................................................................................................37
Origin.............................................................................................................................38
Component Interfaces........................................................................................................39
Security Views...................................................................................................................40
1 of 47
/var/www/apps/conversion/tmp/scratch_2/270187102.doc
5/14/2015
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.
2 of 47
5/14/2015
Academic Structure
Wave: Alpha
Admin: Centralized
Status: WIP
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
1
2
2
2|3
3|4
Definition Data:
Institution
Career
Program
Plan
Sub Plan
PS_INSTITUTION_TBL
PS_ACAD_CAR_TBL
PS_ACAD_PROG_TBL
PS_ACAD_PLAN_TBL
PS_ACAD_SUBPLN_TBL
1
10
75
13,000
196
Institution
Definition: PS_INSTITUTION_TBL
Security: PS_SCRTY_TBL_INST
Assignment Strategy
Everybody gets OSUSI
Career
Definition: PS_ACAD_CAR_TBL
Security: PS_SCRTY_TBL_CAR
3 of 47
5/14/2015
Assignment Strategy
The 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_TBL
Security: PS_SCRTY_TBL_PROG
4 of 47
5/14/2015
Plan
Definition: PS_ACAD_PLAN_TBL
Security: PS_SCRTY_TBL_PLAN
Assignment Strategy
These should map the same as Careers (see above).
Undergraduate admins dont need minors or secondary majors.
Sub plan
Definition: PS_ACAD_SUBPLN_TBL
Security: ?
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).
5 of 47
5/14/2015
Admissions Actions
Wave: Alpha
Admin: Distributed
Status: Done
Before 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.
6 of 47
5/14/2015
Application Centers
Wave: Alpha
Admin: Distributed
Status: Done
You 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:
7 of 47
5/14/2015
Application Centers have been collected for our template users and will be
collected for individuals that dont fit the template.
8 of 47
5/14/2015
Recruiting Centers
Wave: Alpha
Admin: Distributed
Status: Done
The 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.
9 of 47
5/14/2015
3C Group
Wave: Alpha
Admin: Centralized
Status: WIP
PS_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
10 of 47
5/14/2015
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 Indicators
Wave: Alpha (partial)
Admin: Centralized
Status: Done
Service 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
11 of 47
5/14/2015
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).
12 of 47
5/14/2015
Test ID
Wave: Alpha
Admin: Delgated
Status: Done
The 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).
13 of 47
5/14/2015
Demographic Data
Wave: Alpha
Admin: Centralized
Status: Done
With 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_CFG
PS_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.
14 of 47
5/14/2015
Mass Change
Wave: Alpha
Admin: Centralized
Status: 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_TEMPLATE
Security: 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.
15 of 47
5/14/2015
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?
16 of 47
5/14/2015
Search Match
Wave: Alpha
Admin: Centralized
Status: Done
Search/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/****
17 of 47
5/14/2015
None = **/**/****
18 of 47
5/14/2015
Authentication Process
Wave: Alpha
Admin: Centralized
Status: 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
19 of 47
5/14/2015
Users who are both students and employees will be held to their employee login
restrictions and signon times.
o 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.
20 of 47
5/14/2015
21 of 47
5/14/2015
Primary Permission List

Wave: Alpha
Admin: Centralized
Status: WIP
Controls 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.
Char
0
4
9
SSN
Fully Masked
Last 4 digits viewable.
All 9 digits viewable.
DoB
Masked
Masked
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)
22 of 47
5/14/2015
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
23 of 47
5/14/2015
Page: SCRTY_TABL_DEPT
High level node (OSU)
(Service Indicator Reasons dept prompt)
Alphabet Soup Approach
Primary
PL
Indicator
P
Primary
PL
Indicator
P
Demographic
Data
Masking
0
4
9
Student
Enrollment
Access ID
U
G
L
M
N
Definition
Security
A
Q
S
N
Mass
Change
A
C
U
N
Search Match
0 No digits visible
4 Last 4 digits visible
9 All digits visible
Item Types (optional on PPL).
A ?
B ?
N None
Student Enrollment Access IDs
U Undergraduate
G Graduate
L Law students
M Medical students
N None
Definition Security
A All Trees
Q Query trees
S Academic structure tree
N No trees.
Mass Change
Application Prog Update
A Select
C Communication - Delete
24 of 47
5/14/2015
U
N
Temp
Userprofile - Applicant
None
25 of 47
5/14/2015
Query Security
Wave: Alpha
Admin: Centralized
Status: WIP
Overview: 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.
26 of 47
5/14/2015
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 != ' '
minus
select * from PS_SJT_CLASS;
27 of 47
5/14/2015
Notes
Add the POI Type to WEBALL. Run SJT process.
28 of 47
5/14/2015
eReports
Wave: Alpha
Admin: Centralized
Status: WIP
Glenn 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.
29 of 47
5/14/2015
Segregation of Duties
Wave: Alpha
Admin: Centralized
Status: WIP
Can we identify which SIS duties need to be segregated, or is that too much burdon on
the Application Team?
30 of 47
5/14/2015
ODS
Wave: Alpha
Admin: Centralized
Status: WIP
Data 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
31 of 47
5/14/2015
the Restricted groups. Glen Donaldson will provide the list of tables (about 750 in all).
Note: No row level security in ODS.
32 of 47
5/14/2015
Prerequisites
Wave: Pre Alpha
Admin: Centralized
Status: WIP
About 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 required
A 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 training
2/25/08 - 3/10/08
33 of 47
5/14/2015
Academic Organization
Admin: Centralized
Row 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 1
OSUSI
Level 2
ARTS_SCI
EXTENDED
HEALTH_SCI
Level 3
ARTS_COL
ASC_E_DEAN
BIO_COL
HUM_COL
MPS_COL
SBS_COL
LIMA_CAMP
MANSF_CAMP
MARN_CAMP
NEWRK_CAMP
DEN_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.
34 of 47
5/14/2015
Program Actions
Program 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
35 of 47
5/14/2015
How many program actions will there be? Can everybody have them all?
36 of 47
5/14/2015
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
37 of 47
5/14/2015
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_CS
PS_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
38 of 47
5/14/2015
How is it done now?
39 of 47
5/14/2015
Transcript Type
PS_TRANSCRIPT_TYPE
PS_SCRTY_TSCRPT
40 of 47
5/14/2015
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.
Profile
Type
EQD
EQN
EQS
EQX
Plan
Corresponding Tree
EQTN_TBAUTH_TREE
EQTN_IDAUTH_TREE
EQTN_SQAUTH_TREE
EQTN_XTAUTH_TREE
Description
Controls access to equation engine data
Controls access to equations
Controls access to callable SQL
Controls 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.
Get rid of Public equations
Top node in tree will have all equations.
Lower nodes will have progressively fewer equations.
41 of 47
5/14/2015
Maybe only 3 levels of nodes will be necessary.
42 of 47
5/14/2015
Student Financials
PS_INSTALLATION_SF
PS_SEC_VIEW_NAMES
SF Category
Business Unit
Company
Credit Card and Bank Account
Institution Set
Item Type
Origin IDs
SetID
Student Institution Set
Security Table
PS_SEC_UNITSF_OPR
PS_SEC_COMPANY_OPR
PS_SEC_CC_OPR
PS_SEC_ISET_OPR
PS_SEC_ITEM_OPR
PS_SEC_ORIGIN_OPR
PS_SEC_SETID_OPR
PS_OPR_DEF_TBL_CS
43 of 47
5/14/2015
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_TBL
Security
PS_SEC_ITEM_OPDATA
PS_SEC_ITEM_OPR
44 of 47
5/14/2015
Administer by userid
Defined in tree.
There are over 5,000 item types.
Tree Name = ITEM_TYPE_TREE
Origin
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 Payments
45 of 47
5/14/2015
Component 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.
46 of 47
5/14/2015
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
47 of 47
5/14/2015

Ohio State SIS Security Inventory

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ohio State SIS Security Inventory

Hochgeladen von

Copyright:

Verfügbare Formate

SIS Security Inventory

After you define the groups you tie them to

Row Level Security Issue:

This data is stored in a

Per Megan Dugan:

Primary Permission List

HR Row Level Security

Large impact on course catalog

Grant either an access

How is it done now?

The primary tree seems to be EQTN_IDAUTH_TREE which controls which equation

Maybe only 3 levels of nodes will be necessary.

Every primary permission list needs to be added here.

00001 Financial Aid

Das könnte Ihnen auch gefallen