1. Value Based Security Overview

2. Before we get started….
Familiarize yourself with the virtual classroom interface
Review rules of etiquette
Polling Question – VC Experience
If No – continue with slides
If Yes – Remind participants - Use chat to ask questions and 63 to turn mute on and 66 to turn mute off
Proceed to Slide 5 which displays help line.

3. Virtual Classroom Etiquette
CHAT
Use chat to ask questions
Use private chat when you have to step away for a minute
AUDIO
If you do not have a mute button, *6 = mute and *7 = un-mute
Do not place phone on “HOLD”
THANK YOU FOR YOUR COOPERATION!

4. In Case of Difficulties….
Close your web browser and re-log into the event
Send a private chat message to the moderator
Contact virtual classroom support
Press ‘*0’ to reach technical support or dial (U.S.) / (International)
Review with participants

5. To send a chat to me (or co-moderators) simply right click on my name and select Chat. To ask a question you can click on ‘Question & Answer’ on the left (click for animation). To see a larger view of the slides you can remove the participant list at the bottom by clicking on the arrow in the middle of the window pane (click for animation.)

6. Viewing Features F11 for Full Screen Esc to return to Normal View
Click to Scale View of live application
Click to Refresh View of live application
F11 for Full Screen
Esc to return to Normal View
To view the session in FullScreen press F11 on your keyboard and to return to normal view you can press the Esc key(animation) or click the icon that appears in the lower left of your screen. During application sharing, click on the Scale View button-this will allow you to see my screen without having to scroll. You can also click on the Refresh View button which will refresh your view(animation). If you joined with Full version these buttons will appear on the top right of your screen; if using Light version they will appear on top left. Now that I’ve covered some of the basics, do you have any questions before we proceed?
Click to return to normal view

7. Introductions Instructor Participants Name Title Banner Experience
Organization
Title/function
Job responsibilities
Expectations

8. Course Goal
The goal of this course is to introduce you to the new Value Based Security and Oracle Fine-Grained Access Control functionality delivered within Banner 7.

9. Agenda VBS Using FGAC Personal Identifiable Information (PII)
Overview
Set Up
Example
Personal Identifiable Information (PII)
Protection of Sensitive Data

10. Security Considerations - Banner
Application security
Standard, must be set up
Job-responsibility based, so easy to set up
Hiding fields on forms
“Protection of Sensitive Information”
Module-based security
Self-service, Luminis Security
VBS/FGAC
Optional, powerful, customizable
Not hard to set up

11. VBS Definition Value Based Security
A Banner 7.0 replacement for existing General, Student, and Financial Aid Value Based Security
Defined for individual users as needed
Value Based Security restricts a user’s ability to perform select, insert, update, or delete requests in Oracle to specific records in within a table, based on a VBS rule which has been assigned to them. This rule, called a predicate statement, is similar to a SQL where clause condition. Oracle will prevent SQL activity from occurring within a table when a value in a field does not match the criteria specified within the where clause.
Banner’s Value Based Security is an interface between Banner and Oracle to make it easier to create and view Oracle FGAC restrictions on Banner tables. Clients can create FGAC restrictions on tables directly through Oracle without using Banner, the new Banner 7 functionality is intended to make it easier for institutions to create and maintain VBS rules.
Implementation of VBS should be driven by functional business need. VBS restrictions should originate from a functional need to prevent users from maintaining data that is not associated with their job function.

12. FGAC Definition Fine-Grained Access Control
A means of providing row level security based upon existing columns and tables in Banner
Not a Sungard Higher Education invention – ORACLE functionality
Prior to allowing a user to perform any activity against a table, Oracle will identify the user’s VBS rule restriction, or predicate statement, for the table. Then, for the record the user is attempting to perform a task against, Oracle will see if the record meets the user’s predicate condition(s). If the record value matches the VBS predicate statement assigned to the user, Oracle will perform the requested task. If the value does not match the user’s VBS rule, Oracle will not allow the user to perform the requested activity.
VBS is not a required module for implementation of Banner 7.
FGAC will insert a dynamic SQL statement, called a predicate statement, to the end of an executing SQL statement at runtime.

13. How VBS Works 1. User builds a SQL statement
2. FGAC executes GOKFGAC package looks at security policy, appends restrictions to SQL statement
If the SQL activity matches the predicate criteria, the user is able to successfully perform their request. Otherwise an Oracle error messages is generated to indicate that the user does not have the correct privileges to perform the requested activity.
3. Desired SQL is executed or Oracle error message displayed

14. How VBS Works – more detail
1. User builds a SQL statement
2. FGAC executes GOKFGAC predicate function and retrieves predicate
Insert into spraddr (spraddr_pidm, …)
Values (1234, …)
4. Row inserted or Oracle error message displayed
3. FGAC appends Predicate to SQL statement
When activity is identified against a table with a policy record attached to it,
Oracle will execute the Banner GOKFGAC predicate function associated with the requested activity. The function finds the predicate values for the user, and
Dynamically appends the predicate conditions to the end of the SQL statement.
If the SQL activity matches the predicate criteria, the user is able to successfully perform their request. Otherwise an Oracle error messages is generated to indicate that the user does not have the correct privileges to perform the requested activity.
Where spraddr_atyp_code = ‘MA’

