This chapter explains the key security concepts used in Enterprise Data Quality (EDQ). It includes the following sections:
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.
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.
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.
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.
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.
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.
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.
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.
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.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 |
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 Section 1.6, "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.
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:
Log in to the EDQ Launchpad as an Administrator.
Click on the Administration dropdown link, and click on External Groups.
Expand the name of the external realm (this is 'ORACLE' on a default system) and click on a group to edit its mappings.
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 Section 4.2.5, "Filtering Groups"for more information.
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.