Integrating SailPoint with Oracle Database

The SailPoint Oracle Database integration is capable of end-to-end user administration with provisioning and password management capabilities of Oracle database, helping provide rich governance and control experience to the enterprise.

If you have user accounts in Oracle Database that you want to load into SailPoint, you can create a direct connect source for Oracle Database and load that data into your system. To manage that data, either create an identity profile based on the source or verify that the accounts you load are correlated to an existing identity.

Supported Features

The Oracle Database connector supports the following features:

• Authentication
• Accounts
• *Password Management
• *Provisioning
• *Access Certifications (certification of entitlements connected to accounts)

For more information on features, refer to Source Features.

In account - entitlement management, the Oracle Database connector supports the management of Oracle entitlements as system privileges.

• Management of Oracle groups as ROLE
• Aggregation and Refresh entitlement
• Create, Update, and Delete

The Oracle Database source supports:

• Permissions directly assigned to accounts and groups as direct permissions during account and entitlement aggregation.
• Revocation of the aggregated permissions for an account through certification.

The details of the features are:

Accounts

Group Entitlements

Group Entitlements are the entitlement types for which SailPoint provides the ability to aggregate additional details of these entitlement types from the managed system. These objects have separate schema defining the list of attributes that the aggregation task fetches as additional details when aggregation is run for that Group Entitlement type.

The group hierarchy for the Roles attribute is supported.

To enable direct permissions and their aggregation for the account or the group schema of your Oracle Database source, perform the following steps.

1. Use listSources API to get the source ID for your source.
2. Use listSchemas API to get the schema ID for the account or group schema for which you want to enable direct permissions.

3. Use updateSchema API and enter the following content in the body.

   {
       "op": "replace",
       "path": "/includePermissions",
       "value": true
   }
   

Privilege Classification

SailPoint Privilege Classification helps organizations systematically categorize and manage the privilege levels of entitlements within their sources. By classifying entitlements as high, medium, or low, administrators can better understand the potential risk and impact associated with specific access rights. This allows automatic assignment of privilege levels based on system recommendations, custom-defined criteria, or a same level across all entitlements.

For more information, refer to Managing Privilege Classification.

Password Management

If Password Management is enabled for your organization, you can change the password for a user of the source. After enabling password management on the source, be aware of the following:

• The password policy defined in SailPoint applies to accounts on this source.
• If you change the password for an application connected to this source, the change will automatically be made to the source itself.

For more information on configuring password management, refer to Password Management Overview.

Supported Managed Systems

The SailPoint Oracle connector supports the following versions of the Oracle Server:

• Oracle Database 23ai
• Oracle Database 21c
• Oracle Database 19c
• Oracle Database 18c
• Oracle Database 12cR2
• Oracle Database 12c

The SailPoint Oracle connector supports managing Oracle Databases hosted on Amazon Web Services Relational Database Service (AWS RDS). For more information on AWS RDS, refer to Amazon Web Services Relational Database Service (AWS RDS).

Amazon Web Services Relational Database Service (AWS RDS)

AWS RDS Oracle is a managed service provided by Amazon that has certain restrictions on what an administrative account can perform on the Oracle Database instance on AWS RDS. As a result of these restrictions, the SailPoint Oracle connector supports Oracle on AWS RDS with the following limitations:

• Application configuration attributes are the same.
• By default, the Oracle Database connector aggregates all the roles, system privileges, and profiles as entitlements where profiles are not requestable. Among the aggregated roles/system privileges, the master user does not have all the permissions for provisioning on an AWS RDS instance.

• For creation of the service account, the following permissions (in reference to the permissions mentioned in Required Permissions) cannot be assigned to the service account by the master user:

  • GRANT GRANT ANY ROLE TO ${UserName};
  • GRANT GRANT ANY PRIVILEGE TO ${UserName};
  • GRANT SELECT ON dba_col_privs TO ${UserName};
  • GRANT SELECT ON V_$version TO ${UserName};
  • GRANT SELECT on V_$PWFILE_USERS to ${UserName};

• In order to enable the service account to grant the role (which is allowed on RDS) to a user, the following permission must be given to the service account through the master user:

  GRANT <RoleName> TO ${UserName} WITH ADMIN OPTION
  

  For assigning the service user permissions, use the SQL script located at this location: https://community.sailpoint.com/docs/DOC-11323

  This script grants all the permissions available with the master user WITH ADMIN OPTION=YES to the service user.

• In cases where you use custom roles created by the master user or any other user which is equivalent to the master, the owner of the role must assign the role to the service user using the WITH ADMIN OPTION.

• For the table/system privileges, the revoke option is available with the user who has granted them.

Prerequisites

• Configure at least one virtual appliance cluster and successfully test the connection. For instructions, refer to the Virtual Appliance Reference Guide.
• Identify or create a service account on the Oracle Database system.
• Obtain the custom Oracle jar file ojdbc8.jar from Oracle Database 12.2.0.1 JDBC Driver & UCP Downloads.
• For mTLS authentication, complete the requirements in Prerequisites for mTLS Authentication.

Prerequisites for mTLS Authentication

Your Oracle DBA must complete the following on the Oracle Database server before you configure the connector:

