| Oracle® Retail Predictive Application Server and Applications Cloud Edition Security Guide Release 19.0 F25911-13 |
|
 Previous |
 Next |
| Oracle® Retail Predictive Application Server and Applications Cloud Edition Security Guide Release 19.0 F25911-13 |
|
Previous |
Next |
This chapter contains information on security activities carried out in the Compute Tier.
RPASCE allows administrators to assign users into distinct groups. A group is similar to a traditional database role in that it allows the administrator to configure authorization settings for several users at once. The main difference, however, is that user and group have a hierarchical relationship, where settings are always stored at the user level and group is a rollup of user. 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.
The group that a user rolls up to is referred to as the primary group. A user can also be associated with other groups using the Other Groups property. The Other Groups property is not used for authorization purposes, but instead allows a user to save workbooks and formatting in a way that it is visible to users whose primary group is one of those Other Groups. This behavior is typically used by people who need to support other users rather than an end-user (for example, a team whose job is to set up the formatting for all of the other project groups).
When a user is added, 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. The frequent adding and dropping of users and groups can eventually exhaust the list of available positions in these dimensions and will require the reindexing of these dimensions.
Additionally, when a user is added, a directory is created for the user in the /users directory of the domain root. In global domains, this directory is created in the master and in all subdomains. This directory serves as a workbook repository, as well as a cache for some metadata such as MRU lists. When a user is deleted, these directories, as well as any workbooks created by that user, will be deleted with the user.
User accounts can be marked as locked by the domain administrator. This prevents the user from logging on with the RPASCE Client. The account remains locked until the administrator re-enables the account. The domain administrator can set or clear account lockouts by using the User Management utility or the Edit User workbook.
A number of roles are created within IDCS or 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 IDCS or 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 IDCS or 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 and are detailed further in the Atomic User Management section of this document.
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 IDCS or 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
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.
Measures have access rights; these are read-write, read-only, or denied. Measures that are read-write or read-only may be selected in the extra measures and insert measure dialogs. RPASCE ensures that read-only measures are not editable by the user and the presence of read-only measures does not affect the ability to commit a workbook.
Measure security can be specified and changed through the Security Administration workbook. The Measure Rights view allows Read Only, Deny, or Read/Write access to a measure to be specified for each user.
A workbook template can override the security of a measure, but it can only narrow the security of that measure. For example, a measure can have read-write access for a user and a template can specify that all users have read-only access to the measure when a workbook is built. However, if the measure security is read-only, the template cannot expand the security of that measure to read-write. Measures that are explicitly made read-only by a workbook template are not expanded to read-write access by RPASCE.
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 domain 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 (dimensions) at or above base (such as class in the product hierarchy) in any hierarchy other than calendar. As positions are added at a level/dimension lower in the hierarchy than where the position level security is maintained, access to those positions is automatically granted if a user has access to the parent position. In other words, 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 dimension in each hierarchy can be defined as the security dimension for the hierarchy. If a security dimension is defined for the hierarchy, all dimensions in the hierarchy have position level security enabled, but position security is set at or above the designated dimension. For instance, if the class dimension is designated as the security dimension, an administrator can maintain access to positions in the class dimension or at any level above class.
The enabling of position level security as well as the specification of the dimension at which position level security will be maintained are managed within the configuration used to define the domain. The RPASCE Configuration Tools provide the ability to do this configuration within the Hierarchy Definition Tool.
Additionally, position level security can be enabled on a domain by using the hierarchyMgr utility. This utility allows the specification of the security dimension without requiring modifications to the domain's configuration and the application of a domain content patch through the rpasInstall process. For more information on the use of the hierarchyMgr utility, consult the RPASCE Online Administration Guide.
After a security dimension is defined for a hierarchy, all users in the domain default to having access to all positions in any dimension in the hierarchy. Additionally, users automatically have access to newly added positions to a domain.
The Security Administration workbook is 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 hierarchy with a defined security dimension. 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 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, Denied = false and Granted = true. Based on the combination of settings, a user is either granted or denied access.
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.
Note that position-level security, when used for a global domain environment on the same dimension on which it is partitioned, is used to guide a user to the domain or domains that the user has access to. If a user only has access to positions within a single local domain, that user will be guided there on New Workbook. If a user has access to more than one, that user will be asked and can choose based on partition-level positions.
Similarly, Open by default only lists workbooks from those domains, and a user is only shown alert counts from those domains.
Atomic User Management (AUM)provides an alternative method for managing users, user groups, and user permissions. The goal of atomic user management is to streamline the process of setting up and managing user rights by moving to a role-based security model in which permissions are defined at the user group level and users are allowed or denied access as a result of the user groups to which they belong. This is done to simplify user rights management but does not alter the set of permissions or how they are enforced within the application.
Under the AUM model, RPASCE administrative users create RPASCE user groups that are named identically to the user roles defined in IDCS or OCI IAM that correspond to roles within the RPASCE application. They then set the access rights for the workbook template and the measures that will apply to all members of that group. RPASCE users can then be assigned the IDCS or OCI IAM role and, when accessing the application, be granted the rights defined for their groups automatically without the need to create those users and set their rights explicitly through the RPASCE administrative templates.
Note that AUM does not affect the process of position security. Position security is, in most cases, orthogonal to role-based security in that all users in a given role will have the same set of accessible templates and actions but each will have access to a different set of positions. Therefore, neither the mechanisms used to set up and maintain position level security nor the ways in which position level security are enforced change under the atomic user management model.
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.
Application Authorization Role
In order for users authenticated by IDCS or 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.
Application Administrative Role
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.
As users enter the IDCS or 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 IDCS or 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 IDCS or 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 IDCS or OCI IAM or, if appropriate, the user can be dropped from IDCS or 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 IDCS or OCI IAM utility will query IDCS or 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 IDCS or 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.
This section specifies how to set resource limits.
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 complete 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 domain by all users of that domain. The limit is set at the domain level. In a global domain environment, the same limit is applied individually to each local domain and the master domain.
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 domain 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. In a global domain environment, the same limit is applied individually to each local domain and the master domain.
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.
Information on how to set these limits can be found in RPASCE Online Administration Guide.
The Dimension Modification Rights view allows the administrator to determine which user defined dimensions, if any, a user can modify by using the Hierarchy Maintenance Workbook. 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 user defined dimension. A check mark on the regular dimension has no affect. After changes are made to a user's dimension modification rights, they must be committed before they take effect.
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.
Since the Administrator can launch processes in the back-end, albeit in a limited fashion, proper RPASCE server configuration is required to mitigate any security risks.
By default, any RPAS administrative users have access to all RPASCE Administration Tools templates. In order to limit access to those sensitive templates, template security for RPASCE administrative users can be enabled in the domain
All administrative tasks have a dedicated directory under the tasks folder of the domain. This directory contains the configuration, scheduling, and logging information of the task and can be used for auditing purpose. After a task is completed, its audit log is available through the Online Administration Dashboard. The number of successful or failed tasks whose logs are available through the dashboard is controlled by two domain properties:
task_failed_limit: the number of failed tasks to be retained.
task_success_limit: the number of successful tasks to be retained
