Implementing Fine Grained Access Control and Masking

What is FGAC? Fine Grained Access Control (FGAC) in Oracle 8i gives you the ability to dynamically attach, at runtime, a predicate (the WHERE clause) to all queries issued against a database table or view. (Expert One-on-One Oracle by Tom Kite) Other terms for FGAC are Row Level Security and Virtual Private Database (VPD). FGAC is an Oracle feature that SCT has implemented within the Banner framework.

What is FGAC cont’d FGAC can be implemented with or without Value Based Security. FGAC is implemented for specific tables, and works at both the form and table level. Masking is NOT FGAC. FGAC restricts access at the row level

Quick Overview of how FGAC works Assume FGAC has been implemented for table SPBPERS: User JSMITH has BAN_DEFAULT_M access to SPAPERS. We want him to see all people who are designated General Student on form GUASYST. To do this, we associate the SB_GENSTUDENT_PII with JSMITH. When JSMITH queries a person in SPAPERS which has an SGBSTDN record, he will see and have access to this record. If JSMITH tries to query a person which does not have an SGBSTDN record, he will get into the form but will not see anything, as if the record does not exist at all. This will carry over into SQL queries against SPBPERS. We are using FGAC on SPBPERS & GOBTPAC.

Prior to implementing FGAC: The most time consuming part for us was trying to nail down all the department heads to determine who can see what. When we explained to users that we were going to restrict access to SPBPERS data based upon job function we received feedback that certain users would need to see a cross section of records and could not be limited. To sum up, the first step is to define Business Profiles and assign users to the applicable profiles.

Implementing FGAC Step 1: GTVFBPR Create Business Groups Example: Similar to GSASECR where you can give a user direct access to a form or assign forms to security classes.

Step 2A GORFDMN Check the Enable PII box for all PII(s) to be used

Step 2B: GOAFBPI Link applicable PII(s) with Business Profiles

Step 3: GOAFBPR Assign Users to Business Profiles (This is ongoing maintenance)

Shows Business Profile Groups and associated PII Domains.

Step 4: GORFDPI 1. Make sure policies are enabled on form GORFDPI for SPBPERS and GOBTPAC and the Active Indicator is checked for these tables. Make sure the Active Indicator is unchecked for SPRIDEN.. 2. Log in as baninst1 and position in the links directory, run gfpiiaddpol.sql

Checking Exempt from PII will bypass FGAC processing for this user in all Banner Forms. FGAC will remain in place at the table level. (Defect or feature?) Checking Cross Domain PII will allow user to by pass FGAC by entering through a search Form (SOAIDEN, etc).

In order to grant full database access to certain users we created a Business Profile which has all PII Domains associated with it. This is needed for users who will need full SQL row access.

User IDs we have associated with the EXEMPT_FROM_FGA profile User IDs we have associated with the EXEMPT_FROM_FGA profile. BANINST1 is a definite along with whatever USER ID performs table builds.

Shows the predicate that is being used on each select statement issued against applicable FGAC table.

GORFEOB Job Submission process are placed here to exempt from FGAC GORFEOB Job Submission process are placed here to exempt from FGAC. FYI, Job submission jobs which call database procedures will be processed under FGAC.

Things to keep in mind If a person is not a member of a PII domain they will have zero access to the table.  All users who should have access to the table need to be added to a domain.  From here on out, when you create a Banner account for a new employee or give some access to a specific form with PII restrictions, you must add this person to an applicable domain. I added the GOAFBPR form to the GSASECR options menu, so as I give access Forms, I can then add to the Business Group. If you do a select count(*) from spbpers, you will return the total of all rows.  If you turn FGA on for spbpers and are assigned to the student domain and do a select count(*) from spbpers, you will return the total for only students.  Everyone at your institution needs to know this up front, this can be misleading for statistical purposes.  Therefore you will need to exclude certain master user accounts from all PII processing to get accurate table statistics (example BANINST1, WWW_USER). If you have customized table builds based on the FGA table, you will either need to place into above referenced exclusion group or prior to builds turn off FGA, and turn back on when finished example SCT needs to add a PII to capture people without any GUASYST records. We created our own PII to do this, will cover in the Technical presentation. Since FGAC excludes entire rows, custom queries and reports will need to be reexamined. You will want to make sure that all references to the table using FGAC be outer joined, otherwise entire rows will be excluded.

FGA Technical Creating a custom PII

FGA Technical

FGA Technical

FGA Technical

FGA Technical

FGA Technical BEGIN gokfgac.p_turn_fgac_off; Table build code gokfgac.p_turn_fgac_on; END;

Masking Masking is an SCT feature for Oracle Forms You may mask a column fully or partially (partially masking a varchar2 column requires a small form mod, will cover this in technical presentation). Masking is all or nothing. Once Masking is enabled for a user every record will be masked, unlike FGAC where you can grant access to certain records and restrictions on others. I have an RPE(#:1-G3JR6) to allow the same type of functionality for Masking. Because Masking is an Oracle Form feature, Masking will not carry over into SQL queries.

Quick Overview of how Masking works Assume spbpers_ssn has been masked on form SPAPERS for user JSMITH and he has BAN_DEFAULT_M: When JSMITH enters into SPAPERS he will be able to see all columns except SSN, which will be masked. He will be able to update all columns except SSN. Every record he queries in SPAPERS will have the SSN masked, there is no PII processing. Masking is all or nothing. Masking does not carry over into SQL, and each form a user has access to must be set up to Mask. We are masking SSN (birthdate soon) on SPAPERS, SPAIDEN, APAIDEN & APSABIO. We are using a combination of FGAC and Masking on Personal Data.

GORDMCL Here you list the Form Item/s to be Masked on a particular Form.

GORDMSK Establish Masking Rules

Masking Technical

Masking Technical

Masking Technical

Masking Technical

Masking Technical