Secure Configuration Overview

As explained in the Service Security Features Chapter, the Oracle Fusion Transportation Management Cloud Service has many different administrator user accessible security configuration mechanisms to configure the service for users accessing the service. This section outlines the secure configurations and describes several recommendations.

There is never a one size fits all secure configuration for all of the Oracle Fusion Transportation Management Cloud Service clients however there are definitely general recommendations and general Dos and Do Nots that can be given.

Failure to follow these recommendations may lead to bad configurations, unintended access, data access, and performance issues or data corruption.

User Roles

Recommendations

Use caution in giving out the DBA.ADMIN user role ability to individual users. This is a super user role and has privileges to everything within the service.
Use caution in giving out the ADMIN user role to individual users. This is an elevated user role and has service privileges to everything but reduced domain data visibility.
It is not recommended to use the DEFAULT user role since this is a pretty broad service privileged user role.
It is recommended to create custom user roles for every role within your organization so that you can easily control and maintain groups of users’ service privileges and data visibility.
Do not create a custom "DBA.ADMIN" or "ADMIN" user roles as this will just sidestep built in service constraints. Do this at your own risk.
Do not modify the "DBA.ADMIN" or "ADMIN" user roles.
Do not change the DBA.ADMIN user's user role.
User names cannot end with "ADMIN." Do not give .ADMIN user names a Nickname.

Users

Recommendations

Do not use commonly known or previously known passwords for the Oracle Transportation Management Users. Use a strong and unique password by at least utilizing the default BASIC PASSWORD RULES Account Policy.
Do not use commonly known or previously known passwords. Use a strong and unique password.
Do not share the DBA.ADMIN user account. Instead give individual users the DBA.ADMIN user role as their default role or provide them ability to change to the DBA.ADMIN user role by granting it to their default user role.
Do not change the DBA.ADMIN user's user role.
Do not use the <DOMAIN_NAME>.ADMIN user account(s).
Expire or delete only unneeded Oracle Transportation Management Users.
Do not expire or delete users who have recurring processes.
Only enabled OBIEE Non-SSO User for users who require access to OAS.
Only grant Business Intelligence Applications and Business Intelligence Roles to users who require it.
Do not use the External User field as there is no such thing as an external user.

Access Control Lists (ACL)

Recommendations

Do not use assign the same ACL at both the User Role and the User level. As a bad and not recommended example, a user has the DEFAULT user role and then the DEFAULT ACL assign to the individual user. This is redundant and cause performance overhead.
Create custom ACLs that only contain the entry points required for a given set of business functionality access(es) required.
Use caution in granting the "ADMIN" ACL since this almost contains every child ACL and allows privileges to everything within the service.
Use caution in giving out the child "Administration" ACL since this only contains administration entry points.
Do not create a custom "COMMON" ACL by copying "COMMON". By doing this, you will miss any new child ACLs granted or additional entry points grouped into "COMMON" in future releases. Do this at your own risk.
Do not modify the "COMMON" ACL.
Make sure that the "COMMON" ACL is in the hierarchy of child ACLs preferably assigned to the User role.
Do not grant "ADMIN", "DEFAULT", and "COMMON" ACL directly to the user. This is not needed at all.
Do not grant the "everyone" ACL.

User Access

Recommendations

Create custom menus for users based on individual roles. These custom Menus should only contain what you want the user to see.
Create custom Screen Sets for users based on roles. These custom Screen Sets should hide fields and available actions you don't want users to see.
Create custom Manager Layouts for users based on roles. These custom Manager Layouts should hide fields you don't want users to see.
When allowing users to change user role that change business domains by use of the VPD Domain, ensure to have equivalent user access records in the domain being changed to.

VPD

Recommendations

Create custom VPD Profiles to be assigned to the custom user roles you defined.
Use External Predicate Rules and create External Predicates to restrict data.
It is recommended to block every table that is not required with a predicate that will never be true like (1=2).
Do not modify the DBA and OTM-GUEST VPD Profiles.
Take precaution in creating External Predicates to restrict data visibility when a certain join or condition may not exist prior to business actions completing.

Account Policies

Recommendations

Use the default "BASIC PASSWORD RULES" Account Policy for users or create an even stronger custom account policy based on the default password rules. This will ensure a strong Oracle Transportation Management user password.
Do not use the "NO RESTRICTIONS" Account Policy.
It is strongly recommended not to use the "NO DORMANCY" Account Policy.
Do not modify the default Account Policies.

General

Recommendations

"Menu Security" is not security; it is obfuscation at best. While most interactive end users will not stray outside of URL menu links presented, users could potentially still gain access if they know the service resource URLs.
Use caution when granting access to use SQL Execution Interface tool.
Use caution when granting access to upload files into the service.
Use caution when granting access to upload raw data via CSV or DB.XML.
Use caution when granting access to use external integration functionality.
Use caution when granting abilities to define External Systems
Disable or delete obsolete and unused External Systems to prevent accidental usage.