• Configure the Oracle listener to accept TCPS connections, typically on port 2484.
• Enable client certificate authentication (SSL_CLIENT_AUTHENTICATION = TRUE in sqlnet.ora).

• Create a minimum permission user as below:

  CREATE USER "username" IDENTIFIED EXTERNALLY;
  

  Example:

  CREATE USER MTLSUSER
    IDENTIFIED EXTERNALLY AS 'CN=jmtlsclient,OU=SailPoint,O=Lab,C=US';
  

• Grant the required permissions to the database user. Refer to Required Permissions for more information.

/home/sailpoint/certificate/

/home/sailpoint/certificate/keystore/

Responsibility for File Preparation

Prerequisites for Kerberos Authentication

Your Active Directory administrator and Oracle DBA must complete the following before you configure the connector:

Active Directory Configuration:

• Create a client principal (AD user account) for the connector to authenticate as (for example, ora_kerb@EXAMPLE.COM). Enable AES256 encryption on this account (msDS-SupportedEncryptionTypes must include AES256).
• Create a service account (AD user account) with an SPN registered for the Oracle service in the format oracle/<oracle-server-fqdn> (for example, oracle/oracle-server.example.com).
• Generate a client keytab for the client principal using ktpass with AES256-SHA1 encryption.
• Generate a service keytab for the Oracle SPN using ktpass and place it on the Oracle server.

Oracle Database Server Configuration:

• Configure Kerberos authentication in sqlnet.ora with the following parameters:

  • SQLNET.AUTHENTICATION_SERVICES = (KERBEROS5)
  • SQLNET.AUTHENTICATION_KERBEROS5_SERVICE - set to the Kerberos service name (for example, oracle)
  • SQLNET.KERBEROS5_CONF - path to the krb5.ini file on the Oracle server
  • SQLNET.KERBEROS5_KEYTAB - path to the service keytab on the Oracle server
  • SQLNET.KERBEROS5_CONF_MIT = TRUE
  • SQLNET.KERBEROS5_CLOCKSKEW - clock skew tolerance in seconds (for example, 300)

• Create a krb5.ini (or krb5.config) on the Oracle server with the realm, KDC address, and encryption type information matching the Active Directory configuration.

• Restart the Oracle listener and database services after making these changes.

• Create an Oracle database user identified externally. The username must match the Kerberos client principal exactly (case-sensitive, including the realm):

  CREATE USER "ORA_KERB@EXAMPLE.COM" IDENTIFIED EXTERNALLY;
  

• Grant the database user CREATE SESSION and the required permissions. Refer to Required Permissions for more information.

Kerberos Configuration Files on the VA

The following files must be placed on the VA before configuring the source. Place all files in a single directory, for example /home/sailpoint/oracle-kerberos/.

Required Permissions

The service account (user) on the target systems must have permissions for the operations it carries out.

Additional Permissions

Update the service account for the Oracle Database source with the following permissions:

GRANT SELECT ON DBA_TABLESPACES TO ${UserName};

GRANT SELECT ON DBA_PROFILES TO ${UserName};

The Oracle administrator must have all the permissions mentioned below for performing the provisioning operations.

Sign in with administrator credentials and execute the following command to create a new user:

CREATE USER ${UserName} IDENTIFIED BY ${Password};

The following table lists the required permissions for the specific operations mentioned below in this section:

Test Connection

SELECT Permission

GRANT create session TO ${UserName};

For the CDB service account, the above permission must be in the following format:

GRANT CREATE SESSION to <C##username> container=CURRENT;

Account Aggregation

SELECT Permission

GRANT SELECT ON dba_users TO ${UserName}; (By this command discovering schema is possible)
GRANT SELECT ON dba_sys_privs TO ${UserName};
GRANT SELECT ON dba_role_privs TO ${UserName};

For the CDB service account, the above permissions must be in the following format:

GRANT SELECT ON dba_users TO <C##username> container=CURRENT;

Group Aggregation

SELECT Permission

• GRANT SELECT ON dba_roles TO ${UserName}; (By this command discovering schema is possible)
• GRANT SELECT ON dba_tab_privs TO ${UserName};
• GRANT SELECT ON dba_col_privs TO ${UserName};
• GRANT SELECT ON dba_sys_privs TO ${UserName};
• GRANT SELECT ON system_privilege_map TO ${UserName};
• GRANT SELECT ON V_$version TO ${UserName};
• GRANT SELECT on V_$PWFILE_USERS to ${UserName};
• GRANT SELECT ON dba_role_privs TO ${UserName};

For the CDB service account, the above permissions must be in the following format:

GRANT SELECT ON dba_roles TO <C##username> container=CURRENT;

Create Account

For the CDB service account, the above permissions must be in the following format:

Connect account

GRANT CONNECT TO <C##username> container=CURRENT;

All other permissions

GRANT CREATE ROLE TO <C##username> container=ALL;

Update Account

For the CDB service account, the above permissions must be in the following format:

GRANT ALTER USER TO <C##username> container=ALL;

Documentation Feedback

Feedback is provided as an informational resource only and does not form part of SailPoint’s official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.