1. Securing Oracle Enterprise Data Quality
  2. About EDQ Security

1 About EDQ Security

This chapter explains the key security concepts used in Enterprise Data Quality (EDQ). It includes the following sections:
  • Introducing EDQ Security
    Security within EDQ applies to accessing the application (ensuring that only authorized users can access it, and that data within the application is secured), and auditing of user actions to identify anomalies.
  • EDQ User Groups
    All rights to EDQ are granted using a set of permissions that are granted to a user group (or 'internal' group). Where users are managed externally, for example in WebLogic, or in Active Directory, or in an alternative LDAP provider, permissions are granted by mapping External Groups from that directory to these internal groups.
  • EDQ Permissions
    EDQ has four types of permission, as listed below. Permissions are granted to users by means of EDQ User Groups, which are in turn mapped to external user groups.
  • Default EDQ Groups and Permissions
    The default groups and a summary of their permissions are listed below.
  • Default Administrator User Accounts
    On an installation of EDQ on WebLogic server, the weblogic administrator user account (normally 'weblogic', with a password selected when the domain was created), is a member of the 'Administrators' group in WebLogic, which is mapped to the 'Administrators' group in EDQ by means of a default login.properties file in the EDQ Home configuration directory.
  • Mapping External Groups to EDQ Groups
    External groups are mapped to internal EDQ Groups from the Administration pages of the EDQ Launchpad. An external group is granted all permissions from all EDQ groups that it is mapped to.
  • Terms Used in this Guide
    This section provides information about the terms used in this guide.

Introducing EDQ Security

Security within EDQ applies to accessing the application (ensuring that only authorized users can access it, and that data within the application is secured), and auditing of user actions to identify anomalies.

This guide covers the following:

  • Providing secure access control

  • Securing data at rest and in transport.

  • Providing appropriate security auditing capabilities to ensure user activity can be securely logged and traced.

For more information, see About Oracle Enterprise Data Quality in Understanding Oracle Enterprise Data Quality.

Parent topic: About EDQ Security

Authentication

Details of users and groups in EDQ can be stored within its own internal directory or taken from an external LDAP server, such as Microsoft Active Directory. Using external authentication sources enables EDQ to share user credentials with other systems, reducing the number of passwords that users need to remember and maintain, while eliminating overhead in management of users and groups.

Parent topic: Introducing EDQ Security

Authorization

Authorization controls what users can do once they have authenticated successfully. Authorization of users is based on a model of users, and permissions associated with groups. A user is a member of one or more groups (either directly or by mapping an external group to an internal group), and is authorized according to the permissions that are associated with that group.

Parent topic: Introducing EDQ Security

Encryption

Both the WebLogic and Tomcat servers support HTTPS and require that traffic between the client and EDQ is encrypted so that it cannot be read or modified in transit. For environments where HTTPS is not an option, EDQ encrypts passwords sent between the client and server.

Parent topic: Introducing EDQ Security

Auditing

EDQ supports auditing of user actions using the Oracle Fusion Middleware Audit Framework. In addition, EDQ can be configured to write audit information to files.

Parent topic: Introducing EDQ Security

EDQ User Groups

All rights to EDQ are granted using a set of permissions that are granted to a user group (or 'internal' group). Where users are managed externally, for example in WebLogic, or in Active Directory, or in an alternative LDAP provider, permissions are granted by mapping External Groups from that directory to these internal groups.

Users in the external group then have the permissions from whichever group or groups the external group is mapped to. Where users are managed in EDQ (in the 'internal' realm), these users are made direct members of one or more of the internal groups, and therefore have the associated permissions.

Parent topic: About EDQ Security

EDQ Permissions

EDQ has four types of permission, as listed below. Permissions are granted to users by means of EDQ User Groups, which are in turn mapped to external user groups.

Parent topic: About EDQ Security

Application Permissions

These are simple permissions that grant (or deny) groups of users access to log in to EDQ user applications, such as Director, Server Console, and Case Management.

Parent topic: EDQ Permissions

Functional Permissions

These are permissions to access certain functions of the system, for example, the ability to modify a Reference Data set in Director, or the ability to change the state of a case, or alert in Case Management.

Parent topic: EDQ Permissions

Dynamic Permissions (in Case Management)

These permissions are dynamically created within a Case Management workflow as configured in Case Management Administration. Dynamic permissions are used to restrict access to specific cases or alerts or to case comments or attachments.

Parent topic: EDQ Permissions

Project Permissions

