| Oracle® Retail Predictive Application Server and Applications Cloud Edition Security Guide Release 22.1.202.0 F56956-01 |
|
 Previous |
 Next |
| Oracle® Retail Predictive Application Server and Applications Cloud Edition Security Guide Release 22.1.202.0 F56956-01 |
|
Previous |
Next |
This chapter contains information on security activities carried out in the Compute Tier.
Users of RPASCE applications are created and managed within OCI IAM. RPASCE allows administrators to create user groups within the application that correspond to roles defined in OCI IAM. When a user logs into the RPASCE application, the application will check to see if that user belongs to any roles that correspond to a group defined in the application and assign the user the privileges granted to those groups.
User groups are typically assigned based on a common business role such as Planners in order to facilitate managing the authorization settings at the group level. However, users will also have certain roles that server non-business purposes, as described "Non-Business Roles".
When a user is added, either through the Synch Users task or when a user logs into the application for the first time, a position is created for the user in the metadata dimension User. Similarly, when a group is added, that group is assigned a position in the metadata dimension Group.
As users enter the OCI IAM system, they can be granted both the application authorization role and one or more of the business roles. Once granted appropriate roles, users will be able to access the RPASCE application with the corresponding access rights. However, some additional administrative setup is required for a user accessing the system for the first time.
Position security is not role-based and is not managed through OCI IAM. It is therefore necessary for an administrative user to set the position access rights for a new user in order for that user to be able to interact with data in the application. Additionally, new users will not have access to the Dashboard in the RPASCE client until a dashboard workbook has been prepared for them. When a new user first logs in, that user will receive a message from the application to contact their administrator to complete these setup processes.
During the lifetime of a user within the system, any changes to that user's responsibilities can be accommodated by updating the set of roles assigned to the user in OCI IAM. If the set of roles possessed by a user change, those changes will automatically result in a change to that user's access rights when that user next logs in that reflect the access rights of the new set of roles they possess.
When a user should no longer be granted access to the application, the application authorization role can be revoked in OCI IAM or, if appropriate, the user can be dropped from OCI IAM entirely. No subsequent login attempts by that user will succeed, and they will no longer have access to the application and its data.
When a user is removed from the system, the system may continue to hold resources created by and for that user in the form of workbooks, saved formatting, and so on. To allow these resources to be reclaimed, a pair of administrative utilities can be run. First, the Sync Users from OCI IAM utility will query OCI IAM for the set of users authorized for the application. Any users who no are longer authorized for the application because of role changes or as a result of being removed from OCI IAM will be flagged within the application as expired.
A second utility, Manage Users, can then be executed. This utility will drop all workbooks and reclaim all other resources associated with the expired users and will purge them from the system. The purpose of this two-step process is to safeguard against the loss of user information as a result of accident. Purging a user from the system and deleting all that user's work may result in a significant loss of time and effort. As such, it is recommended that the two utilities be scheduled to run separately in order to provide a chance for error remediation prior to the irrevocable deletion of user data.
Two special roles are associated with an RPASCE application using AUM: the first is the authentication role and the second is the application administration role. These roles are do not relate to the business processes of the application, but are instead used to manage access to the application and determine which users have administrative privileges within the application.
The names for these roles are not fixed and will vary between RPASCE applications and between the different environments (production, stage, and so on) making up a customer instance. For new customers, the role names will be provided during the provisioning and deployment process. For existing customers migrating to AUM, they are created as a part of the migration process.
In order for users authenticated by OCI IAM to be allowed access to the RPASCE application, they must belong to the application authorization role. Users who do not possess the authentication role will not be allowed access to the application, even if they possess one or more of the roles defined and granted rights in the application. In this way, a single set of business-related roles can be managed across multiple RPASCE application instances but access can still be limited for an application instance to a subset of all users. It can be useful, for example, to share user roles between a stage and a production environment but grant access to the stage environment to a subset of users.
Under the AUM model, users are no longer granted administrative privileges through the setting of the admin flag within the user management templates. Instead, users possessing the administrative role for a given application instance will be granted admin rights for that application instance. These rights can then be managed by assigning a user the administrative role or revoking that role, with the changes taking effect automatically when the user next accesses the RPASCE application.
User accounts can be marked as deactivated by the administrator in the OCI IAM console. This prevents the user from logging on with the RPASCE Client. The account remains locked until the administrator re-activates the user.
A number of roles are created within OCI IAM as part of the provisioning process that are used to support the RPASCE applications. Some of these roles are created to support user operations and must be assigned to users in the system.
However, there are also many roles created within OCI IAM to support the integration of the RPASCE systems with other systems and components within the Cloud environment. These roles are used by the internal processes of the system and, in general, do not need to be assigned to users of the system. Nor would such an assignment meaningfully affect the access rights of a user, as those systems are not exposed outside of the Cloud environment.
This section provides information about these roles created within OCI IAM. It describes the roles that can be used by users and provides information about what those roles are used for. It also provides a summary description of the types of roles used internally by the system.
For GA applications, these include a set of GA user roles that correspond to the standard roles in the processes those GA applications support. The roles created vary by the application, and information about the roles created and their uses are detailed in the application-specific User Guides.
In addition, a role is created to allow access to the content of Retail Home, including access to notifications received in the RPASCE Client and Retail Home. This role is named PLATFORM_SERVICES_ADMINISTRATOR_ABSTRACT for production environments or PLATFORM_SERVICES_ADMINISTRATOR_ABSTRACT_PREPROD for stage environments. The role appropriate for an environment must be assigned to any and all users who must have access to Retail Home and notification content in that environment.
Users who need to administer translation resources through Retail Home must be provided with either the RETAIL_HOME_ADMIN or the RETAIL_HOME_ADMIN_ PREPROD role. Users who need to administer notifications through Retail Home must be provided with either the PLATFORM_SERVICES_ADMINISTRATOR or PLATFORM_SERVICES_ADMINISTRATOR_PREPROD role. As above, the proper role varies between production and staging environments.
Finally, for instances that make use of the optional Atomic User Management functionality, two non-functional roles are defined: the application authorization role and the application administration role. These roles control access to the application in general (for the former) and to the administrative activities of the application (for the later) respectively.
In addition to the user roles described above, a large number of roles are created to support the processes and actions of the system.These roles need not be assigned to users of the application. They are instead used for communication between the RPASCE application and other components of the Cloud environment.
In many cases, system accounts are created within OCI IAM that make use of these roles. In general, these roles tend to be prefixed by the component of the overall system that uses the role. For example, BdiEdgeRpasJobAdminGroup is used by RPASCE to accomplish integration with external systems through the BDI interface.
Information on the roles created to support integration with other components in the Cloud environment can be found in the documentation for those components:
Oracle Retail Bulk Data Integration Cloud Service Integration Guide
https://docs.oracle.com/cd/B31315_01/191000/BDI%20Implementation%20Guide/bdics-191000-impg.pdf
Oracle Retail Process Orchestration and Monitoring Implementation Guide
https://docs.oracle.com/en/industries/retail/retail-process-orchestration-monitoring/19.1/index.html
RPASCE applications support integration with OAS (Oracle Analytics Server) and the OAS Data Visualizer tool. During environment provisioning, a connection will be created within an environment's OAS instance to the Planning Data Schema containing the data used by any RPASCE applications in that environment.
In order for users to create or view reports within OAS or to work with the OAS Data Visualizer, they must be granted permissions through the assignment of OAS application roles. Standard OAS roles allow control over which users are allowed to create or view content with OAS. These default roles include:
DV Content Author - users able to create data sources and visualizations within the Data Visualizer.
DV Consumer - users able to view visualizations created within the Data Visualizer.
BI Content Author - users able to create reports and dashboards in OAS.
BI Consumer - users able to view reports and dashboards in OAS.
Note that many roles automatically include all users in other roles. For example, all users with the DV Content Author are default members of DV Consumer.
Additionally, customers may wish to create additional roles to allow or deny access at a more granular level. For instance, customers with multiple Oracle Cloud subscriptions may wish to make use of additional roles to allow access to the reports created for one application to users of that application but not to users of another second application.
For more information about pre-created user roles in OAS and use of additional roles to provide additional control over information, see "Set Up Security with Users, Groups, and Application Roles" in Managing Security for Oracle Analytics Server.
|
Note: In most cases, the pre-created roles described in the OAS Security Guide will be prefixed with the tenant ID for a customer's environment. For example, for an environment with the tenant ID abc123, the role DVConsumer will instead appear as abc123-DVConsumer. |
This section deals with authorizing access.
Currently, workbook access is either granted or denied. If users have been granted access to a workbook, they can open, modify, and commit the workbook. No distinction is made between read-write-commit, read-write, and read-only access. Workbook access is automatically granted to the user who builds a workbook, and it can be shared by that user with other users in the system who are authorized to view that workbook and the data contained within it. The user who receives access to a workbook has access to all data and operations within the workbook without limit.
For guidance on assigning permissions to workbooks by role and group, see the Implementation Considerations chapter, section "Security," of each RPASCE Application's Implementation Guide. All recommendations in the guides are for the GA solution. If a customer chooses to customize permissions, keep in mind that the Principle of Least Privilege: only provides users with sufficient permissions to do their job and nothing more.
|
Note: A user must have access to the workbook template in order to access the workbook, even if the workbook has world or group access rights. |
Users with administrator status automatically have access to all workbook templates. By default, administrators have access to all workbooks that are saved with world access. If a workbook is saved with group access, administrators can only access the workbook if they are members of the default user group of the user who saved the workbook.
Another aspect of workbook security is the ability to set limits for the number of workbooks that a user can have saved at any given time. Limits can be set for a user per template, for a user group per template, or for a template for all users. The limits are evaluated in the above order, which means that a limit defined at user-template overrides any values defined at group-template or template. If the above limits are not defined, the default value is one billion.
The limits are checked when the workbook build process is initiated. When the limit is reached, an error message displays informing the user that the workbook build process cannot complete because the limit has been reached. The message also lets the user know what that limit is. The wizard process then terminates.
Administrative users have full access to all workbook templates, regardless of the access rights that other administrative users may assign to them in the Security workbook. The administrative user can build the Security workbook to change the access right back, so the nominal assignment does not matter for administrative users.
Non-administrative users do not have access to the Security template and User Administration template groups even if the administrator inadvertently assigns them access rights.
Position Level Security allows access control for dimensions on a position-by-position basis. This capability is completely optional. If position level security is not explicitly defined and configured, all users in a application have access to all positions in all hierarchies. After the position level security is defined, access to a position can be granted or denied for individual users, users in a group, or for all users.
Position level security can be defined at levels at or above base (such as class in the product dimension) in any dimension other than calendar. As positions are added at a level lower in the dimension than where the position level security is maintained, access to those positions is automatically granted if a user has access to the parent position.
For example, if security is maintained at the subclass level, users are automatically granted access to all the SKUs in a given subclass if they have access to that subclass. This includes those that were added after security was established.
Exactly one level in each dimension can be defined as the security level for the dimension. If a security level is defined for the dimension, all levels in the dimension have position level security enabled, but position security is set at or above the designated level. For example, if the class level is designated as the security level, an administrator can maintain access to positions in the class level or at any level above class.
To specify the security level for a dimension, the application designer must update the configuration and either rebuild or patch the application. After a security level is defined for a dimension, all users in the application default to having access to all positions in any level in the dimension. Additionally, users automatically have access to newly added positions. Views in the Security Administration workbook are used to control position access for individual users, user groups, or all users (referred to as world or default access). Three views are provided in this workbook for each dimension with a defined security level. The default view controls access to positions for all users (for instance, Prod Security Default); one view controls access to positions by user group (for instance, Prod Security Group); and the last view controls access to positions by individual users (for instance, Prod Security User).
Access must be granted at all levels for a user to have access to a position. This means that a position must have a value of true at the levels default/world, group, and user. Table 4-1 demonstrates how access is granted or denied based on all combinations of settings.
In the table, security is set by Position. Denied = False and Granted = True. Based on the settings for User, User Group, and World, the user is either granted or denied access, as shown in the Resulting Access column.
Table 4-1 Granting Access
| User | User Group | World | Resulting Access |
|---|---|---|---|
|
Denied |
Denied |
Denied |
Denied |
|
Denied |
Denied |
Granted |
Denied |
|
Denied |
Granted |
Denied |
Denied |
|
Granted |
Denied |
Denied |
Denied |
|
Denied |
Granted |
Granted |
Denied |
|
Granted |
Denied |
Granted |
Denied |
|
Granted |
Granted |
Denied |
Denied |
|
Granted |
Granted |
Granted |
Granted |
Position-level security is used when a user selects positions in the wizard process before building a workbook. Only positions to which a user has access are available for selection in the 2-tree, which are then included in the build of the workbook.
This section specifies how to set resource limits. The views described in the subsections below - WorkbookTemplate Limits, Max Domain Session Limit, Max User Session Limit and Dimension Modification Rights are the views present in the security administration workbook. See the Security Administration Workbook section in Oracle Retail Predictive Application Server Cloud Edition Administration Guide for more information.
The Workbook Template Limit views are used to limit the number of workbooks that the user can have saved. Limits can be set for a user per template, for a user group per template, or for a template for all users. The limits are evaluated in the above order, which means a limit defined in a user-template overrides any values defined at group-template or template. If the above limits are not defined, the default value is one billion, but it is not displayed in the workbook.
The limits are checked when the user begins the workbook build process. If the limit has been reached, an error message appears that informs the user that the workbook build process cannot completed because the limit has been reached. The wizard process then terminates.
The Max Domain Session Limit view is used to limit the number of user sessions that can be attached to a single application by all users of that application. The limit is set at the application level. This limit is checked during user login. If the limit has been reached, an error message appears to inform the user that the login has failed because this limit has been reached.
The Max User Session Limit view is used to limit the number of concurrent user sessions that can be attached to a single application by the same user at the same time. The limit is set per user so that the administrator can control the maximum number of concurrent sessions that are allowed for an individual user.
This limit is checked during user login. If the limit has been reached, an error message appears to inform the user that the login has failed because this limit has been reached.
The Dimension Modification Rights view allows the administrator to determine which user-defined dimensions, if any, a user can modify. Its purpose is to provide a filtered list of user-defined dimensions to be shown on the dimension selection wizard page of the Hierarchy Maintenance template. The view contains a check box for each available user and dimension combination. A check mark in the cell indicates that the user is permitted to modify the specified dimension.
While RPASCE can be configured to store any type of data, it is designed to be used with sales history, inventory, and other business-related information with low security requirements. It is not intended to be used with any sensitive data, such as personally identifiable information or credit card information. It does not have any mechanisms to protect this data, such as encryption, and therefore must not be used in this manner.
In order to be able to run and schedule administrative tasks in a cloud environment where the administrator has no access to the back-end servers, RPASCE Online Administration Tools provide an interface that allows authorized users to launch back-end processes from the RPASCE UI. It also provides a dashboard-like interface for the administrator to monitor the status of the tasks whose requests have been submitted.
