Oracle Transportation Management Service Automatic User Creation
In the Oracle Transportation Management service there are two post-provisioning automatic user creations that can occur during different circumstances. One of these user creations will occur when a new business domain is created and the other one can be configured to occur when a new service provider is created.
Business Domain ADMIN User
A new user is created during a new business domain creation and there is no way to disable this user from being created automatically in the service. This ADMIN user is required and will be reserved. This user will have a user ID in the format of <NEW_DOMAIN_NAME>.ADMIN. This user will have the ADMIN user role, and this user will be used internally for automation agents and integration transaction processing in that business domain. There are also other assumptions in the service that there is an <DOMAIN_NAME>.ADMIN user, which makes this user required. The password for this Business Domain ADMIN user is prompted for during the business Domain creation and it is a required field on the UI. Make sure to use a strong password for this Business Domain ADMIN user during initial Business Domain creation. It is strongly recommended to review any of your existing Business Domain ADMIN users’ password(s) immediately and ensure recently updated passwords that are not generally known.
Service Provider User
By default in the Oracle Transportation Management Cloud service, a new Service
Provider user is NOT created when a new service provider is created. However, it can
be configured to have this user be automatically created when a new service provider
is created through the service. If configured, this user ID would be created in the
format of SERVPROV.<CURRENT_DOMAIN>-<NEW_SERVPROV_XID> and
this new service provider user will have the limited SERVPROV user role. This new
service provider user will NOT have a default password. In order for this new
service provider user to use the service, another user administrator user will need
to give this service provider user a password within the Oracle Transportation
Management service. It is strongly recommended to immediately review all existing
SERVPROV users and ensure strong and recently updated passwords that are not
generally known.
This automatic service provider user creation during a new service provider creation can be enabled via the following property :
glog.servprov.autoCreateUser=[true|false] (defaults to false)
Disabling Service Users
Instead of actually deleting Oracle Transportation Management service users, users can be set to become effective and expired on specific dates. This is the preferred recommendation for disabling user accounts. The effective and expiration dates can be set on the User Manager for individual users or via the Manage User Expiration Date Action by a user that has the correct service administration access to do so. Please also note that the actual date of the effective date is the beginning of the date in the service server time. The actual date of the expiration date is the end of the date in the service server time. If the user log-in is not effective or expired the user will not be able to log into the service. It is also recommended to remember to check that the user that is set to expire is not a contact required in the service and also does not have any scheduled recurring process to run. Any recurring processes with an expired user will fail to run until it is assigned to another user.
Service users can be deleted from the service when the user account is no longer valid. However, before deleting any user, remember that any existing Recurring Processes for that user needs to be assigned to another user. Any recurring processes with a missing user will fail to run if these are not assign to another user. The recurring process will actually be deleted. All records which have a Foreign Key relationship to that user will also have to be reassigned or deleted.
Manage User Expiration Date Action
The Oracle Transportation Management User Manager's Manage User Expiration Date UI Action can be used to 'Manage the Users' expiration dates' en masse. This action supports multiple User IDs at once. Note that leaving the data field blank will actually null out the database column value.
User Account Policies
The Oracle Transportation Management service provides the ability to set up different account policies for each individual user. Most of these Account Policy settings are only checked and enforced during an interactive end user login or a REST http Basic Authentication user login. The Account Policy settings are not checked during the other Integration User Authentications. Some of the others Account Policy settings are checked when the user themselves is conducting an Oracle Transportation Management service password change, or during an administration user maintenance update though the UI.
For proper security, users should be defined with an account policy.
Account policies are accessed via Configuration and Administration > User Management > Account Policy. For more details, see the "Account Policy" help topic.
The Account Policies provide control over password definition, password renewal rules and login behavior. Account policies allow configurability of the following password rules:
- Password Rules: validation rules for password strength
- User Password Expiration
- Warning period for password expiration
- Duplicate password prevention, including configurable number of historical passwords
The account policy allows you to configure the following login behavior:
- Maximum number of failed login attempts before locking the account
- Lockout Attempts and Duration for Entering Incorrect Passwords
- Login History for auditing purposes
- Dormant Account Locking
Some of the available account policy settings, while they can be configured really no longer make sense in the Oracle Transportation Management cloud service since the service user’s password is never actually entered by the end user. For example you can certainly set the Expiration Duration and Number of Passwords for History as desired and during the interactive end user login the user will be prompted to change their Oracle Transportation Management service password and it will be checked against previous passwords. However, this may confuse end users when they have remember a password they never use and have to periodically change it.
However, it is strongly recommended to assign users an account policy that contains basic password rules.
The service currently stages only one Account Policies during service provisioning for your use that's recommended for use. This is the BASIC POLICY account policy. The other account polices that are staged aren't recommended, are deprecated and will be removed in a future version. These are the BASIC PASSWORD RULES, STANDARD, NO DORMANCY, and NO RESTRICTIONS account policies. These staged account policy data records aren't assigned to any reserved user that Oracle Transportation Management service is provisioned with. The account policy field is defaulted to the BASIC POLICY account policy in the User Manager User interface for any user that's being newly created or an existing user is being edited and it doesn't contain an account policy.
| Account Policy | Description |
|---|---|
| BASIC POLICY | A default account policy that contains updated basic password rules along with the lockout. |
| BASIC PASSWORD RULES | An account policy that contains only basic password rules that's deprecated and will be removed in a future release. |
| STANDARD | A standard account policy that contains example settings that is not recommend; is deprecated and will be removed in a future release. |
| NO DORMANCY | Not recommended for use and is deprecated and will be removed in a future release. |
| NO RESTRICTIONS | Not recommended for use and is deprecated and will be removed in a future release. |
Account Policy Password Rules
When creating an account policy, password rules should be created to ensure the strength of passwords chosen by user administrators or potentially end users. Every Oracle Transportation Management user requires a password within the service even though this password is not ever used and entered by an interactive end user. It is strongly recommended to ensure a strong password is provided for every user by the use of the Password Rules.
These password rules are defined using a regular expression, thus supporting standard rules (i.e. alphanumeric required) as well as providing the ability to create more complex customer-defined rules which adhere to your corporate standards.
The regular expression is based on standards for the Java Development Kit. Details on the expression patterns can be found at Java Pattern Regular Expressions.
The BASIC POLICY and the BASIC PASSWORD RULES Account Policies contain Account Policy Password Rules that are staged with the service. These password rules are described in the table.
| Account Policy | Password Rules | Description |
|---|---|---|
| BASIC POLICY |
.{12,} \p{Alpha} \p{Digit} \p{Lower} \p{Upper} \p{Punct} |
Password must have at least 12 characters. Password must contain at least one alphabetic character. Password must contain at least one numeric character. Password must contain at least one lower case character. Password must contain at least one upper case character. Password must contain at least one special character. |
| BASIC PASSWORD RULES |
.{8,} \p{Alpha} \p{Digit} \p{Lower} \p{Upper} |
Password must have at least 8 characters. Password must contain at least one alphabetic character. Password must contain at least one numeric character. Password must contain at least one lower case character. Password must contain at least one upper case character. |
Oracle Transportation Management User Login History
All failed attempts to login to the Transportation and Global Trade Management Cloud service are automatically logged as exceptions. While the Keep Login History flag can be enabled on any custom Account Policy, the Transportation and Global Trade Management Cloud service will record all end user interactive login attempts (successful or failed) regardless of the setting. The history can be viewed from within the service using the Login History user interface. These successful or failed Login History records should be visible to any user with the DBA.ADMIN user role.