15. Terminology VBS FGAC Predicate Domain Domain Driver Policy
Business Profile
This is an overview of the major terms used in Value Based Security.
These definitions are also listed in the FGAC Handbook and someday in a workbook.
VBS: Value-Based Security. This type of security is defined for individual users as needed and depends on a predicate being entered. Referred to as “VBS Using FGAC.” VBS is strictly a Banner term and is the module written to utilize Oracle FGAC.
FGAC: Fine-Grained Access Control. Type of row-level security that dynamically modifies a SQL statement by adding a condition (WHERE clause) which restricts the rows shown to the user. The modification is transparent to the user.
Predicate: The SQL clause for a domain and group that defines the access restriction. A predicate is a piece of a SQL statement that is appended dynamically that defines restrictions.
Domain: Area in Banner that has a common driving table, usually the parent table of a module.
Domain driver: Includes the driver table for VBS type domains. VBS group rules are written to restrict access based on values on the driver table. Examples: For Admissions, SARADAP is the central table and is the domain driver. All group rules written for the SARADAP domain will utilize the SARADAP columns. For the Banner General example, the domain driver we are choosing is Geographic Region/Division and the table is GORPGEO. For the Banner General example, the domain driver we are choosing is Geographic Region/Division and the table is GORPGEO.
Policy: The ORACLE object on a table that enables FGAC to function. A policy must be created before PII and VBS will work. After a domain and its tables are defined, a process is run to create the policy. In GOKFGAC FGAC, there is one policy per table.
Example: gorpgeo_geod_code = ‘GRADUATE’
Business profile: Grouping of users that have the same access restrictions. A business profile reduces data entry of access restrictions. A business profile is different from a BANSECR role. Maintenance of business profiles is distributed and moved out of BANSECR schema. In some cases, maintenance of business profiles can be distributed to client offices.

16. Set Up POLLING QUESTION
______ present the underlying database table relationsips in SCT Banner?
CRUD
ERD
FGAC
GOKFGAC

17. VBS Process Flow Define VBS Restrictions Identify and Setup Users
Functional User Tasks
Combined Tasks
Technical User Tasks
Define VBS Restrictions
Identify and Setup Users
Setup VBS Domains
Test Restrictions
Create the Rules and Assign Users
Value Based Security requires both functional and technical user setup.
VBS restrictions are based on a functional business need. The functional users define the VBS restriction, and the user or groups of users who will be impacted by each specific rule within the restriction. The technical staff works with the functional users to create business profiles, which are based on the groups of users defined by the functional staff. The technical staff then assigns users to the business profiles.
The technical users work with the functional users to identify the tables that will be impacted by the VBS restriction. After the technical users convert the functional rule descriptions into SQL predicate conditions, they create the VBS rules in Banner, and assign the specific rules to the identified user or groups of users.
The technical users then verify that the predicate statements are being generated correctly for each table and restricted user.
After the rules have been verified, the functional users test that the VBS rule works as requested.
Once the VBS restriction has been tested, the functional users need to train the end users on the changes to their job. In conjunction with this, the technical users will move the new VBS restriction from the pre-production database to the production database, and schedule the go-live date with the functional users.
Migrate Rules to Production
Verify Restrictions

18. Analysis Worksheet Performing this analysis will help you to:
fill in the pieces that are required for setting up the VBS group rule
trace ramifications of the rule
analyze restrictions and possible outcomes
Open up the VBS Analysis Template to show users – ask them to locate it in their workbook.
The VBS Analysis Template is a tool to assist you with creating your VBS restrictions. This can be completed either before or in tandem with creating your VBS restrictions in Banner. This template provides you with all the information you need to create a VBS restriction in Banner, including the Banner form names associated with each piece of information needed for creating the restriction.
Filling out the template is not a required step. It is meant to provide you with one document that you can reference in order to have all the information you need to create your rule.
You can also use this template as a supplement to any documentation you produce about the new VBS restriction you are creating.

19. Can use the VBS worksheet to gather the elements

20. How to implement VBS in a nutshell
Decide, with your functional users, on a use case
Identify the details of that use-case in technical terms
Use Banner to reflect those details, or technical elements – use the PII elements already defined where ever possible

21. What are these technical “elements”?
Domain – functional part of the system effected. Ex: Admissions
Domain Driver: Primary driving table. You can look at reference material to find this out
**** A set of Domains and their drivers have already been created in Banner. It is likely that you will use these already existing ones

22. What are these technical “elements”?
Group – a grouping of restrictions
Business Profile – will assign users to this, the users whose access will be restricted
**** You will be creating Groups and Business Profiles

