Best Practices from Oracle Development's A‑Team

Oracle Database Vault security policies for Oracle WebCenter Content

The Oracle Database is the content repository of choice for many customers. Oracle Database Vault prevents data breaches from WebCenter Content Administrator Accounts and applications that may connect to WebCenter Content.

Oracle WebCenter Content, an Oracle Fusion Middleware component, is an integrated suite of applications designed for managing content. Oracle WebCenter Content contains the Oracle WebCenter Content Server, which is used to manage the content repository. The content repository is used to store content and deliver it to users as needed in the correct format.

Oracle Database Vault provides privileged user controls, command controls, and privilege analysis, helping prevent data breaches resulting from threats, external or internal, that target applications and privileged user accounts.

These  Database Vault security policies for WebCenter Content are available in the Oracle Support website via Master Note for Oracle Database Vault security policies with Siebel, PeopleSoft, JD Edwards EnterpriseOne and WebCenter Content (Doc ID 1623425.1). This Note contains an attachment that could be downloaded to access the Database Vault security policies for WebCenter Content (179.32 KB).

Before getting started:

  1. Make sure WebCenter Content is installed on Oracle Database release or higher.
  2. Make sure the database has “TEMP” as a temporary Tablespace.
  3. Installation steps:

    1. 1. Unzip the file wcc_dbvault_sec_policies.zip into a temporary directory.
    2. 2. Using Sqlplus, login to the database with the Database Vault Owner account and run the script wcc_create_dbv_policies.sql. This script is located under the create_policies directory.

     In order to temporarily disable the protection policies, run the ‘wcc_disable_dbv_policies.sql’ script. It is in the ‘disable_policies’ subdirectory. Note: Disabled Database Vault policies expose your application data to access by privileged user accounts.
    To re-enable the security policies, go to the subdirectory ‘enable_policies’ and run the ‘wcc_enable_dbv_policies.sql’ script.
    To delete the security policies, go to the directory ‘delete_policies’ and run the ‘wcc_delete_dbv_policies.sql’ script.


    The following security policies are installed:

WebCenter Content Realm: This realm protects all WebCenter Content business data owned by the _IPM, _MDS, _OCS, _OCSSEARCH, _OIM, _OPSS, _ORAIRM, _ORASDPM, _SOAINFRA, _URMSERVER schemas (note that the <PREFIX> chosen at installation/configuration time needs to be added to the schema names) against unauthorized access by privileged users, like DBAs. Access rights to business data by authorized application users remains unchanged. You may need to adjust the script files to reflect your instance users.

Connect Command Rule: This command allows connection to the database by various users according to specific security policies.

  • Database users are allowed to connect to the database using pre-defined list of processes. These processes include middle tier processes, and any client tools.
  • These include rules that specify which IP addresses and/or hostnames these processes should connect from. You may want to enter here the IP and hostname for all the middle tiers in the WebCenter Content cluster.

Use Cases

Our main goal is to validate that customers can ensure a DBA and other privileged users (system administrators) cannot view application data but can still perform necessary DBA and system administration functions such as application rollout and system maintenance.When it comes to backend privileged user access, Oracle Database Vault can be used to help fulfill various compliance related requirements such as the following:

Database Vault (DBV) can help mitigate the risks of the following regulations at the data tier level

Regulatory Legislation

Regulation Requirement

Does DBV Mitigate This Risk?

Sarbanes-Oxley Section 302

Unauthorized changes to data


Sarbanes-Oxley Section 404

Modification to data, Unauthorized access


Sarbanes-Oxley Section 409

Denial of service, Unauthorized access



Unauthorized access, modification and/or disclosure


HIPAA 164.306

Unauthorized access to data




HIPAA 164.312

Unauthorized access to data


Basel II – Internal Risk Management

Unauthorized access to data



Restrict Access to cardholder data by business need-to-know


CFR Part 11

Unauthorized access to data


Japan Privacy Law

Unauthorized access to data


Several of the anticipated customer use cases for Database Vault include:

  • Limiting the system DBA’s access to WebCenter Content application data.
  • Providing the application DBA proper access to the usual database objects such as tables, views, and indexes, for maintenance and deployment, without giving the ability to see any application business data.
  • Ensuring the above policies are followed in a production environment as well as during any application maintenance or patching.

The scripts delivered have been developed to accomplish the above security policies.  If your policies differ from the above, the scripts can be modified to support your specific security needs.


The Rule Set ‘WebCenter Content Access’ is configured to be static, which means that changes to the underlying Rules are not effective until the user(s) log out and back in. But static Rule Sets minimize the performance impact, especially in Rule Sets with many complex Rules.

Clustered environments


Find below the modifications to 01_wcc_create_rule.sql in order to handle clustered WebCenter Content environments:

-- create Rule 'Check WebCenter Content IP 3'

rule_name => 'Check WebCenter Content IP 3',
rule_expr => 'SYS_CONTEXT(''USERENV'',''IP_ADDRESS'') = ''111.222.333.444'' OR
SYS_CONTEXT(''USERENV'',''IP_ADDRESS'') = ''111.222.333.555'' OR
SYS_CONTEXT(''USERENV'',''IP_ADDRESS'') = ''111.222.333.666'' OR
SYS_CONTEXT(''USERENV'',''IP_ADDRESS'') = ''111.222.333.777'''


-- create Rule 'Check WebCenter Content Hostname 4'
rule_name => 'Check WebCenter Content Hostname 4',
rule_expr => 'SYS_CONTEXT(''USERENV'',''HOST'') = ''myhost.us.oracle.com'' OR
SYS_CONTEXT(''USERENV'',''HOST'') = ''myhost2.us.oracle.com'' OR
SYS_CONTEXT(''USERENV'',''HOST'') = ''myhost3.us.oracle.com'' OR
SYS_CONTEXT(''USERENV'',''HOST'') = ''myhost4.us.oracle.com'''


Hostname vs. IP addresses

The initial set of rules provided in this kit are provided as a sample to aid system administrators in the creation of rules that would meet their end user’s business requirements. Either the IP check rule or the Hostname check rule could be removed if not needed.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content