Security: ui and self-service 2016 summer iips conference A look at role and process based security Laura Temples – Central Piedmont community College Joel Brubaker – NC Community College System Office

Responsibility Protect Integrity Protect Privacy FERPA, HIPAA Provide the most restrictive security that allows an employee to do their job. That does not mean they have to use every mnemonic in their security class

Role based Security vs. Process based security What is it? Role based is access defined by title; Cashier, Registrar, Accountant, VP of… Process based is access defined by an action; Taking a payment, Registering a student, Reconciling a checking account, Defining Holidays in the calendar. Where to use it and why? Role based works best when there is no variation between users in the role; small number of items to secure Process based works best when a large number of items are secured, “I want the new user to have the same access as so-and-so but not xyz”.

Colleague UI – Process based Why process/task based? Long term maintainability; How many are struggling to keep up with security? Easier to add new processes; Review new forms with data owner and determine the process/task where it should go. Easy Audits; Who does what process. Easy Temporary Access Granting; Add a process/task not a mnemonic. Eliminates the “Give new user the same access as another user except …”. New user setup is granted a series of tasks. This also makes it easier to control access until proper training is completed for a process. Easier when responsibilities change. Same Title but different responsibilities Inquiry vs Maintenance. New processes or functionality that doesn’t fit; create a new security class based on process; Student Finance Administration or Financial Aid Counselor.

Process/Task (SCD) Mnemonics Think of Process Based security like an egg carton. Process/Task (SCD) The egg carton represents the process or task. Just like your local grocery store, you buy the carton but not the individual eggs. Mnemonics

Import Files - Colleague to PC Download Examples of Process Based Security Classes: Register a Student ASPR RG RGAA RGN RGST RGPE SACP SCHD ST XNCA etc … Cash Receipt Entry CR CREN LOCR ST etc … Check Reconciliation AP CF REC RECB RECM RECR ERMR ARR LBRT ECK etc … Import Files - Colleague to PC Download FLDL SF UT

To complete the process, add all needed mnemonics.

Adding new processes is easier with Task Based: Review Software Update Notes with Data Owner Add new items where appropriate or create a new Class Security Classes (SCD) Centralized Residency Batch Maint The items below were documented in the Release Notes Processes XRDS001 XRDPM (New) ST UI Form: Parameter Maintenance for RDS (Inquiry) XRDF010 XRCE (New) ST UI Form: Batch Continuing Enrollment Expiration Processor XRDS002 XRDS (New) ST UI Form: Student Continuing Enrollment and Residency XRDS003 XRDTS (New) ST UI Form: RDS Transaction Summary (Inquiry) XRDF011 XRDA (New) ST UI Form: Continuing Enrollment Analytics Centralized Residency Individual Maint Map the New items to their associated Process security class. Idea!!! In Test, create a single test class to input all new items until review of Process. Centralized Residency Inquiry

WebAdvisor - Either works Process Based (Make a Payment/Register for a class) Role Based (UT.OperS Equivalent) WebAdvisor’s sunset is coming; use what you have in place now.

Individuals Groups Stop drop and rethink YOU HAVE TO DO BOTH AT THE SAME TIME: PROCESS AND ROLE BASED LEAST RESTRICTIVE SECURITY BY DEFAULT WITH SELF-SERVICE MOST RESTRICTIVE SECURITY BY DEFAULT WITH UI

Self-Service – Role Based Self-Service security is role based by design via the Resource Database. Resource database Currently secures: Portal Colleague Workflow Approvals Web time entry and Leave request online For more info: Ellucian manual “Using the Resource Database” (Release 18) March 2014 The Resource Database consists of institutional information that you take from existing Colleague databases using one or more batch processes. You can use the Resource Database to define the resources (people) who can be assigned to one or more roles, and who give approval through the organizational structure and approval chains. The Resource Database is part of the Colleague base product.

Self-Service: Role Security Create Role to Secure Function Determine the functions you wish to secure in Self-Service. Create the Role in ORGR. Update SS Security This step is performed in the SS software. Update the security within Self-Service, adding the Role to the Menus and/or Pages. Assign Roles to Users In Colleague, using either BURA (batch) or AROR (individual), assign the Roles needed to the PERSON.

Roles are added to the menus and pages to secure access as needed. Do you need to secure it? Colleague will always be in the background Every role created must have the membership maintained daily.

All users that need access must be made a member of that Role when security on a SS function is needed.

Over 2000 employees - distributed vs centralized CPCC’s Roles Over 2000 employees - distributed vs centralized Task based security layered for specific responsibilities of the job – same title different responsibilities UT.OPERS equivalents for students, employees and advisors used as model for roles in SS Everyone has either student or employee (or both) role and registry record added at time of account creation Additional roles for additional responsibilities e.g. advisor, cashier, financial aid Developing process for termination – currently all employee roles removed manually Must choose between creating Organizational Roles that match the role names delivered on the menus, or change the menu security to match the role names that you choose to use. Guess which way we did it…

MRPR – API Security Roles in Self-Service – finer access control access WebAPI Security modification to a Role via MRPR modify function Key Point Where UI security is most restrictive; API security is least restrictive This concept presents a change in thinking and can allow fewer roles to service different groups of people like Advisors.

ONE ROLE ALLOWING 2 DIFFERENT TYPES OF ACCESS FADV – Assigned Advisees Rights: All Access Assigned Member of Role via BURA or AROR Advisor Role ORGR Role-Permission Relationships - MRPR Everyone Else Rights: Review Any

You’re going to break an egg! Sooner or Later… You’re going to break an egg!

Tips for Resolving Security Conflicts WEBADVISOR Colleague UI Self-Service Most restrictive access prevails Inquiry for parent screen yields inquiry for detail screen Inquiry for parent AND Detail screen also listed as “Do” yields: Inquiry when accessed from parent Update when accessed directly Inquiry on parent AND Inquiry on detail yields inquiry regardless of access “Never Do” - Use Only if a user should NEVER access a mnemonic Did you include MENU in security class? Process and Mnemonic Self service side: You must choose between creating Organizational Roles that match the role names delivered on the menus, or change the menu security to match the role names that you choose to use. lEAST restrictive access prevails Colleague security side: Role created and Assigned If accessing from WA –is the link included in the security class May need to stop and start application pools or DMI app listener Person must exist in ResourceDB (EPDB)and have registry record (DRUS)

Questions