23. Defining the Domain Identify the domain codes using GTVFDMN
Identify the driver rules using GORFDMN
Can look at the domain tables using GORFDPL
A Domain is an area in Banner that has a common driving table. An example of a VBS domain is Student Admissions, where the driver table is SARADAP. All lesser tables in Admissions (SA%) are part of the domain and will follow restrictions based on the rules defined for the Admissions domain.
The VBS rule is written against the driver table. All other tables in the domain are restricted by the rule on the driver table. Usually a driver table will be the parent table of a Banner module. You will have one domain (and corresponding driver table) for each table that your VBS rule will be written against. Refer to your Predicate statements to identify which tables will be assigned as a driver table.
After your functional users define the specific Business cases, the technical user must convert the descriptions into actual SQL criteria in order to build the predicate statement.
The predicate is the SQL clause that defines the access restriction. The predicate statement is the condition (WHERE clause) that is dynamically added to a SQL statement to restrict the rows the user has access to.
Show the VBS Analysis Worksheet to highlight the predicate statements and domains.
Predicate Criteria - Examples:
All users can view all addresses
Predicate Statement: none (user will not have any VBS restrictions on the select privilege)
2. Registrar's Office users can insert, update, and delete addresses where the address type code is equal to 'MA' or 'PR'
Predicate Statement: spraddr_atyp_code in ('MA', 'PR')
3. Finance Office users can insert, update, and delete addresses where the address type code is equal to 'BU' or 'BI'
Predicate Statement: spraddr_atyp_code in ('BU', 'BI')
Domains should only include directly related tables, such as tables within a module. This way you can re-use the domain and domain policy tables in additional VBS rules. If you have a VBS restriction that will write rules against tables that are not within the same area, add additional domains to your VBS restriction for each table the restriction will have a rule written against.
Question: What if you wanted to restrict the list of values from STVATYP?
If you are going to restrict select on a validation table, you need to also restrict tables with same code value.
You will need a separate domain for STVATYP and rules will be parallel to those set up for SPRADDR_ATYP_CODE, SPRTELE_ATYP_CODE, etc.
A number of domain codes and definitions are delivered as seed data. The domain code naming convention is: GB_SPRADDR_VBS, where 'G' represents the Banner system code, (in this case is 'General'), 'B' is hard-coded for 'Banner', 'SPRADDR' is the unique entity name, and '_VBS' is the domain type. The other delivered domain type is '_PII'.
Note: You may want to recommend to clients that they create their own naming convention for locally created domain codes in order to easily differentiate them from the delivered seed values. One recommendation is to include the college or university initials somewhere within the domain code value (ex: CCC_GB_SPRADDR_VBS). Another recommendation is to change the second character of the naming convention from 'B' for Banner, to the unique system letter code the college or university has chosen to use for their locally developed objects (ex: SZ_ADMISSIONS_VBS).
A domain can consist of only one table – the driver table, or many tables called the domain policy tables. If you include multiple tables within your domain, then all the tables will be restricted based on the VBS rule written against the driver table.
For example, the main (or parent) table in the Banner Student Admissions module is the SARADAP table. This table stores application information on a person. Within the Admissions module, there are many other tables which store Admissions data, and these tables are identified because they all begin with the same two characters – 'SA%'. If you wanted to restrict a user from being able to maintain any admissions data based on a field value in the SARADAP table, you would include all the Admissions tables within the same domain.
If your domain includes more than one table, you need to tell Oracle how your domain table is related to your driver table. We do this by adding a partial SQL exists clause statement in the policy table definition.
For example, look at the Banner delivered SB_ADMISSIONS_VBS domain. The additional tables within the domain ('SA%') are lesser tables within the Admissions module, but you want the data you can have access to in these tables to be restricted by the rule you create against the driver table, SARADAP. We use the exists clause to look at the driver table to see if the parent record meets the predicate criteria. If the parent record meets the predicate criteria, we will also restrict access to the joined policy table record.
Go to SAAADMS and briefly explain the function of the Application form. Do a Dynamic Help Query to show that the information is stored in the SARADAP table (pick a field in the top of the form, not the curriculum information because that is stored in a different table). Next go into the Decision form, and briefly explain the purpose of the form, and do a Dynamic Help Query to show that the data is stored in the SARAPPD table.
Log into SQL and do a description on both tables. Show the class which fields are used to join the two tables together.
Open up a Word (or Notepad) document. As a class exercise, ask the class how they would write the select statement to select all decision codes:
Select
Sarappd_pidm,
Sarappd_term_code_entry,
Sarappd_appl_no,
Sarappd_apdc_code
From sarappd
Now we want to restrict the user to only being able to see the decision codes for applications within their college. Since this is stored in the SARADAP table, how do we add the restriction?
Where exists ( select 'X'
from saradap
where saradap_pidm = sarappd_pidm
and saradap_term_code_entry = sarappd_term_code_entry
and saradap_appl_no = sarappd_appl_no
and saradap_coll_code_1 = 'BU' )
We are creating the exists condition for everything up to the college code restriction. When entering in the partial exists clause, we do not need to add the ending right parenthesis because this exists clause will be added to our SQL query dynamically at runtime, then combined with our future predicate statement. The right parenthesis will be automatically generated during this time.
We need a separate policy for each database activity so we can tell the main VBS process what kind of access is occurring. For example, a user may need to set up insert restrictions but allow all select. By separating the policies we achieve this goal: Allowing institutions to set up varying restrictions per table.
The GFVBSADDPOL.SQL and GFGACDROPPOL.SQL scripts are located in the /general/plus directory.
The script needs to be run for each table within your domain, and the script must be run using the BANINST1 user.
You could of course run this for every table in your database, but then you will add minimal performance impacts to your database because Oracle will attempt to locate a FGAC predicate statement every time activity goes against a table.

24. Setting Up the VBS Groups and Group Rules
Groups: This is a group of restriction that are needed based on the use-case. Create these with GTVFGAC
Group Rules: Set up the predicate for group rules with GOAFGAC

