oracle-deep-data-security-lab/scenarios/04-view-bypass-mac/WORKSHOP.md

Workshop - Prevent View Bypass With Oracle Deep Data Security

About This Workshop

This workshop demonstrates why access rules should be enforced on the protected data, not only in application SQL or views. Before DDS, a legacy view can expose accounts outside the user's ownership. After DDS, the base table and alternate access paths respect the same boundary.

Workshop Goals

• Create an account table and a legacy view.
• Show how a view can become an alternate access path.
• Apply DDS to enforce account ownership at the table boundary.
• Validate that table and view access return the same authorized subset.

Estimated Time

20 to 30 minutes.

Scenario Summary

Persona	Business Role	Expected Access After DDS
emma	Account owner	Only accounts owned by Emma.
marvin	Account owner	Only accounts owned by Marvin.

Before You Begin

cd <repo-root>
export TNS_ADMIN=<wallet-directory>
sql admin@ddslab_tunnel

SQLcl note: after running @file.sql, do not type /.

Connection alias note: ddslab_tunnel is the TNS alias configured in the wallet tnsnames.ora for this lab. If your wallet uses another alias, replace ddslab_tunnel with your own service alias.

Lab 1 - Prepare The Environment

Task 1.1 - Reset The Scenario

@scenarios/04-view-bypass-mac/sql/99_reset.sql

Task 1.2 - Create Table And View

@scenarios/04-view-bypass-mac/sql/00_schema.sql

The script creates:

Object	Purpose
DDS_MAC_ACCOUNTS	Protected base account table.
DDS_MAC_ACCOUNTS_VIEW	Legacy view over the base table.

Task 1.3 - Load Accounts

@scenarios/04-view-bypass-mac/sql/01_seed_data.sql

Example accounts include owners emma, marvin, and erik.

Task 1.4 - Create Personas And Roles

@scenarios/04-view-bypass-mac/sql/02_identities.sql

The script creates:

CREATE END USER emma IDENTIFIED BY "Welcome1_DDS!";
CREATE END USER marvin IDENTIFIED BY "Welcome1_DDS!";
CREATE DATA ROLE account_owner_role;

Lab 2 - Demonstrate The View Bypass Risk

Task 2.1 - Query The Legacy View

SELECT account_id, account_name, owner_name, region, balance
FROM dds_mac_accounts_view
ORDER BY account_id;

Expected result before DDS: the view may expose accounts belonging to multiple owners.

Lab 3 - Apply Oracle Deep Data Security

Task 3.1 - Apply Data Grants

@scenarios/04-view-bypass-mac/sql/03_data_grants.sql

The main grant is:

CREATE OR REPLACE DATA GRANT mac_account_owner
  AS SELECT
  ON dds_mac_accounts
  WHERE owner_name = ORA_END_USER_CONTEXT.username
  TO account_owner_role;

This filters accounts to the authenticated owner. The script enables DDS on DDS_MAC_ACCOUNTS.

Lab 4 - Validate Table And View Access

Task 4.1 - Test Emma

exit

sql 'emma/Welcome1_DDS!@ddslab_tunnel'

@scenarios/04-view-bypass-mac/sql/04_test_queries.sql

Expected result: Emma sees only her authorized account from both table and view paths.

Task 4.2 - Test Marvin

exit

sql 'marvin/Welcome1_DDS!@ddslab_tunnel'

@scenarios/04-view-bypass-mac/sql/04_test_queries.sql

Expected result: Marvin sees only his authorized account.

Lab 5 - Clean Up

exit

sql admin@ddslab_tunnel

@scenarios/04-view-bypass-mac/sql/99_reset.sql
exit

What You Built

Component	Purpose
DDS_MAC_ACCOUNTS	Protected base table.
DDS_MAC_ACCOUNTS_VIEW	Legacy view used to demonstrate alternate access paths.
END USER	emma, marvin; account owner personas.
DATA ROLE	account_owner_role; owner authorization profile.
DATA GRANT	Filters rows by owner_name = ORA_END_USER_CONTEXT.username.
SET USE DATA GRANTS ONLY	Enforces DDS on the base table.

The trust chain is: end-user identity -> account owner role -> owner data grant -> protected table access.

Product Manager Talking Points

• Views are useful, but they should not be the only security boundary.
• DDS protects the data regardless of the access path.
• This reduces bypass risk from direct SQL, legacy views, and reporting tools.