5.5 Managing the Policy and Session Database

Oracle Access Management requires a database to store Access Manager policy data, password management data, and Access Manager sessions in a production environment. At most, your deployment can have one policy store database (which serves password management) and one session store. By default, a single JDBC data source is used for both.

This section includes the following topics:

5.5.1 About the Database Store for Policy, Password Management, and Sessions

In a production environment, the Oracle database stores policy data, password management data, and sessions of the Access Manager.

The policy store database, by default, stores the following data:

  • Policy data, including authentication modules and schemes, Application Domains, and policies.

  • Password Management data, which includes password policy type for each configured User Identity store as well as the policy that governs password requirements, expiry, notification,

  • Sessions, as a persistent backup to distributed in-memory storage

Note:

The preferred mode for audit data storage in production environments is writing audit records to a stand-alone RDBMS database for audit data only. This is done using a separately configured audit store. The policy store is not used for audit data.

5.5.2 About Database Deployment

Oracle requires a single database as the policy store in production environments. This single database can also be used to store session data.

Using the database as the session store provides greater scalability and fault-tolerance (against a power event taking all servers down).

Note:

You can have up to two databases: one policy database and one session database. Access Manager is agnostic with respect to the actual back end repository and does not manage this policy store configuration directly.

The policy database must be installed according to vendor instructions. The policy database is configured for use in a Oracle WebLogic Server domain using Oracle Fusion Middleware Configuration Wizard and policy store Database configuration template.

During initial deployment with the WebLogic Configuration Wizard, the following database details are requested:

  • Database login ID and password

  • Database Service name and location

An Administrator must extend the database with the Access Manager-specific schema using RCU, as described in Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management. Basic schema creation occurs when the RCU is invoked. The RCU prepares the database to accept Access Manager policy, password management, and session data.

Using the WebLogic Configuration Wizard you can register and test the connection to the database.

Actual Access Manager policy elements are created the first time the WebLogic AdminServer is started with the Oracle Access Management Console deployed.

5.5.3 Configuring a Separate Database for Access Manager Sessions

Access Manager includes a data source named oamDS which is configured against the database instance extended with the Access Manager Schema.

The following pre-defined Java Naming and Directory Interface (JNDI) names are used by the OAM Server to refer the data source.

jdbc/oamds (used by both the policy layer and session layer to access database)

You can use the following procedure to create a separate database instance for session data using the WebLogic Administration Console. There is no support for this action in the Oracle Access Management Console.

Note:

In this rare instance, Oracle recommends that you carefully edit oam-config.xml as described in Step 2f.

  1. Install and configure the database for session data and then use RCU with the Access Manager-specific schema to set up the database as a session data store.

  2. Create a new Data Source instance for session data:

    1. From the WebLogic Administration Console, Domain Structure panel, expand the domain name, Services node.

    2. Expand JDBC, Data Source.

    3. Create a new Data Source with the JNDI name jdbc/oamsession.

    4. Save the changes.

    5. Stop the OAM Servers and the AdminServer to avoid potential loss of data during the next step.

    6. In oam-config.xml, edit the value of the DataSourceName attribute to the one configured in step 1. For example:

      domain-home/config/fmwconfig/oam-config.xml
      

      From:

      <Setting Name="SmeDb" Type="htf:map">
        <Setting Name="URL" Type="xsd:string">jdbc:oracle:thin://amdb.example.
          com:2001/AM</Setting>
        <Setting Name="Principal" Type="xsd:string">amuser</Setting>
        <Setting Name="Password" Type="xsd:string">password</Setting>
        <Setting Name="DataSourceName" Type="xsd:string">jdbc/oamds</Setting>
      </Setting>
      

      To:

      <Setting Name="SmeDb" Type="htf:map">
        <Setting Name="URL" Type="xsd:string">jdbc:oracle:thin://amdb.example.
          com:2001/AM</Setting>
        <Setting Name="Principal" Type="xsd:string">amuser</Setting>
        <Setting Name="Password" Type="xsd:string">password</Setting>
        <Setting Name="DataSourceName" Type="xsd:string">jdbc/oamsession</Setting>
      </Setting>
      
  3. Restart AdminServer and OAM Servers.