25. Establishing the Business Profiles
Create a Business Profile name using the FGAC Business Profile Validation Form (GTVFBPR)
Assign user IDs to the business profile using the FGAC Business Profile Assignments Form (GOAFBPR)
A business profile is created to differentiate the types of users in your group. Decide on unique business profile names to identify the groups of users who will be included in your VBS group.
Introduced to reduce data entry of access restrictions.
Business Profiles are different than BANSECR classes and roles. The maintenance of Business Profiles is meant to be distributed and moved out of the BANSECR schema.
You can consider using your existing Banner security classes as the basis for creating your profiles.
Some schools are considering creating SQL scripts to assign users to Business Profiles. Example: create Business Profiles that are the same name as the BANSECR classes. Write a SQL script to insert the Banner user into the corresponding Business Profiles which have the same name as the BANSECR class name. This way when a new user is created, they can automatically be added to the appropriate Business Profile as needed. You can also use the same idea with copying a new user's access from an existing user's access. Check to see what Business Profiles the existing user has been assigned to and insert a new record for the new Banner user.
Explain to the class that a new VBS rule would normally only be entered by one person at the institution. Since we can not have separate databases for each class participant, we need to create our VBS rules and make them unique to each person. Request that each person enter in their VBS information into Banner by preceding the values with their initials, so each person can create and maintain their own VBS restrictions.
Go into the VBS Template and add the Business Profile names. Then have everyone go into GTVFBPR and enter in their Business Profile codes and descriptions.
You can use VBS_REGISTRARS_OFFICE, VBS_FINANCE_OFFICE as the instructor codes.
Next, go into GOAFBPR and enter in one TRAINXX user into the VBS_REGISTRARS_OFFICE profile and another TRAINXX user into the VBS_FINANCE_OFFICE profile.

26. Defining the Policies
The policies are the actual Oracle objects that govern the use of the VBS elements you are creating
Created by the DBA team
Run gfvbsaddpol.sql to create the policies
Note: can drop the policies by running gfgacdroppol.sql
A Domain is an area in Banner that has a common driving table. An example of a VBS domain is Student Admissions, where the driver table is SARADAP. All lesser tables in Admissions (SA%) are part of the domain and will follow restrictions based on the rules defined for the Admissions domain.
The VBS rule is written against the driver table. All other tables in the domain are restricted by the rule on the driver table. Usually a driver table will be the parent table of a Banner module. You will have one domain (and corresponding driver table) for each table that your VBS rule will be written against. Refer to your Predicate statements to identify which tables will be assigned as a driver table.
After your functional users define the specific Business cases, the technical user must convert the descriptions into actual SQL criteria in order to build the predicate statement.
The predicate is the SQL clause that defines the access restriction. The predicate statement is the condition (WHERE clause) that is dynamically added to a SQL statement to restrict the rows the user has access to.
Show the VBS Analysis Worksheet to highlight the predicate statements and domains.
Predicate Criteria - Examples:
All users can view all addresses
Predicate Statement: none (user will not have any VBS restrictions on the select privilege)
2. Registrar's Office users can insert, update, and delete addresses where the address type code is equal to 'MA' or 'PR'
Predicate Statement: spraddr_atyp_code in ('MA', 'PR')
3. Finance Office users can insert, update, and delete addresses where the address type code is equal to 'BU' or 'BI'
Predicate Statement: spraddr_atyp_code in ('BU', 'BI')
Domains should only include directly related tables, such as tables within a module. This way you can re-use the domain and domain policy tables in additional VBS rules. If you have a VBS restriction that will write rules against tables that are not within the same area, add additional domains to your VBS restriction for each table the restriction will have a rule written against.
Question: What if you wanted to restrict the list of values from STVATYP?
If you are going to restrict select on a validation table, you need to also restrict tables with same code value.
You will need a separate domain for STVATYP and rules will be parallel to those set up for SPRADDR_ATYP_CODE, SPRTELE_ATYP_CODE, etc.
A number of domain codes and definitions are delivered as seed data. The domain code naming convention is: GB_SPRADDR_VBS, where 'G' represents the Banner system code, (in this case is 'General'), 'B' is hard-coded for 'Banner', 'SPRADDR' is the unique entity name, and '_VBS' is the domain type. The other delivered domain type is '_PII'.
Note: You may want to recommend to clients that they create their own naming convention for locally created domain codes in order to easily differentiate them from the delivered seed values. One recommendation is to include the college or university initials somewhere within the domain code value (ex: CCC_GB_SPRADDR_VBS). Another recommendation is to change the second character of the naming convention from 'B' for Banner, to the unique system letter code the college or university has chosen to use for their locally developed objects (ex: SZ_ADMISSIONS_VBS).
A domain can consist of only one table – the driver table, or many tables called the domain policy tables. If you include multiple tables within your domain, then all the tables will be restricted based on the VBS rule written against the driver table.
For example, the main (or parent) table in the Banner Student Admissions module is the SARADAP table. This table stores application information on a person. Within the Admissions module, there are many other tables which store Admissions data, and these tables are identified because they all begin with the same two characters – 'SA%'. If you wanted to restrict a user from being able to maintain any admissions data based on a field value in the SARADAP table, you would include all the Admissions tables within the same domain.
If your domain includes more than one table, you need to tell Oracle how your domain table is related to your driver table. We do this by adding a partial SQL exists clause statement in the policy table definition.
For example, look at the Banner delivered SB_ADMISSIONS_VBS domain. The additional tables within the domain ('SA%') are lesser tables within the Admissions module, but you want the data you can have access to in these tables to be restricted by the rule you create against the driver table, SARADAP. We use the exists clause to look at the driver table to see if the parent record meets the predicate criteria. If the parent record meets the predicate criteria, we will also restrict access to the joined policy table record.
Go to SAAADMS and briefly explain the function of the Application form. Do a Dynamic Help Query to show that the information is stored in the SARADAP table (pick a field in the top of the form, not the curriculum information because that is stored in a different table). Next go into the Decision form, and briefly explain the purpose of the form, and do a Dynamic Help Query to show that the data is stored in the SARAPPD table.
Log into SQL and do a description on both tables. Show the class which fields are used to join the two tables together.
Open up a Word (or Notepad) document. As a class exercise, ask the class how they would write the select statement to select all decision codes:
Select
Sarappd_pidm,
Sarappd_term_code_entry,
Sarappd_appl_no,
Sarappd_apdc_code
From sarappd
Now we want to restrict the user to only being able to see the decision codes for applications within their college. Since this is stored in the SARADAP table, how do we add the restriction?
Where exists ( select 'X'
from saradap
where saradap_pidm = sarappd_pidm
and saradap_term_code_entry = sarappd_term_code_entry
and saradap_appl_no = sarappd_appl_no
and saradap_coll_code_1 = 'BU' )
We are creating the exists condition for everything up to the college code restriction. When entering in the partial exists clause, we do not need to add the ending right parenthesis because this exists clause will be added to our SQL query dynamically at runtime, then combined with our future predicate statement. The right parenthesis will be automatically generated during this time.
We need a separate policy for each database activity so we can tell the main VBS process what kind of access is occurring. For example, a user may need to set up insert restrictions but allow all select. By separating the policies we achieve this goal: Allowing institutions to set up varying restrictions per table.
The GFVBSADDPOL.SQL and GFGACDROPPOL.SQL scripts are located in the /general/plus directory.
The script needs to be run for each table within your domain, and the script must be run using the BANINST1 user.
You could of course run this for every table in your database, but then you will add minimal performance impacts to your database because Oracle will attempt to locate a FGAC predicate statement every time activity goes against a table.

