One of the principles of good security practice is to keep all software versions and patches up-to-date. This document is based on a release level of 12.2 on all software and documentation.
Keep both the E-Business application middle-tier and the database behind a firewall. In addition, place a firewall between the middle-tier and the database. The firewalls provide assurance that access to these systems is restricted to a known network route, which can be monitored and restricted, if necessary. As an alternative, a firewall router substitutes for multiple, independent firewalls.
If firewalls cannot be used, be certain to configure the TNS Listener Valid Node Checking feature which restricts access based upon IP address. Restricting database access by IP address often causes application client/server programs to fail for DHCP clients. To resolve this, consider using static IP addresses, a software/hardware VPN or Windows Terminal Services or its equivalent.
Demantra data is secured as follows:
The data is partitioned into components, which generally correspond to organizational roles, which can overlap. Each component has an owner, who acts as the administrator and who can create additional users. (See “Creating or Modifying a Component”.)
Each user is authorized for one component. In addition, you can further restrict a specific user's access to data by applying filters so that the user can see only specific level members as well as only certain series.
Users can belong to groups, and group members can collaborate, inside or outside of workflows. When a user creates a note, he or she can control access to that note by user or by group.
The following table summarizes how Demantra controls access to data elements.
It is useful to remember that each user of a component sees a subset of the data associated with that component. You cannot give user access to data that is not contained in the component.
Each component has the following properties:
Series, levels, units of measure, indexes, and exchange rates. For each level, you define permissions that the users have for the members of that level. The choices are as follows:
Full control, including ability to delete members
Read/write existing members
Read existing members
No access
An owner. This owner acts as the administrator of the component.
Possible additional users, created by the owner. The owner can also further restrict data access for particular users.
User details are defined using the Business Modeler (Security > Create/Modify User). For more information about users see: Creating or Modifying a User
For users, you can specify the following details:
Overall permission level, which can enable the user to log onto Demantra administrative tools and modify the component.
Series that the user can access, generally a subset of the series included in the component.
Optional permissions to control which level members the user can see and edit. The choices are as follows:
Full control, including ability to delete members
Read/write existing members
Read existing members
No access (the members are filtered out entirely for this user)
Group or groups to which the user belongs.
For user groups, you can specify the following details:
Which users are in the group.
Whether this user group is also a collaboration group (for use by the Workflow Engine).
Whether users of this group can log into the Workflow Editor.
Most level members are created by integration and it would generally be undesirable to delete them. Most users, therefore, do not have delete access to these members. The exception is a user with System Manager permission; see “Permission Levels”.
Level members can be created directly within Demantra (through Member Management). For any these members, the user who created the member has permission to delete it.
When a user views data at an aggregation level that is higher than where the permissions are set, it is necessary to resolve how to aggregate editable members and uneditable members. Demantra uses the following rules:
If all lower-level members are editable (either as read/write or full control), the member is editable.
If some of the lower-level members are visible but read-only, the member is not editable.
If some of the lower-level members are not visible, those members are filtered out and do not affect the aggregation. The upper-level member may or may not be editable, depending on the preceding rules.
As the implementer, you can define custom methods to perform operations on a selected member, for users to access as an option on the right-click menu. You can apply security to your methods, just as you do with the core right-click actions.
You can define a user security threshold for visibility of that method. For example, you can state the method should only be visible to users who have 'Full Control' of the member from which you launch the method. To control this, you log into the Business Modeler, select 'Configure > Configure Methods'. For 'Method Type'= Custom, you can select from the Security Threshold of Full Control, Read & Write or Read Only.
For information on methods, see “Methods and Workflow”.
If a worksheet is private, it can be seen only by its owner. If it is public, it is visible to all users.
To change who can access a worksheet
Log onto the Business Modeler as described in “Logging onto the Business Modeler.”
Click Tools > Worksheet Management.
The Worksheet Manager is displayed.
In the row corresponding to the worksheet, click the Permission Type field.
Click Private or Public and click OK.
Oracle does not support Microsoft SQL Server in this release. Please monitor My Oracle Support for versions supporting SQL Server. Items marked with ** are not valid unless support for Microsoft SQL Server is available.
In Demantra, the database connection (and data source configuration) is controlled by the Java Naming Directory Interface (JNDI).
To point Demantra to a different database without rerunning the installer, complete the following steps:
Make a backup copy of server.xml. This file is located in …\Oracle Demantra\Collaborator\Tomcat\conf\.
Open server.xml for editing.
Locate the following sections:
Context path="/demantra"
docBase="E:\Program Files\Oracle Demantra 73b37\Collaborator\demantra"
crossContext="false"
debug="0"
reloadable="false"
Resource
name="jdbc/DemantraDS"
auth="Container"
type="javax.sql.DataSource"
driverClassName="oracle.jdbc.driver.OracleDriver"
url="jdbc:oracle:thin:@dempm2db.us.oracle.com:1521:ORCL"
username="demo73b37"
password="manager"Modify the “username” and “password” sections to point to the new schema and to use the new password.
To point to a different DB, modify the DB host and SID within the URL, which in this example are “dempm2db.us.oracle.com” and “ORCL”, respectively.
Restart the web server. (If you are not using Apache Jakarta Tomcat, refer to your application server’s version-specific documentation to learn how to modify the database hostname, username, password, and SID (system identifier) specified by the JNDI.)
The principle of least privilege states that users should be given the least amount of privilege to perform their jobs. Over-ambitious granting of responsibilities, roles, grants, etc., especially early on in an organization’s life cycle when people are few and work needs to be done quickly, often leaves a system wide open for abuse. User privileges should be reviewed periodically to determine relevance to current job responsibilities.
System security stands on three legs: good security protocols, proper system configuration and system monitoring. Auditing and reviewing audit records address this third requirement. Each component within a system has some degree of monitoring capability. Follow audit advice in this document and regularly monitor audit records.
Oracle continually improves its software and documentation. Check the notes on My Oracle Support regularly for the latest information.