Changes in This Release for Oracle Database Real Application Security Administrator's and Developer's Guide

The following features are new in this release:

• Real Application Security includes support for privilege scoping

  Oracle Database 12c Release 2 (12.2) extends the Real Application Security model by allowing per principal session privilege grants, through an ACL set on the principal as a native Real Application Security application user, for granting session management privileges. In addition, Oracle Database 12c Release 2 (12.2) extends the Real Application Security model by allowing per principal session privilege grants, though an ACL set on the principal as a dynamic role, for granting only the SET_DYNAMIC_ROLES privilege. Principal-specific ACL grants take precedence over system-level session privilege grants. It allows for a negative grant to be set on the principal specific ACL. Use of an ACL allows a common set of grants to be enforced on a group of native application users and dynamic roles.

  This feature provides the following new API:

  • SET_ACL Procedure— Sets an ACL on the specified application user or dynamic role.

  This feature enhances the following APIs with the addition of the acl parameter:

  • CREATE_USER Procedure

  • CREATE_DYNAMIC_ROLE Procedure

  This feature enhances the following views by displaying the ACLs that are set on the user and or dynamic role or both:

  • DBA_XS_USERS

  • DBA_XS_DYNAMIC_ROLES

  This feature adds the SET_DYNAMIC_ROLES privilege, which is defined in the SESSION_SC security class to protect enablement and disablement of a dynamic role as part of the attach session and assign user operations.

  See SET_ACL Procedure, CREATE_USER Procedure, CREATE_DYNAMIC_ROLE Procedure, DBA_XS_USERS, DBA_XS_DYNAMIC_ROLES, and the SESSION_SC security class in Security Classes for more information.

  See About Real Application Security Session Privilege Scoping Through ACL for more information.

• Real Application Security supports column-level access control on DML statements. This allows users to insert, update, and delete specific column values based on their granted column-level privileges.

  Beginning with Oracle Database 12c Release 2 (12.2), users with required privileges can do DMLs with Data Security column security. This means:

  • To update a row value, an authorized user needs both the row-level UPDATE privilege as well as the column privilege on the protected columns to be updated.

  • To insert a row, an authorized user needs both the row-level INSERT privilege as well as the column privilege on each protected column. If the INSERT statement does not insert a value for a protected column, the column privilege is not required, and the default value (or NULL if there is no default value) is inserted.

  • To delete a row, an authorized user only needs the row-level DELETE privilege. The column privilege is not required.

  • No data is disclosed for DMLs with Data Security row-level and column-level security. DML statements with RETURNING INTO or with the parameter - sql92_security enabled require both the row-level SELECT privilege as well as the column privileges if the columns appear in the RETURNING INTO clause.

• Real Application Security includes support for schema-level security policy administration

  This feature enhances the following APIs:

  • GRANT_SYSTEM_PRIVILEGE Procedure by adding the schema parameter

  • REVOKE_SYSTEM_PRIVILEGE Procedure by adding the schema parameter

  This feature extends the ADMIN_SEC_POLICY privilege to schemas for policy management.

  See XS_ACL Package, XS_DATA_SECURITY Package, and XS_SECURITY_CLASS Package for more information.

  This feature adds the APPLY_SEC_POLICY privilege for policy enforcement within granted schemas to achieve policy enforcement within an application.

  The APPLY_SEC_POLICY privilege will be checked in the following APIs before enforcing policies: APPLY_OBJECT_POLICY Procedure, REMOVE_OBJECT_POLICY Procedure, ENABLE_OBJECT_POLICY Procedure, and DISABLE_OBJECT_POLICY Procedure.

  This feature adds two audit actions:

  • AUDIT_GRANT_PRIVILEGE

    — to audit the GRANT_SYSTEM_PRIVILEGE API

  • AUDIT_REVOKE_PRIVILEGE

    — to audit the REVOKE_SYSTEM_PRIVILEGE API

  This feature adds the following views: ALL_XS_SECURITY_CLASSES, ALL_XS_SECURITY_CLASS_DEP, ALL_XS_PRIVILEGES, ALL_XS_IMPLIED_PRIVILEGES, ALL_XS_ACLS, ALL_XS_ACES, ALL_XS_POLICIES, ALL_XS_REALM_CONSTRAINTS, ALL_XS_INHERITED_REALMS, ALL_XS_ACL_PARAMETERS, ALL_XS_COLUMN_CONSTRAINTS, ALL_XS_APPLIED_POLICIES, and DBA_XS_PRIVILEGE_GRANTS.

  See About Schema Level Real Application Security Policy Administration for more information.

• Oracle Label Security support for the Oracle Database Real Application Security

  For the user_name parameter in the SA_USER_ADMIN.SET_USER_LABELS procedure and in the SA_USER_ADMIN.SET_USER_PRIVS procedure for Oracle Database, the user name can be an Oracle Database Real Application Security user name.

  See the SA_USER_ADMIN.SET_USER_LABELS procedure in Oracle Label Security Administrator’s Guide and the SA_USER_ADMIN.SET_USER_PRIVS procedure in Oracle Label Security Administrator’s Guide for more information.

  Labels or Oracle Label Security privileges assigned to the Real Application Security user are enforced in the Real Application Security user session. Oracle Label Security context is established upon the following Real Application Security session operations (ATTACH_SESSION, SWITCH_USER, ASSIGN_USER) and in Real Application Security direct logon sessions. Based on labels or privileges or both that the current Real Application Security session has, the Oracle Label Security policy is enforced.

  See Attaching an Application Session to a Traditional Database Session, Assigning an Application User to an Anonymous Application Session, Switching a Current Application User to Another Application User in the Current Application Session, and Oracle Label Security Context Is Established in Direct Logon Session for more information.

• Predefined application role XSCONNECT

  Allows the user granted this role to connect to the database. In other words, a user not granted this predefined role cannot connect to the database.

  See Regular Application Roles, GRANT_ROLES Procedure, and About Creating a Direct Login Application User Account for more information.

The following features are deprecated and will not be supported in future releases:

• For the CREATE_USER procedure

  The PASSWORDEXPIRED and LOCKED values for the parameter STATUS are deprecated.

  See "CREATE_USER Procedure" for more information.

• For the SET_USER_STATUS procedure

  The PASSWORDEXPIRED status value is deprecated.

  See "SET_USER_STATUS Procedure" for more information.

• For the SET_PASSWORD procedure

  The password types XS_MD4 and XS_O3LOGON are deprecated.

  See "SET_PASSWORD Procedure" for more information.

• For the SET_VERIFIER procedure

  The verifier types XS_SALTED_MD5, XS_SHA1, XS_SASL_MD5, XS_MD5, XS_MD4, and XS_O3LOGON are deprecated.

  See "SET_VERIFIER Procedure" for more information.