27. Process Flow Diagram Domain Table 1 (GORFDPL)
Domain and driver (GTVFDMN and GORFDMN)
Domain Table 1 (GORFDPL)
Oracle Policy
VBS Group Rules (GOAFGAC) domain Predicate and
Users assignments
GOKFGAC package parses Rules
Domain Table 2
This diagram is also displayed in the workbook.
Domains in Banner are groupings of tables that are impacted one or more VBS rules. They are led by a driver table, which is the table a VBS rule is written against. The rules written against a domain’s driver table will also restrict the user’s ability to perform specified actions on all the tables within the domain.
For each table within your domain, you must create an Oracle policy record. This policy record is stored in Oracle’s dba_policies data dictionary.
When Oracle encounters any activity (select, insert, update, delete) on a table with a policy record, Oracle calls the Oracle function associated with the activity privilege.
The called function identifies the VBS restrictions on the table. These VBS restrictions are called the predicate statement. The predicate statement adds the VBS table restrictions as ‘where’ clauses which will be appended to the end of the SQL activity being requested. The function also will identify the user assignments to the predicate statements.
The function returns the generated predicate statement for the user and parses the ‘where’ condition to the SQL activity in order to limit the user’s ability to perform certain privileges against the table.
POLLING QUESTION
What is the central table within the domain?
Predicate
Policy
Package
Driver

28. Reviewing Policy Records
Object Policy Package Function Sel Ins Upd Del
SPRADDR GOKFGAC_SPRADDR_DEL GOKFGAC F_DELETE_FNC NO NO NO YES
SPRADDR GOKFGAC_SPRADDR_INS GOKFGAC F_INSERT_FNC NO YES NO NO
SPRADDR GOKFGAC_SPRADDR_SEL GOKFGAC F_SELECT_FNC YES NO NO NO
SPRADDR GOKFGAC_SPRADDR_UPD GOKFGAC F_UPDATE_FNC NO NO YES NO
The following script produces the results in the slide. You can run this in SQL to show how it is working on the database.
Column object format a12
Column policy format a15
Column package format a12
Column function format a14
Select
object_name "Object",
policy_name "Policy",
package "Package",
Function "Function",
Sel "Sel",
Ins "Ins",
Upd "Upd",
Del "Del"
From dba_policies
Where object_name = 'SPRADDR‘

29. VBS Restrictions and Banner
Banner Object, or other activity against table
VBS Rules for domain on GOAFGAC
Oracle Table
SPRADDR
GOKFGAC Package
predicate functions
As mentioned earlier, after our VBS rules are created, when Oracle encounters any activity against a table, it will check to see if a policy statement has been added to the table. If it has, the policy will tell Oracle to go the the GOKFGAC package and run the associated function for the privilege requested. The function will look at the Banner VBS tables to see if there is a predicate statement that needs to be appended to the database activity, and will check to see if the user has been assigned to a specific predicate statement. If a predicate statement is found for the user, the function will return the predicate statement and add it dynamically to the end of the SQL request.
VBS adds minimal overhead with calls to GOKFGAC to parse predicate.
Policy

30. Setting Up the VBS Group Rule
Use GOAFGAC to:
set up the predicate for group rules
enter different predicates for the same domain
use the Access to Predicate window of GOAFGAC to define access to the predicate
Referring back to the VBS Analysis Worksheet that we created during the previous steps, we can now assign the VBS rules we defined to the VBS group and business profiles we created earlier.

