User Roles
The Oracle Transportation Management service has a User Role concept which allows for a way to configure and group similar users with similar characteristics together. Every user must have a default user role. Being able to define similar user characteristics at a group level instead of at an individual level provides easier security configuration and easier maintenance. These user roles within the service are where most data visibility via a virtual private database (VPD) and authorization capabilities known as functional security are defined and configured for users.
The user roles in the service are non-hierarchical, meaning they cannot build on top of each other and cannot inherit attributes from each other. User roles cannot union attributes from one user role into another. However, individual user roles can be configured so that they are granted to a specific user and other user roles, which then allow users to switch to another role within the service. Again, this switching does not allow the union of user role attributes from one user role into another but allows the user to morph into another role to have different data visibility or service privileges.
User role definitions can be changed while the service is running and these changes should be reflected immediately. However, there is some overhead associated with this and performance issues could occur. It is not recommended to change the user role definitions in production during peak volumes.
User roles allow for the configuration of VPD, User Access Level, grants to other user role and users, and Access Control Lists. User roles allow for the configuration of the data visibility by use of the Oracle Virtual Private Database (VPD) functionality with settings that include the VPD Context ID, the VPD Profile ID, and the VPD Domain Name that would apply to the users with this user role assigned. These VPD settings will be discussed in the section Virtual Private Database Overview. The user roles also provide a capability to configure the Security Level that is applicable to the user access concepts that will be discussed in the User Access section. The user roles also provide a capability to specify the user role grants and the user grants. The Grantee user role specifies other user roles that will have the ability to use the current user role. The Grantee user specifies individual users that will have the ability to use the current user role. In addition, user roles provide the capability of specifying Access Control Lists (ACL) that will apply to all of the users that are assigned the user role. The following menu item provides the ability to create, view, and modify user roles.
This page is accessed via Configuration and Administration > User Management > User Role. For more details see, the "User Role" help topic.
After a user role is added to the system, you can assign it directly to a user as their default user role or assign it to another role as a grant. If you assign multiple roles via grants, a user can switch between each role without logging out and logging back into the system. For example, you may configure many user roles that provide domain level visibility into different sets of data for different companies. Then, you can assign one or more of these roles to a user and the user could switch between the roles as needed without logging in and out. You can also assign multiple roles to a master role and then assign the master role to a user thereby providing that user with visibility in multiple domains of select data. See the Change User Role section for more information.
Service administrators can set the default user role for any individual user during creation or modification of the user. In addition, there is a way to have the default user role for new users specified on the domain itself. This allows any user that is created in that domain to have the default user role specified for that domain automatically. This can be configured through the following Add Domain and Manage Domain menu items.
- Configuration and Administration > Domain Management > Add Domain
- Configuration and Administration > Domain Management > Manage Domain
Oracle Transportation Management Default User Roles
The Oracle Transportation Management service stages several user roles by default. Please see the below table for the information and details about these default roles.
| User Role ID | Description | Required | Reserved | Can Be Deleted | Notes |
|---|---|---|---|---|---|
| DBA.ADMIN | Intended for use by service super administrator(s). for full access to data and functionality | Yes | Yes | No | Assigned to user DBA.ADMIN. Data access crosses domains. |
| SERVPROV.ADMIN | Intended for the administrator(s) of the Service Provider domain to provide Access to service provider users | Yes | Yes | No | Assigned to user SERVPROV.ADMIN. Data access crosses domains. |
| ADMIN | Intended for use by a service Domain administrator for access to data and functionality. | Yes | Yes | No | Data is limited to the user's domain. Functionality typically includes Domain administration and diagnostics. |
| INTEGRATION | Intended for use by only an external integration user for limited access to external integration | No | Yes | No | Not assigned to any user by default |
| DEFAULT | A default User Role not really intended for normal end user for user access to data and functionality | Yes | Yes | No | Not recommended for direct use for end users. |
| SERVPROV | Intended for Service Provider users for limited access to data and functionality. | Yes | No | No | Data and functionality are limited to those needed by a service provider using Oracle Transportation Management. |
| OTM-SYSTEM | Special user role intended only for the internal otmSystem user, which has very limited service level privileges. | Yes | Yes | No | Designed only for 'otmSystem’ user. |
| OTM-GUEST | Special user role intended only for internal guest user, which has very limited service level privileges and no data privileges. | Yes | Yes | No |
Designed only for 'guest’ user. No data privileges. |
| USER-ADMINISTRATION | Intended only for users who provide user account provisioning. | No | Yes | No | Will allow user administration related modifications with specific exceptions. |
| DATAENTRY | Limited access to data | No | Yes | No |
Data is limited to the data entered by the current user. Not assigned to any user by default |
| EXTERNAL | No | Yes | No | Not assigned to any user by default. May be removed in a future version. |
The DBA.ADMIN and SERVPROV.ADMIN user roles are special roles in that they are primarily intended for the DBA.ADMIN and SERVPROV.ADMIN users respectively. The ADMIN user role is intended for the Domain Admin user. The ADMIN user role will automatically be assign to the Business Domain ADMIN user that is created when creating a new domain in the service. The DEFAULT user role is a default user role that is not really intended for normal end users, but serves more as an example of what could be configured. The SERVPROV user role is intended for use with service provider users. The OTM-SYSTEM user role is intended for use with only the ‘otmSystem’ user. The OTM-GUEST user role is intended for use only with the ‘guest’ user. The DATAENTRY and EXTERNAL user roles are not needed by default, but are provided as example user roles that could be modified and used in an implementation. The INTEGRATION user role is not needed and is not assigned to any user by default, but is provided to easily assign external integration user(s) the access control entry points required for inbound external integration.
The USER-ADMINISTRATION user role is intended for use for users who only want user administration capabilities. A user with this user role will have full access through the User Manager, User Role, Account Policy and LoginHistory User Interfaces. This includes any field or grids on the these screens. Note that VPD and other data restrictions still will apply. For example, since you have access to the Login History User interface, you will not see all login history records. You will be able grant this new user role to your user roles or users as you see fit.
Note the following caveats:
- The USER-ADMINISTATION user role is Reserved. You will only be able to modify the new user role to add User Role Grants and add User Grants.
- The DBA.ADMIN user role and ADMIN user role will still NOT be able to be assigned or granted by this new User Role.
- Any DBA.ADMIN or ADMIN user role user will still not be able to be modified by this new User Role.
- This USER-ADMINISTATION user role does not have its own limited menu. Therefore, you will to need to create and assign a menu through User Access.
Reserved User Roles
The service protects a set of user roles from modification or deletion. These roles are referred to as reserved user roles. Most of the Oracle Transportation Management service default user roles listed above are reserved user roles.
Change User Role
The Oracle Transportation Management service has the ability to allow individual end users to temporarily change their current User Role to another one, after logging into the service. These user role options do need to be granted appropriately to the user through the User Role user and role grants. The Oracle Transportation Management service only supports 1 current user role per user at a time. Changing a user role can be done via the “Settings and Action” popup section in the upper right Header section of the application shell of the service which is seen after successful login.
In order to allow users to switch to another role, another user role needs to be configured so that it is granted to specific user(s) and/or to other user role(s). Just note that this switching does not allow the union of user role attributes from one user role into another. Changing the user’s User Role after login is only valid for the duration of that session or until it is manually reset or changed back.
The end user will have the ability to Change their User Role to their default user role, any additional user role(s) that has been granted to their default user role, and any additional user role(s) that have been granted specifically to their user. The end user can only have 1 current user role at a time.
The ability to Switch User Roles adds a layer of complexity and should be avoided unless absolutely necessary. There are some considerations that should be reviewed prior to implement thousands of user roles.
First, if an end user has the ability to switch to a different user role in order to do a business or management application operation don't they have the ability to do this operation regardless? Forcing end users to have 3 additional mouse clicks to perform their work tasks just to gain access to something they have access to, is just overhead on the end user and the application. Instead of very complex switch user role types of workflows, when an end user has the access to do it; just let them do it instead of constantly switching user roles to do it. Plus, the user will have 3 additional clicks to switch their user role back to the default to be able to do their other work. And that is if they remember to switch the user role back prior to getting errors and having to redo what they just did after fixing their user role.
Next, the required setup is more complex and requires more maintenance and testing. When allowing a user to switch to another user role you potentially have to have a different set of ACLs, VPD related settings, menus per user role and other User Access items per user role. You will now have more than 1 user role that you have to maintain for that user or users that you may need to periodically need to review to ensure it is correct. You can also change the Data visibility / business domain of the user by changing user roles by use of the VPD Domain Name which adds even more complexity. Remember, if the user has the ability to switch to a different user role in order to do a business operation they have the ability to do it already.
Consideration needs to be given since a user can only have 1 current user role at a time within the Oracle Transportation Management service. So if there is a Recurring Process or Agents that run as a particular user, then you do not want that user running these processes switching user roles.
While there are no real consequences of frequently switching user roles, please be aware that there is a waste of CPU cycles to process the user role change, increased network traffic for the requests, and annoyance from end users. With 3 mouse clicks to get permissions for end users to do something they are allowed to do will definitely get annoying after a while if frequently switching roles.
Oracle cannot dictate to clients as to what is necessary or unnecessary in regards to requirements on whether or not to use user role switching capabilities. Oracle can only recommend. Every client should use the switching user role functionality for difference reasons and how they see fit. In reality, there are only 4 valid reasons to switch user roles. These are for VPD Data Visibility reasons, testing of another role that is other user default user role, demonstration purposes and the occasional case where the end user really does need those special permissions to go override or change something they don’t normally need to. The number one reason for changing user roles though, is for VPD Data Visibility either across Business Domains or across specific business regions or locations. For example, I have a planner who only does Northeast corridor order and shipments. The order and shipments are restrained to regions or locations. However a bunch of southwest planner called in sick and help is needed there. So temporarily, a client could have the Northeast planner users help by switching their user roles to see those orders and shipments.