By default, a project created in Director is accessible to all user groups. However, projects may be restricted to a smaller set of groups. Where this is the case, any user that is not in a group that has access to the project, will not be able to see or use the project in any way.

Note:

Any user that has the ability to add projects in Director automatically has access to all projects.

Parent topic: EDQ Permissions

Default EDQ Groups and Permissions

The default groups and a summary of their permissions are listed below.

To see full details on the precise set of permissions granted to each group, select a group from the Administration - Groups option on the EDQ Launchpad (after logging in as an administrator), and click on the Edit button.

Table 1-1 Permissions for various user groups

Group Summary FunctionalPermissions ApplicationPermissions

Administrators

Power users with all functional and administrative privileges

All

Dynamic Case Management permissions are not automatically granted to Administrators

All

Data Stewards

Users with review access to Director and Dashboard, with permission to review all results, resolve issues, and make manual match and merged output decisions, but without permission to create or change any processing logic

Read-only permissions to Director

Full permissions to Match Review

Dashboard

Director

Match Review

Issue Manager

Case Management

Server Console

Executives

Users with access to Dashboard results only

Dashboard: View Dashboard

Dashboard

Match Reviewers

Users with access to the Match Review application, the Case Management application and Dashboard only

Basic Case Management permissions (no bulk updates and cannot view cases assigned to others)

Dashboard: View Dashboard

Match Review

Issue Manager

Case Management

Dashboard

Review Managers

Users with access to the Case Management application, with permission to configure case management and perform bulk edits on cases and alerts.

Full Case Management permissions except deletion and editing of audit trail activities

Case Management

Dashboard

Data Analysts

Users with permission to create and modify processing logic in Director, but with no administration privileges

Full access to Director except the ability to modify System-level (cross-project) configuration and access the Users data store.

Director

Server Console

Match Review

Case Management

Issue Manager

Parent topic: About EDQ Security

Default Administrator User Accounts

On an installation of EDQ on WebLogic server, the weblogic administrator user account (normally 'weblogic', with a password selected when the domain was created), is a member of the 'Administrators' group in WebLogic, which is mapped to the 'Administrators' group in EDQ by means of a default login.properties file in the EDQ Home configuration directory.

This therefore grants the weblogic user, and any other users in the WebLogic Administrators group, administrative access to EDQ.

Note:

Ensure this mapping is fixed and intended only to grant initial access so that the actual required permissions can be set by mapping external groups to internal groups, see Mapping External Groups to EDQ Groups

On an installation of EDQ on Tomcat, a default internal administrator user account called 'dnadmin' is created. The initial password for this user is also 'dnadmin', but it must be changed to a more secure password after initial login. In such an installation, by default this is the only user account with administration rights, and it is important not to delete the user or forget the password, as otherwise it may not be possible to access the system.

Parent topic: About EDQ Security

Mapping External Groups to EDQ Groups

External groups are mapped to internal EDQ Groups from the Administration pages of the EDQ Launchpad. An external group is granted all permissions from all EDQ groups that it is mapped to.

To map external groups to internal EDQ groups, follow the steps below:

  1. Log in to the EDQ Launchpad as an Administrator.
  2. Click on the Administration dropdown link, and click on External Groups.
  3. Expand the name of the external realm (this is 'ORACLE' on a default system) and click on a group to edit its mappings.
  4. Select the EDQ Groups you want to grant to the external group, and click on Save to save the changes.

It is useful and desirable to create some external groups on the domain that can be mapped precisely to internal EDQ groups, to ensure optimal permission assignment.

Note:

For installations with a large number of external user groups, an optional filter can be specified in a local login.properties file to narrow down the list of groups that is available in this screen. See Filtering Groups

for more information.

Parent topic: About EDQ Security

Terms Used in this Guide

This section provides information about the terms used in this guide.

The following terms are used in this guide:

  • AD – Active Directory

  • Certificate – Generally refers to an X.509 certificate

  • Kerberos – Network authentication protocol

  • LDAP – Lightweight Directory Access Protocol

  • OID – Oracle Internet Directory

  • OPSS - Oracle Platform Security Services

  • SSL – Security Sockets Layer, a protocol for encrypted connections over which application traffic can be transported. Replaced by TLS, although SSL is still used as a generic term.

  • TLS – Transport Layer Security, a successor to SSL.

  • WLS – WebLogic Server

  • X.509 Certificate – A certificate issued by a trusted authority (certificate authority) to certify that a specified entity (individual, organization, server, or other entity) holds the matching private key for a public key.

Parent topic: About EDQ Security