31. Viewing the Restrictions
Use GOIFGAC to:
display the status of the policy and the predicate for a table
view your predicate and see what restrictions are in effect for each user ID/table
Predicate rules displayed by user and table
Verify the SQL code to confirm that predicate is generating correctly
POLLING QUESTION
Name some areas that the VBS Predicate Rule affects?
Active SCT workflows
SCT Banner objects
Reports and processes
Third-party reporting tools
Database views
SQL Plus statements

32. Test all rules and objects
Create data with intended restricted values
Apply rule to sample User
Test objects with and without VBS
Verify that processing is not adversely impacted by new VBS rule
Create address for individual with types MA, BI, and PR to test our address restriction for a Banner user in each Business Profile
Logon as User with the Registrars Office VBS restrictions
Try query, insert, update and delete on all objects listed on impacted objects list
Test for address codes MA, PR, BI, and BU
Examine outcome and verify results are correct
Logon as User with the Finance Office VBS restrictions
Compare results from both tests. If the object is a process, is the process still working correctly in the restricted environment?
If you have SQL access, have the class log into SQL as one of their TRAIN## users with a VBS restriction. Verify that they have the same access as they do through Banner.

33. Migrate the Rules and Profiles
Use completed VBS Analysis Worksheet
GORFDPL
Activate the tables within the domain(s)
GOAFGAC
Activate the group rule
Set the effective date to a future date

34. End-User Training Document what the error messages mean
New procedure documentation for handling data entry requests that users no longer have access to work on
Contact list of managers/help desk staff to call with problems
Provide your users with documentation that they can refer to in order for them to understand what the error messages mean when encountered.
Provide training and documentation for handling procedural changes to job responsibilities in order to answer the question “Who will do my job now?” You do not want to negatively impact service to your customers when this new restriction is implemented. Does the end user know who the student should go to in order to get a transcript created and sent to their Work address? Who makes changes to the student’s Billing address? You don’t want the student to walk all over campus just to change their Billing address.
Communication is very important in the days and weeks before turning a new access restriction on. You need to be able to answer user questions of why you decided to do this, and handle any unexpected issues that arise from implementing the new rule restriction.
Don’t forget to notify your help desk staff that the new rule is going to be turned on. The help desk staff needs to know how to handle any calls from users about this issue.

35. Review
Before building the VBS group rule, what should be completed to fill in the pieces that are required for setting up the rule, and to be able to trace its ramifications?
True or False: A domain is often the central table for a module or processing area.
Continued on next slide
(Note: These questions are slightly different from those in the workbook. If teaching a class w/ the workbook, this slide could be skipped.)
Analysis Worksheet
False – the Driver table is the central table for a module or processing area
POLLING QUESTION
What is the FGAC Predicate inquiry form?
GOIFGAC
SARADAP
GOKFGAC
SORLCUR

36. Review, Continued Which form is used to:
enter the domain driver ________
define the domain codes and identify the domain as a VBS type ________
enter the domain tables ________
(Note: These questions are slightly different from those in the workbook. If teaching a class w/ the workbook, this slide could be skipped.)
3. FGAC Domain Driver Rules (GORFDMN)
FGAC Domain Validation (GTVFDMN)
FGAC VBS Table Rules Form (GORFDPL)

37. Day-to-Day Operations

38. Viewing Results
Data a user is allowed to view is determined by the setup of the security
A user won’t see the data when “select” restrictions are in place
Users can see that they have VBS restrictions because the FGAC toolbar icon will be highlighted.
Querying data:
Trying to select rows beyond what you can select will not show error message (Record not found is not an error)

39. Viewing and Changing Data
In some cases, a user may be allowed to view all data but can change only the data that meets specific criteria.
Need to train users on vague error message statements
Oracle Bug
Oracle’s behavior does not return an error message if an update/delete is attempted on a table where the user has full select privileges
Refer to the workbook and review the specific policy error messages
Reports and Processes show the actual Oracle Error in the log file
Self Service shows Oracle Error on new error page
Oracle Bug:
Oracle’s behavior does not return an error message if an update/delete is attempted on a table where the user has full select privileges
Oracle Bug
Oracle does not note the access restriction and returns record updated/inserted/deleted successfully
APIs are programmed to show an error when this happens
APIs interrogate ROWCOUNT for possible error
For the forms that have not been re-written to run off of the APIs, users will encounter the Oracle error. Basically, any form which does not have the new tab user interface will not be using the APIs.

40. Security Overview

41. VBS and Banner Security
GSASECR
JANE_DOE CLERK_CLASS
JANE_DOE AR_MGR_CLASS
Banner Form
SPAIDEN
Address Tab
MA Mailing
GSASECR
CLERK_CLASS SPAIDEN BAN_DEFAULT_M
CLERK_CLASS SPAPERS BAN_DEFAULT_M
CLERK_CLASS GOAEMAL BAN_DEFAULT_M
Continued on next slide

42. VBS and Banner Security
GOKFGAC
GORFDPL
f_select_fnc
GB_SPRADDR_VBS SPRADDR
Banner Form
SPAIDEN
GOAFGAC
Address Tab
GB_SPRADDR_VBS REG_CLERK_PROFILE
MA Mailing
GOAFBPR
REG_CLERK_PROFILE JANE_DOE
GOAFGAC
GB_SPRADDR_VBS SPRADDR_ATYP_CODE in (‘MA’, ‘PR’)

