Limiting users’ access to data is still a thorny issue in many Oracle shops: How do we insure only the right people view - much less change! - only the data they’re allowed to? We’ll show you how we solved those issues for a large government agency with hundreds of external users via Real Application Security (RAS), whether they’re using APEX applications or direct-access tools like SQLcl.
Delhi Call Girls Punjabi Bagh 9711199171 ☎✔👌✔ Whatsapp Hard And Sexy Vip Call
Access Denied: Real-World Use Cases for APEX and Real Application Security
1. Access Denied:
Real-World Use Cases for APEX
and Real Application Security
Jim Czuprynski
@JimTheWhyGuy
Zero Defect Computing, Inc.
Karen Cannell
@thtechnology
TH Technology
2. Jim Czuprynski: Who Am I, and What Am I Doing Here?
➢E-mail me at jim@jimthewhyguy.com
➢Follow me on Twitter (@JimTheWhyGuy)
➢Connect with me on LinkedIn (Jim Czuprynski)
Traveler & public speaker Summers:
Wisconsin
Winters:
Illinois
Cyclist
XC skier
Avid
amateur
bird
watcher
Oldest dude in
martial arts class
4. Karen Cannell: About Me …
• TH Technology – Oracle Consulting Services, APEX Focus
• Mechanical/SW Engineer - Analyzed, designed, developed, converted, upgraded,
enhanced legacy & Oracle database applications for 30+ Years
• Web/APEX applications for Govt, Medical, Engineering, Fisheries since HTMLDB
• ODTUG Vice President, Kscope Conference Chair, Editor Emeritus, Technical
Journal
• APress Author
• Oracle ACE Director
APEX Grids: Editable Essentials
➢E-mail me at kcannell@thtechnology.com
➢Follow me on Twitter (@thtechnology)
➢Connect with me on LinkedIn (Karen Cannell)
5. A Tricky Business Problem, Vexing DevOps As Well As DBAs
The Business Problem:
A government agency’s complex data warehouse-based
application must strictly limit each user to access only the
confidential data they are permitted to view
Access Methods:
• Most users access their data via desktop or
mobile apps written in APEX …
• … but a small number of privileged users
leverage SQL*Plus or other native SQL tools
Environment:
• Data model includes multiple schemas, each
containing complex views and MVs
• Multiple APEX applications developed / evolved
over 20+ years, dating back to HTMLDB
Security:
• Strict data access and confidentiality rules must be enforced, based on complex
overlapping requirements from multiple state and federal government agencies
• DevOps are tired of rewriting / duplicating security rules throughout several applications
• DBAs are tired of responding to requests for out-of-band custom reporting / extracts
6. You Said VPD. Did You Mean RAS?
Good news! Our
client suggests
we implement
VPD!
Virtual Private Database (VPD): Relatively ancient
• Uses query rewrite via WHERE clause predicates to limit
data access
• Focused on database, not application, technology
• Inadequate management of newer identity management
techniques
Real Application Security (RAS): VPD 2.0
✓Much more secure
✓Extremely flexible security policies
✓Scalable to thousands of different users connecting via
SQL tools / APEX / SSO
✓Cost effective – implement it just once
✓Security is enforced within the DB kernel
Uh-huh, that’s
nice! Did you
tell them about
RAS?
7. How RAS Handles Data Access Requests
APEX, Java, OCI
(aka Web
Connections)
SQLPlus, SQLcl
(aka Direct
Connections)
Oracle Database
RAS Security
Policies
Data Realm
ACLs
ACE
ACE
ACE ORDERS
LINEITEM
SUPPLIER
CUSTOMER
1. Users initiate
DB connections
as RAS users
2. RAS determines security
policy based on connecting user
3. Appropriate permissions to allow or
deny access to data within tables are
applied via Access Control Lists (ACLs)
4. Only appropriate data
is returned (if any at all!)
??
8. RAS: Components and Concepts
Every application session that
needs security implemented is
assigned a RAS session during
connection to the database
Note that direct
connections are assigned
a RAS session as well
Access to database objects
and the data stored within is
strictly controlled through
RAS security policies as well
10. DW_SC and SAFIS_SC Security Classes control access to all objects in ACCSP schemas
RAS Components: ACLs, ACEs, Realms, Policies, & Classes
App Roles
App Users
JSIMPSON
KCANNELL
JIMCZUPRYN DWRO_ROLE
DWRO_ROLE
SAFIS_ROLE
FULLDML
READONLY
READONLY
DW_ACL
ACE
SELECT
REALM
DATA_SOURCE IN
(‘0016’,’0022’,’0031’)
CONSOLIDATED_
REPORTS
ACCSP_DATA_SOURCE
Data Security Policy
SAFIS_ACL
ACE
SELECT
INSERT
UPDATE
DELETE
REALM
1 = 1
DW_ACL
ACE
SELECT
REALM
DATA_SOURCE IN
(‘0001’,’0002’,’0003’)
ACCSP_SUBSAMPLE
Data Security Policy
CONSOLIDATED_
LANDINGS
REALM
CHILD OF
CONSOLIDATED_
REPORTS
11. RAS Terminology
Term Definition
Principal Either an application user / role or a database user / role
Application Session A lightweight connection to the database through which only permitted data may be accessed
Application User Like a traditional database user account, but only used within an application session to connect to the database via either the
middle tier or by connecting directly to the database. Application users do not own schemas
Application Role Uses one or more ACLs – not database grants – to map privileges to application users or application roles. (Application roles can
be granted database privileges by being granting a database role)
Application Privilege A right or permission either granted or denied to a principal. Application privileges can also be aggregated so that they imply
other rights or permissions
Access Control Entry (ACE) Grants or denies access a particular set of privileges to a particular application user or role. Note that an ACE doesn’t specify
which data to protect; that only happens when the ACL is associated with specific target data, thus creating a data realm
Access Control List (ACL) A collection of ACEs that permit or deny application privileges to specific users
Security Class The scope for a set of application privileges, typically associated with an ACL. The ACL then grants application privileges within the
security class to specific principals
Data Realm A specific filter that’s applied to rows within the table – for example, limiting a user’s view of rows in TPCH.CUSTOMERS to only
those whose C_NATIONKEY column contains a value of 24 (USA)
Data Security Policy Protects database rows and columns within tables from unauthorized access. Only rows from the specified data realms for only
the columns permitted to be viewed will show data
12. TPC-H: A Perfect Schema for RAS Demonstrations
Entities and Relationships:
CUSTOMER
Purchasers of
PARTS and
SUPPLIES
NATION
Country where
Customer
resides
REGION
Global area
ORDERS
Records what
each Customer
has purchased
over time
LINEITEM
Items and
services
purchased for
each Order
PARTSUPP
Combines PART
and SUPPLY
entities
PART
Items available
for purchase
SUPPLY
Services
provided
13. Obscuring Rows and Columns For Specific Users
. . .
realms :=
XS$REALM_CONSTRAINT_LIST(
XS$REALM_CONSTRAINT_TYPE(
realm => 'C_NATIONKEY IN (SELECT RSU_NATIONKEY FROM TPCH.RAS_SECURED_USERS
WHERE RSU_USERNAME = XS_SYS_CONTEXT('XS$SESSION', 'SESSION_XS_USER'))'
,acl_list => XS$NAME_LIST('TPCH.SUPR_ACL’,TPCH.DWRO_ACL')
)
);
collims :=
XS$COLUMN_CONSTRAINT_LIST(
XS$COLUMN_CONSTRAINT_TYPE(
column_list => XS$LIST('C_MKTSEGMENT’,’C_NAME’)
,privilege => 'VIEW_RESTRICTED_PARTICIPANT_INFO'
)
);
SYS.XS_DATA_SECURITY.CREATE_POLICY(
name => ‘TPCH.CUSTOMER_DS'
,realm_constraint_list => realms
,column_constraint_list => collims
);
. . .
This establishes the realm in which
values for C_NATIONKEY should be
used to limit rows retrieved for each
specific user account …
… and this establishes the list of
columns whose data should be
hidden within that realm as well
14. Using RAS with SQL Tools, APEX, and Other Application Languages
RAS complements both SQL Tools (e.g. SQL*Plus) as well as other application
environments, especially APEX
• RAS direct-connect application user accounts – those that are granted XS$CONNECT
privileges - allow direct connections to a database instance, thus enabling (sufficiently-
trained!) “super-users” to build their own custom data extracts or reports
• APEX interfaces with RAS almost seamlessly, with some minor tweaks to existing
application security settings
• The identical RAS security privileges the user has when connecting via APEX are enforced
when connecting directly to an instance via SQL tools (e.g. SQLcl, SQLDeveloper) using a
direct-connect RAS user account … so no special handling is needed
15. RAS User Accounts: Options and Implications
RAS
User
Type
Usage
Granted
XS$CONNECT
Role?
Per-
Session
Username
Password State
Retained &
Managed Within
Connect
to APEX?
Direct
User
Connecting directly to
an Oracle database
instance through SQL
tools (e.g. SQL*Plus)
Yes
User
account
Oracle Database No
Internal
User
Connecting to
application sessions only
No
User
account
Oracle Database Yes
External
User
Connecting to
applications sessions
only
No XS$GUEST
SSO / Custom
Methods
Yes
Note: The domain of Direct and Internal user account names is distinct – they cannot overlap!
16. Choosing RAS Internal vs. External Users for APEX
This is actually a great opportunity!
• We can transition from how database accounts are managed
right now: intra-database
• We only need a few RAS Direct users for now to handle SQL Tool
access
• RAS Internal users will work best for all the rest of our logins – I
can transition everyone with a few magic DBA scripts!
Yeah. Not so fast, hot shot!
• The decision to go with “schema-d” users was made long
ago, for a good reason!
• So now super-users have two logins? Great.
• And don’t even suggest going to SSO – that’s a huge
project and means refactoring!
Solution: For our APEX application environment, the External user type actually makes a lot more sense
RAS Internal
Users seem to
make the most
sense for our
APEX accounts!
Huh?!? What
about all our
existing user
accounts?
17. How RAS and APEX Authentication Schemes Interact
[oracle@host19c ~]$ sqlplus tpch_dwro/@devdb
SQL*Plus: Release 19.0.0.0.0 - Production
on Sat Sep 3 17:06:45 2022 Version 19.11.0.0.0
Copyright (c) 1982, 2020, Oracle. All rights reserved.
Enter password: *************
SQL*Plus Session
APEX Application
APEX Authentication
RAS Security
Policies
DirectConnect RAS users
initiate database connections
as DB user accounts …
... while APEX RAS External users are
first authenticated via an APEX
authentication scheme
The authentication scheme evaluates the
user + password supplied, then simply
returns TRUE if that combination is valid
Once authenticated, the
APEX application session is
transformed into a RAS
session as user XS$GUEST
Finally, it’s crucial to remember that
while RAS enforces row & column
security, it does not handle APEX-
specific feature, page, or item security!
18. Enabling RAS External Users in APEX Via Authentication Schemes
• Series of images
RAS Mode determines whether APEX
will use INTERNAL users (i.e. resident
within Oracle SYS schema, controlled
just like typical user accounts) or
EXTERNAL users (typically, controlled via
SSO / other means)
RAS application roles can be assigned
during the initial connection to the
application, or even dynamically
within a user session
If needed, RAS can also access
customized namespaces that
store variable values in
application-specific or user
account-specific domains
19. APEX Post-Authentication Process
Why not simplify?
Just put all these
application item
computations into
a single place!
Umm …
you’ve lost
your $#@%$^
mind, dude!
DBA: Centralize and Simplify!
Move all Application Item Computations (AICs) to an
APEX post-authentication process – it’s cleaner, simpler,
and involves a single round-trip to the server. See?
DevOps: Stay in Your Lane, Bruh!
Application items and computations are an integral part
of APEX – developers need to see how these are set. This
also means refactoring our applications! And oh, BTW –
don’t even try to tell APEX developers what they can and
can’t implement within RAS!
Solution: Actually, it turns out that all data essential for RAS policies must be set in post-authentication process
• Application computations and processing can simply pick up from there
• Be sure to clearly document what gets set where and how - don’t hide the logic!
• Learn the gentle art of compromise ☺
20. POST_AUTH Procedure: Replacing AICs & Enabling RAS Dynamic Roles
CREATE OR REPLACE PROCEDURE post_auth (p_username IN VARCHAR2)
IS
v_contact_id ACCSPADMIN.MM_CONTACTS.CONTACT_ID%TYPE;
v_Is_Admin CHAR(01);
v_access_ids VARCHAR2(4000);
v_access_ids_char VARCHAR2(4000);
v_safis_access_ids VARCHAR2(4000);
v_safis_access_ids_char VARCHAR2(4000);
v_partner_id ACCSPADMIN.ACCSP_PARTNERS_CONTACT.PARTNER_ID%TYPE;
v_partner_name ACCSPREC.PARTNERS.PARTNER_NAME%TYPE;
v_partner_abbrev ACCSPREC.PARTNERS.PARTNER_ABBREV%TYPE;
BEGIN
-- Determine + assign Contact ID
v_contact_id := ACCSPREC.DW_AUTH.GET_CONTACT_ID(UPPER(p_username));
APEX_UTIL.SET_SESSION_STATE('G_CONTACT_ID', v_contact_id);
. . .
Just as in our APEX
application, the supplied
username drives both
authorization and
determination of
appropriate privileges
within the app itself
21. POST_AUTH Procedure: Replacing AICs & Enabling RAS Dynamic Roles
CREATE OR REPLACE PROCEDURE post_auth (p_username IN VARCHAR2)
IS
v_contact_id ACCSPADMIN.MM_CONTACTS.CONTACT_ID%TYPE;
v_Is_Admin CHAR(01);
v_access_ids VARCHAR2(4000);
v_access_ids_char VARCHAR2(4000);
v_safis_access_ids VARCHAR2(4000);
v_safis_access_ids_char VARCHAR2(4000);
v_partner_id ACCSPADMIN.ACCSP_PARTNERS_CONTACT.PARTNER_ID%TYPE;
v_partner_name ACCSPREC.PARTNERS.PARTNER_NAME%TYPE;
v_partner_abbrev ACCSPREC.PARTNERS.PARTNER_ABBREV%TYPE;
BEGIN
-- Determine + assign Contact ID
v_contact_id := ACCSPREC.DW_AUTH.GET_CONTACT_ID(UPPER(p_username));
APEX_UTIL.SET_SESSION_STATE('G_CONTACT_ID', v_contact_id);
. . .
Just as in our APEX
application, the supplied
username drives both
authorization and
determination of
appropriate privileges
within the app itself
. . .
-- Determine + assign ADMIN privileges
v_Is_Admin:= ACCSPREC.DW_AUTH.IS_DW_ADMIN(UPPER(p_username));
APEX_UTIL.SET_SESSION_STATE('G_IS_ADMIN', v_Is_Admin);
-- Determine + assign PartnerID, Partner Name, and Partner Abbreviation
v_partner_id := ACCSPREC.DW_AUTH.GET_PARTNER_ID(v_contact_id);
APEX_UTIL.SET_SESSION_STATE('G_PARTNER_ID', v_partner_id);
v_partner_name := ACCSPREC.DW_AUTH.GET_PARTNER_NAME(v_partner_id);
APEX_UTIL.SET_SESSION_STATE('G_PARTNER_NAME', v_partner_name);
v_partner_abbrev := ACCSPREC.DW_AUTH.GET_PARTNER_ABBREV(v_partner_id);
APEX_UTIL.SET_SESSION_STATE('G_PARTNER_ABBREV', v_partner_abbrev);
. . .
-- Activate RAS dynamic role if Participant confidential information
-- is viewable for the user
IF ACCSPREC.DW_AUTH.DETAIL_PPT(UPPER(p_username)) THEN
APEX_AUTHORIZATION.ENABLE_DYNAMIC_GROUPS (
p_group_names => APEX_T_VARCHAR2('RAS_DW_VIEW_PARTINFO_ROLE')
);
END IF;
END;
These replace all
Application Item
Computations
originally coded within
the application
If the user is allowed to
view data in secured
columns, this enables
the appropriate RAS
role dynamically
22. Managing RAS Sessions in APEX: Wait, What Now?
Everything
looks great
from my
side! Just let
me log out …
Wow, It’s Actually Working!
My application testing looks good; RAS constraints are being
applied properly depending on each user’s permitted
realms. Nicely done!
Really? Well,
your $#@%^
app is leaving
sessions
connected to
my database!!
Then Why Are All These RAS Sessions Still Connected?
• RAS sessions were not terminating after a “normal” logout
• After some research and conversations with RAS and APEX
developers at Oracle, we found out that a RAS session
apparently does not “kill” itself in the same manner as a
normal APEX session
Solution: Terminate RAS sessions on logout by invoking a post-logout procedure
23. INVALID_SESSION: Cleaning Up RAS Sessions After Logout
A simple call to the
DELETE_SESSION
procedure of the
APEX_SESSION
package terminates
a RAS session cleanly
These Custom authorization
scheme settings offer precise
control of session
invalidation, authentication,
and post-logout processing
for RAS External Users
24. RAS: Recommendations for Seamless Implementation
• The ease of implementing RAS security policies is directly proportional to time spent on building
consistent data models in the past. Some examples:
• Key realm discriminator column is not consistently named or applied across every table, MV, and view
• We implemented separate DSPs for any special cases … which is much smarter than renaming columns for consistency’s sake
• PII columns that need to be hidden were named inconsistently across several views and MVs
• We implemented four (4) different DSPs for about a dozen database objects – ideally, we’d have liked to implement just one
• RAS-specific tracing is invaluable when a security policy seems to be failing:
SQL>
BEGIN
DBMS_SESSION.SET_IDENTIFIER('ACCSP_DEBUG');
DBMS_APPLICATION_INFO.SET_MODULE('ACCSPD', NULL);
END;
/
ALTER SESSION SET EVENTS 'TRACE [XSSECCLASS] disk=high';
ALTER SESSION SET EVENTS 'TRACE [XSXDS] disk=high';
ALTER SESSION SET EVENTS 'TRACE [XSVPD] disk=high';
ALTER SESSION SET EVENTS 'TRACE [XSACL] disk=high';
ALTER SESSION SET EVENTS 'TRACE [XSSESSION] disk=high';
ALTER SESSION SET EVENTS 'TRACE [XSPRINCIPAL] disk=high';
These two trace directives look
closely at all events related to
applying data security policies
25. RAS and APEX: Key Concepts to Remember
Work with
your DBA, plan
ahead … and
think!
Exactly! And don’t
forget to listen to
your DevOps
teammates!
Put simply: Application security is now subdivided!
✓RAS controls which data (rows and columns) the user can
view & access
✓APEX roles control what app features the user can utilize
RAS Security Policies must cover all combinations
and possibilities across all potential users, so this
means you’ll need to invest significant time into
planning and brainstorming
Your APEX app no longer needs to enforce row and column security!
✓Be sure to document & reference all RAS Security Policies within the application
✓Developers don’t have to implement the policies, but they need to understand them
26. RAS and APEX: RTFM, and Go Slow To Go Fast
... but
implementing
RAS in APEX can
be confusing!
Sure, RAS
appears to be
simple and
elegant …
• RTFM!!! Be sure you understand all RAS concepts
• Decide on where you’re keeping your user account
information, depending on RAS user type(s) selected
• Start small! Build a simplified APEX app to prove out key
RAS policies are being applied implemented as expected
• Build a simple APEX page to prove policies are working,
and be sure to include a real-time display of whatever RAS
dynamic application role privileges are in effect for RAS
External users
Note: The RAS examples in the documentation are extremely simple. Our actual use
cases were much more complex – e.g., multiple schemas, MVs, and a “mature”
application base – so we encountered some frustratingly undocumented aspects of RAS
27. Real-Time Display of RAS Session Info & Applied Restrictions (1)
Here’s a list of the applied
discriminator values that
restrict row realms and
column display, as well as any
RAS Roles currently in force …
… and here’s the result of the
POST_AUTH procedure’s population
of variables that used to be
Application Item Computations
28. Real-Time Display of RAS Session Info & Applied Restrictions (1)
Here’s a list of the applied
discriminator values that
restrict row realms and
column display, as well as any
RAS Roles currently in force …
… and here’s the result of the
POST_AUTH procedure’s population
of variables that used to be
Application Item Computations
And since this user is permitted to view
sensitive data, they appear in unrestricted
format (blurred here for purposes of privacy)
29. Real-Time Display of RAS Session Info & Applied Restrictions (2)
Likewise, this user’s
discriminator values reveal
they can see a different set of
row realms, but note there is
no dynamic role granted to
view sensitive data
30. Real-Time Display of RAS Session Info & Applied Restrictions (2)
Likewise, this user’s
discriminator values reveal
they can see a different set of
row realms, but note there is
no dynamic role granted to
view sensitive data
Since this user is not permitted to
view sensitive data, they appear
in restricted format …
… but they can still view unrestricted data based on
the row domain they’re permitted to view
31. RAS and APEX: When RTFM Fails
Not everything
is documented
in the #$%^&
manual!
We had one big
advantage: Oracle
PMs actually
listened to us.
Eventually :)
Here’s what wasn’t intuitively obvious from the documentation!
• How different RAS user account types actually connect to the DB
• Whether to implement RAS External or Internal users
• When to build and use RAS dynamic roles
• Whether RAS namespaces were required for APEX implementation
• Building RAS realm and column constraints for complex
scenarios – e.g., involving restricting data to be viewed
based on more than one discriminator value – is simply not
documented anywhere
• Columnar security policies applied via RAS application roles
permit access to data, not restrict it from access!
There are a dizzying array of RAS options, so be sure to choose wisely
to avoid unnecessary refactoring of your applications!
32. Useful Resources and Documentation
Oracle Real Application Security & Virtual Private Database Home Page:
https://www.oracle.com/database/technologies/security/virtual-private-db.html
Oracle 19c Real Application Security User Guide:
https://docs.oracle.com/en/database/oracle/oracle-database/19/dbfsg/index.html
Oracle 19c Real Application Security Administration (RASADM) User Guide:
https://docs.oracle.com/en/database/oracle/oracle-database/19/rasad/index.html#RASAD142