Creating a Fine-Grain Access Control (FGAC)

Owned by Denise Kidd
Last updated: Aug 05, 2024
4 min read

Business case: Allow NTC advisors to see all overrides entered in SFASRPO, but can only add/delete/update override records with the ‘PRE-REQ’ Permit Type.

Identify or define a new domain - GTVFDMN

Filter GTVFDMN to determine if your domain exists. Domains should be named based on the affected table and should follow the following naming convention:

SB_SFRSRPO_VBS

  • S: Student

  • B: Banner

  • SFRSRPO: affected table

  • VBS: indicates that we are using value-based security on this domain.

Note the existing domain. To create a new domain:

Click Insert. Using the naming convention, define a new name and give it a description. Save.

image-20240719-131120.png

Connect the domain to the driver table - GORFDMN

If you created a new domain, connect it to its driver table in GORFDMN.

Click Insert. Select or enter the domain. Enter or select the driver table. Select or enter VBS. Save.

image-20240719-130819.png

Create/identify the business profile code - GTVFBPR

In this step we’re creating or identifying the code representing the group of individuals this rule applies to.

Select an existing business profile or create a new one by clicking Insert. Enter the code and Description. Save.

Business profiles are groups of individuals; these individuals are being grouped based on their need to do the task the rules allow them to do.

Create/identify the group - GTVFGAC

A group is made up of one or more rules. In this step, we’re creating/identifying the group code we’ll later link the rules to.

Determine if a group exists to which you are adding this rule. If not, create a new group by clicking Insert. Enter the Code and Description. Save.

Groups should be named oriented with their function.

Create the rules for the domain - GORFDPL

Important historical context

Prior to July 2024, SQL was entered in GORDFDPL instead of GOAFGAC. When maintaining rules created prior to this point, use GORFDPL.

Ellucian recommends as a best practice, because domains are aligned with a table, refrain from creating domain level rules unless you have an exceptional circumstance.

Click Insert. Select/enter the domain and table. Check the Active Indicator box. Save.

If you had to create a new domain in the first step OR you created a rule container for an existing domain with a new associated table: have a DBA run gfvbsaddpol.sql to create Oracle policies for all tables defined for the domain before moving to the next step. If available, use GORFDPS to create the policies instead of running the script.

If you used an existing domain + table combination, move to the next step after you’ve created the container. In this circumstance, running the script isn’t needed.

Create rules for the group - GOAFGAC

Enter the group. Go.

Check the Active indicator. Next block. Enter the appropriate SQL code in the Predicate field. Click the Validate SQL button (optional but recommended). Save.

If you don’t know the affected field in the table, click the Column button. Selecting the Column Name will populate it in the Predicate field.

Set access to predicate - GOAFGAC

In the Access to Predicate tab, select the business profile, or group of users, the rule applies to. Check the functions you want to apply this limitation to.

You could also or instead identify users for access to predicate settings. This could be helpful when testing: enter a user who may not be assigned to the business profile and use the same checkbox pattern as for the profile.

Save.

Add users to the business profile - GOAFBPR

If the users this rule applies to has previously been established, you can skip this step.

Select/enter the Business Profile. Go.

Enter the User IDs for all users should should be in this business profile. Save.

Testing

Identify users

Identify a user in the business profile and a user NOT in the business profile. Impersonate these users in TEST.

In this example, we’re limiting those in the business profile to only adding/deleting/updating the PRE-REQ override code, but they need to see all existing overrides in SFASRPO.

Expected results

User in the business profile

  • All existing overrides are visible.

  • When attempting to enter a PRE-REQ override, the record is saved:

  • When attempting to enter a CAPACITY override, they get an error and the record is not saved:

  • When attempting to delete an existing CAPACITY override, they get an error and changes are not saved:

  • When attempting to update an existing DEPARTMENT override, they get an error and changes are not saved:

User NOT IN the business profile

All existing overrides are visible, and the user can add/delete/update existing overrides with all changes saved.