Entra ID RAS Integration

Real Application Security (RAS) provides fine grain access controls within the Oracle database for application users.  This capability can be extended to centralized database architectures such as Centrally Managed Users (CMU) and Entra ID integration.  Thomas Minne recently wrote up an excellent article titled "Unifying Identity and Data Security: Real Application Security with Active Directory" that illustrates how to configure RAS access controls of CMU roles by way of specifying the CMU database group with principal_name and the RAS xs_acl.ptype_db principal_type.

With CMU, database roles can be mapped as identified globally to Active Directory (AD) groups using the group's distinguished name (DN) in AD.  In the following example, we map the database roles idp_dba and to dbsession to AD groups  "cn=idp_dba,cn=Groups,dc=myco,dc=com" and "cn=dbsession,cn=Groups,dc=myco,dc=com" respectively:

DB Role For DBAs:
SQL> CREATE ROLE idp_dba IDENTIFIED GLOBALLY AS 'cn=idp_dba,cn=Groups,dc=myco,dc=com';
SQL> GRANT pdb_dba TO idp_dba;
DB Role For Users:
SQL> CREATE ROLE dbsession IDENTIFIED GLOBALLY AS 'cn=dbsession,cn=Groups,dc=myco,dc=com';
SQL> GRANT CREATE SESSION TO dbsession;

With Entra ID integration, the database roles are mapped to Entra ID app roles that are linked within Entra ID to Entra ID groups.  In the following example, we map the database roles idp_dba and dbsession to Entra ID app roles dba.role and session.role respectively:

DB Role For DBAs:
SQL> CREATE ROLE idp_dba IDENTIFIED GLOBALLY AS 'AZURE_ROLE=dba.role';
SQL> GRANT pdb_dba TO idp_dba;
DB Role For Users:
SQL> CREATE ROLE dbsession IDENTIFIED GLOBALLY AS 'AZURE_ROLE=session.role';
SQL> GRANT CREATE SESSION TO dbsession;

In both cases, the RAS access policy declarations can be applied to the CMU or Entra ID database role names.  For example, the dbsession can be granted minimal RAS select privilege and the idp_dba role can be granted maximum select privilege.  Here are examples borrowing from Thomas Minne's blog post:

    aces(1) := xs$ace_type(privilege_list => xs$name_list
                            ('select'),
                             principal_name => 'dbsession',
                             principal_type => xs_acl.ptype_db);
    aces(2) := xs$ace_type(privilege_list => xs$name_list
                            ('select','view_employee_details'),
                             principal_name => 'idp_dba',
                             principal_type => xs_acl.ptype_db);

A user that is a member of the dbsession group would only be able to return the limited results governed by the RAS rules for that access control. And a user that is a member of the idp_dba group would be able to see all the data within the contraints of rules of the RAS access controls for the idp_daba role.

I hope you find this educational and informative.

Blessings!