43. VBS and ORACLE Security
ORACLE Role Level Security
JANE_DOE STUDENT_QRY_ROLE
JANE_DOE AR_QRY_ROLE
SQL Query
Select * from SPRADDR
ORACLE Role
STUDENT_QRY_ROLE Select SPRIDEN
STUDENT_QRY_ROLE Select SPRADDR
STUDENT_QRY_ROLE Select SPBPERS
Continued on next slide

44. VBS and ORACLE Security
GOKFGAC
GORFDPL
f_select_fnc
GB_SPRADDR_VBS SPRADDR
GOAFGAC
GB_SPRADDR_VBS REG_CLERK_PROFILE
SQL Query
GOAFBPR
REG_CLERK_PROFILE JANE_DOE
Select * from SPRADDR
GOAFGAC
GB_SPRADDR_VBS SPRADDR_ATYP_CODE in (‘MA’, ‘PR’)

45. Review How do you determine what restrictions are in place for you?
True or False: The data a specific Banner User ID is allowed to view is determined by the setup of the security.
True or False: A User ID is not allowed to view a specific type of data. When this user attempts to view that data, he or she will receive an error message.
After you log into Banner, an icon on the toolbar indicates whether FGAC is in place for your User ID. Clicking the icon will access the FGAC Predicate Inquiry Form (GOIFGAC), which provides detailed information on the kind of restrictions that are in place for your user ID.
True.
False. The data is not displayed. It will appear to the user as if no data exists.

46. Questions and Answers POLLING QUESTION
What message appears if a user attempts to insert a row into a table that is not allowed based on the VBS rules?
“Security violation”

47. Personal Identifiable Information

48. Personal Identifiable Information
PII secures Person information, and is only on the selection of data
Philosophy of PII: User can access PII based on their business needs (job responsibilities)
We deliver PII on the SPRIDEN table.
Allows user access to personal information for only those people they need to see as part of their job responsibilities:
If you work in the Admissions Office, you can only view personal information for people who have applied for Admission to the institution. This means that the user should not be able to see information about employees, vendors, etc who have never applied to the institution.
PII is not for everyone! Canadian schools may be required to implement PII in order to comply with their Federal regulations. Many schools will not need to implement PII because users in some institutions have job crossover which requires them to have the ability to view a larger population of people within Banner. Community Colleges in particular will probably not see any benefit to implementing PII at their institution.
One way you may choose to implement PII would be to exclude all users from PII restrictions, except a selected group of users that you really do want to restrict the persons that user has the ability to view information on. (Work Studies, certain groups of people who need access to Finance information, etc)

49. How does PII work?
To have access to a SPRIDEN row, the PIDM must have a row in one of the PII Domains the user is assigned
If the person has a record, the Banner user can view the person’s information.
If the person does not have a record, the Banner user receives a message saying that you do not have permission to view that ID.
PII domains are similar to VBS domains. The difference is that PII domains include only one table, and the predicate statement is always “select ‘X’ from XXXXXXX where XXXXXXX_PIDM = :pidm”. In PII we still need to establish the domains, but we do not have to create the predicate statements.

50. VBS and PII Both VBS and PII use FGAC to restrict the data
Both restrict data but in different ways
Implementation differences
VBS provides row level security based on any column value
PII provides row level security specifically on the _PIDM column
In other words:
PII restricts the people (PIDM) a Banner user is allowed to access (view) within an object.
Within that object, VBS will restrict the Banner user from viewing specific data about the person they have permission to view.
PII and VBS do not require each other - you can choose to implement one or the other, or both can be used together.
PII is system wide! Once turned on, all Banner users are impacted
VBS is enabled only for those assigned to a rule

51. PII Restrictions and Banner
Domain Tables
Oracle Table
SPRIDEN
Query ID information
Policy
GOKFGAC
f_find_pii_domain
PII Domain Processing Areas
PII user domain assignments on GOAFPUD
As mentioned earlier, we deliver PII on the SPRIDEN table, and PII is specifically associated with the select Oracle privilege.
When Oracle encounters select activity against the PII table, whether through Banner or SQL, the policy record will run the f_find_pii_domain function from GOKFGAC in order to determine if the user has a PII domain assignment.
If a PII domain is found for the user, the function will return the generated predicate statement and add it dynamically to the end of the SQL request.
The PII domain tables tells which ID data is secured for the user.

52. PII Process Flow – By Business Profile
Functional User Tasks
Combined Tasks
Technical User Tasks
Create Business Profiles
Identify and Setup Users
Setup PII Domains
Assign Profiles to PII Domains
Test Restrictions
Like VBS, PII restrictions are based on a functional business need. The functional users define the PII restrictions, and the user or groups of users who will be impacted by each specific rule within the restriction. The technical staff works with the functional users to create business profiles, which are based on the groups of users defined by the functional staff. You can use existing VBS-generated Business Profiles, or create new Business Profiles specifically for a PII restriction. The technical staff then assigns users to the business profiles.
The technical users work with the functional users to identify the driver tables that will be impacted by the PII restriction. Next, the technical users create the PII domains, and assign the specific rules to the identified user or groups of users.
The technical users then verify that the predicate statements are being generated correctly for each table and restricted user.
After the rules have been verified, the functional users test that the PII restriction works as requested.
Once the PII restriction has been tested, the functional users need to train the end users on the changes to their job. In conjunction with this, the technical users will move the new PII restriction from the pre-production database to the production database, and schedule the go-live date with the functional users.
Migrate Rules to Production
Verify Restrictions

