Improve view bypass lab before and after flow

scenarios/04-view-bypass-mac/WORKSHOP.md

@@ -21,6 +21,7 @@ This workshop demonstrates why access rules should be enforced on the protected
 | --- | --- | --- |
 | `emma` | Account owner | Only accounts owned by Emma. |
 | `marvin` | Account owner | Only accounts owned by Marvin. |
+| `erik` | Account owner | Only accounts owned by Erik. |
 
 ## Before You Begin
 
@@ -75,12 +76,43 @@ The script creates:
 ```sql
 CREATE END USER emma IDENTIFIED BY "Welcome1_DDS!";
 CREATE END USER marvin IDENTIFIED BY "Welcome1_DDS!";
+CREATE END USER erik IDENTIFIED BY "Welcome1_DDS!";
 CREATE DATA ROLE account_owner_role;
 ```
 
 ## Lab 2 - Demonstrate The View Bypass Risk
 
-### Task 2.1 - Query The Legacy View
+### Task 2.1 - Connect As Emma Before DDS
+
+Exit the administrator session:
+
+```sql
+exit
+```
+
+Connect as Emma:
+
+```bash
+sql 'emma/Welcome1_DDS!@ddslab_tunnel'
+```
+
+Emma represents an account owner. Before DDS enforcement, she still has a broad legacy role, so this section demonstrates why view-based controls and object grants can be risky.
+
+### Task 2.2 - Query The Base Table Directly Before DDS
+
+```sql
+ALTER SESSION SET CURRENT_SCHEMA = ADMIN;
+
+SELECT account_id, account_name, owner_name, region, balance
+FROM dds_mac_accounts
+ORDER BY account_id;
+```
+
+Expected result before DDS: Emma can see `Account Alpha`, `Account Beta`, and `Account Gamma`, even though only `Account Alpha` belongs to her.
+
+This is the direct table access path.
+
+### Task 2.3 - Query The Legacy View Before DDS
 
 ```sql
 SELECT account_id, account_name, owner_name, region, balance
@@ -88,11 +120,34 @@ FROM dds_mac_accounts_view
 ORDER BY account_id;
 ```
 
-Expected result before DDS: the view may expose accounts belonging to multiple owners.
+Expected result before DDS: the view also returns accounts owned by multiple users.
+
+This is the alternate access path. The important point is not that the view itself is bad; the risk is relying on a specific access path as the only security boundary.
+
+### Customer Message
+
+Before DDS, Emma can reach the same overexposed data through both paths:
+
+```text
+Direct table query -> all accounts
+Legacy view query  -> all accounts
+```
+
+The business rule "Emma should only see Emma's account" is not being enforced at the protected data boundary yet.
 
 ## Lab 3 - Apply Oracle Deep Data Security
 
-### Task 3.1 - Apply Data Grants
+### Task 3.1 - Reconnect As ADMIN
+
+```sql
+exit
+```
+
+```bash
+sql admin@ddslab_tunnel
+```
+
+### Task 3.2 - Apply Data Grants
 
 ```sql
 @scenarios/04-view-bypass-mac/sql/03_data_grants.sql
@@ -110,9 +165,17 @@ CREATE OR REPLACE DATA GRANT mac_account_owner
 
 This filters accounts to the authenticated owner. The script enables DDS on `DDS_MAC_ACCOUNTS`.
 
+In this lab, the predicate compares the account owner with the active DDS end-user context:
+
+```sql
+WHERE UPPER(owner_name) = ORA_END_USER_CONTEXT.username
+```
+
+That means Emma, Marvin, and Erik can run the same SQL, but the database returns different rows for each persona.
+
 ## Lab 4 - Validate Table And View Access
 
-### Task 4.1 - Test Emma
+### Task 4.1 - Test Emma After DDS
 
 ```sql
 exit
@@ -126,9 +189,18 @@ 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.
+Expected result: Emma sees only `Account Alpha` from both table and view paths.
 
-### Task 4.2 - Test Marvin
+The same two access paths are tested again:
+
+```text
+Direct table query -> only Account Alpha
+Legacy view query  -> only Account Alpha
+```
+
+The SQL did not become smarter. The database security boundary became mandatory.
+
+### Task 4.2 - Quick Validation With Marvin
 
 ```sql
 exit
@@ -142,7 +214,35 @@ sql 'marvin/Welcome1_DDS!@ddslab_tunnel'
 @scenarios/04-view-bypass-mac/sql/04_test_queries.sql
 ```
 
-Expected result: Marvin sees only his authorized account.
+Expected result: Marvin sees only `Account Beta` from both paths.
+
+### Task 4.3 - Quick Validation With Erik
+
+```sql
+exit
+```
+
+```bash
+sql 'erik/Welcome1_DDS!@ddslab_tunnel'
+```
+
+```sql
+@scenarios/04-view-bypass-mac/sql/04_test_queries.sql
+```
+
+Expected result: Erik sees only `Account Gamma` from both paths.
+
+### Customer Message
+
+After DDS, the result is consistent regardless of the path:
+
+```text
+Emma   -> Account Alpha only
+Marvin -> Account Beta only
+Erik   -> Account Gamma only
+```
+
+This shows the value of DDS versus relying only on view logic, application SQL, BI filters, or agent-generated SQL.
 
 ## Lab 5 - Clean Up
 
@@ -165,7 +265,7 @@ exit
 | --- | --- |
 | `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. |
+| `END USER` | `emma`, `marvin`, `erik`; 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. |
@@ -177,4 +277,3 @@ The trust chain is: **end-user identity -> account owner role -> owner data gran
 - 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.
-