53. Questions and Answers POLLING QUESTION
What message appears if a user attempts to insert a row into a table that is not allowed based on the VBS rules?
“Security violation”

54. Protection of Sensitive Data

55. Protection of Sensitive Data
Concealing
Masking
Removing visibility
The protection of sensitive data is another new feature of Banner 7.
This functionality is available on all Banner forms. Not available on reports and processes.
It is comprised of the following functionality:
Concealing: Changing a field value to all ‘*’ characters
Masking: Showing part of the field value and concealing or removing the remaining part of the field value
Visibility: Removing visibility for a field from the form

56. Process Introduction Identify the fields that need protection
Establish the fields that need protection
Review the protected fields

57. Identify Fields that Need Protection
Form name
Block name
Field name
Data type
Field length
Use the Help (Item Properies) to get all of the above information for each field you want to add protection to.
If you can not click in the field to get the information, then a technical user will need to review the form’s
Source code to obtain the information.
CLASS EXERCISE:
1. Go to SPAIDEN and click on the Biographical Tab.
2. If the birth date, SSN, and/or Citizenship code values are missing, fill them in and save the record.
3. Click in Birth date field and go to ‘Help (Item Properties)’. Note where they can identify the above information.
4. Do the same for the SSN and the Citizenship code fields.

58. Establish the fields that need protection
Define the fields that need protection in the form GORDMCL
Add the field protection rule in the form GORDMSK
Defining the fields:
This is basically creating a data dictionary entry for Banner so it knows that we are defining a data restriction on this field within a specific table.
Enter in the information obtained in the previous step
CLASS EXERCISE:
Ask for 3 volunteers to each enter in the SSN, Birth Date, and Citizenship fields.
Add the protection rule:
Enter the specific protection rules for each field
Apply to:
All Users
Business Profile
Single Banner User
Apply to: All users, Business Profile, Single Banner user – one or the other, can not choose more than one.
Everyone can do this:
Add record for birth date. Keep visibility checked, and conceal unchecked. In masking area, select the DD-MON mask.
For “apply formatting to”, uncheck “all users” and enter in each person’s TRANINXX user.
Add record for SSN. Keep visibility checked, and check the conceal indicator. Apply formating to the TRAINXX user.
Add record for Citizenship code. Uncheck visibility. Apply formatting to the TRAINXX user.
5. Go back to SPAIDEN and show the results.
Sequence numbers:
Banner will review each protection rule for the form and items, starting with sequence number 1. When you match the first
‘Apply to’ area of a rule, the selected protection rule will apply to you. If none of the rules apply to you, then you have full
Privs to that field.
So, if you wanted only a select group of users to have the ability to update a field, and conceal it from the rest, you can
Add two rules: #1 with visibility checked and no masking for only the group that should have access, and #2 with concealing
turned on and set for all users.

59. Review the protected fields
Is the form displaying the information correctly?
Do you need to protect any other fields or icons?
What other forms display the same data?
Go into SPAIDEN. Show how each field was masked, concealed, and removed.
Ask if anyone can identify any problems with the information we protected.
Note how age still appears – need to review the form for issues like this.
Try to find out what the Age field name is. Since it is a calculated value within the form, you cannot click into the field to do a Count Query Hits.
You may be able to guess the field name (PERS_AGE) based on the form functionality for the Sex field. Otherwise someone will need to review the Oracle Form source code in Forms Developer in order to identify the field name. Remove field if you want to in order to show that it works correctly.
What about the Citizenship code? The description still appears, so is this protecting the information you wanted to hide from the user? In some cases yes – you may want to remove the validation code field so users can not change it, but leave the description so they know what the value is.
Also, note that the calendar icon appears. If you cannot see the entire birth date, the user should not have access to click on the calendar button.
The citizenship LOV icon is also still there, but when you click on it it tells you that there is not LOV for that field. Perhaps the icon should also be removed in order to make the form look more complete and reduce questions about why icons are there that do not work correctly.
PERS_SEX – The correct way to conceal or remove fields using a radio button or validation table, includes needing to enter both the character field and the icon or button associated with the field:
For SPBPERS_SEX you should also remove the PERS_SEX field which is the button on the form

60. Protection of Sensitive Data – Issues
Oracle does not support character masking
Do not protect required fields
Trickle down effect -
Some fields are displayed on more than one form
Have you protected the correct data?
How does the form look after removing a field?
Character masking is not supported within Oracle Forms. The major issue with this – SSN is a character field. You will not be able to mask a character field in Banner without a modification to Baseline. If you are interested in doing this, you will need to add a procedure to the end of a post-query trigger within the form. For more information about this topic, refer to the FGAC Handbook
SCT delivers GOAMTCH with character masking on the SSN field as Baseline. At this time, this is the
only form we support SSN masking on. Later releases of Banner 7 will provide support for the additional
SSN field masking. Refer to Product Calendar for specific details.
Do not protect required fields for users who have maintenance on the form because they will not be able to change
The field if needed or they will not be able to insert the record.
Trickle down effect –
SSN (for example) is displayed in every Banner system. Make sure you protect the field in all the forms a value is displayed in.
Are there any fields on the form that we forgot about that may provide the same information to the user that we wanted to protect from them?
After removing an item from a form, are there any other items on the form that are left behind that may also need to be removed?

61. Questions and Answers

62. Thank you for your participation