| Oracle® Retail Merchandising Security Guide Release 16.0 E76966-03 |
|
 Previous |
 Next |
This chapter covers the technical overview of the authentication process used for RMS, Oracle Retail Trade Management (RTM) using Oracle Access manager and Single Sign-On.
Further, it details the security considerations and implementations that are part of the Database, Data level security, as well as the Application layer.
The following topics are covered in this chapter:
|
Note: RTM share the same database as that of RMS. The Security features that are applicable to RMS are applicable to RTM as well. |
The security features of the Application are as follows:
Access Control - It is the process of restricting access to a particular entity based upon a broad range of criteria that may or may not include the attributes related to a particular user.
Authentication - It is the process of verifying the identity of a user. The authentication process usually requires a user to provide a user name and password or a combination thereof, upon signing into an application.
Authorization - It is the process of checking to see if an authenticated user has the privilege to access particular system functionality.
Data Authorization - It is the process of determining an authenticated user's rights to act upon a particular set of data. This process typically checks if the authenticated user is linked to a certain level in the organization hierarchy and/or a certain level in the merchandise hierarchy.
Role-Based Access - Within the Oracle Retail's systems, users are assigned to different roles. The role logical grouping has different access rights to specific functions within the various Oracle Retail Systems.
User Store - It is a repository that holds user data required for authentication and authorization processes.
In order to ensure users are limited to parts of the application and information that is relevant to their business role, RMS has a three-tier security structure.
The three levels of security offered by RMS are as follows:
Database-level security - This is a built in feature of Oracle Database, based on database roles.
Application-level security - This is the screen-level security based on Application User roles.
Data-level security - This is built into RMS to give a client the ability to further limit user access to information.
The Application-level security requires the users to authenticate at login and restricts them to resources only for which they are authorized.
The user's access to either entire areas of the system (for example, Purchase Orders) the modes in which users can access areas (for example, viewing Purchase Orders only) will be restricted through this.
The users are associated to groups that are mapped to application roles.The application specific permissions are granted to these security roles. For more information on the security roles, see Table 11-1.
Data-level security restricts user access to specific data within the merchandising system. The client has the ability to limit user data access both from a merchandise hierarchy perspective and organizational hierarchy perspective. For example, a buyer for the Small Appliances department could have data level security put in place so that they only have the ability to access items within the Small Appliances department. This prevents users from accessing information that does not pertain to their job.
Unlike the other layers of security, this level of security can be configured by the client in the RMS through the Data Upload utility available in the Application.
Data level security is defined at the group level in RMS.
For a user to have access to any data, the LDAP user ID used to login to the RMS application must be defined in the SEC_USER table as an 'APPLICATION_USER_ID'.
The user must be assigned to a security group in SEC_USER_GROUP. This is done through associating the USER_SEQ on SEC_USER assigned to the APPLICATION_USER_ID with a GROUP_ID on SEC_GROUP.
The security group can only access the merch hierarchies and the org hierarchies assigned to the user in FILTER_GROUP_MERCH and FILTER_GROUP_ORG respectively.
If a security group is NOT assigned to any data in FILTER_GROUP_MERCH or FILTER_GROUP_ORG, users in this group are considered 'super users' and will have access to all merch hierarchies or all org hierarchies respectively
Security groups are powerful tools for data authorization in RMS; however, they require significant administration. Security groups are defined on RMS tables, so it is possible that the information can be interfaced onto these tables from an external system aware of the merchandise and organizational hierarchies.
The item/location security in RMS is based on relationships defined between groups of users and merchandise and organizational data.
The Security groups are defined on the SEC_GROUP table. These security groups are meant to define users with many job tasks who need to access the same information.
The SEC_GROUP table stores group attributes. The Security groups allow users who need similar data to be grouped together.
GROUP_ID - This contains the unique identifier associated with the security group.
GROUP_NAME - This contains the name of the security group.
ROLE - This contains the role that a client wants to assign to this group. This field is referenced in the code type ROLE. There are no pre-defined values for this field and it is completely user-defined. This field does not have any functionality linking it to Oracle Roles or any other type of roles used within the RMS. This field is used within the regionality dialog for searching and reporting.
The Security groups are defined in the RMS user interface. Users are added as members of a group by associations on the SEC_USER_GROUP table.
The SEC_USER_GROUP table link users.
The security groups are as follows:
GROUP ID - This contains the unique identifier associated with the security group as defined in the SEC_GROUP table.
USER SEQ - This contains the security user assigned to the security group. It references the user sequence defined on SEC_USER table.
This table holds the database user ID and the application user ID associated with a security user.
The application user ID is copied to database session context RETAIL_CTX. APP_USER_ID. The RMS security table SEC_USER now also holds application user ID in addition to database user ID. The data security function uses the application user ID for applying the security policy if database session context RETAIL_CTX. APP_USER_ID is available else, it uses the logged in database ID for applying security policy.
The security groups are as follows:
DATABASE USER ID - This column holds the database user login ID assigned to the security user.
USER SEQ - This is a sequence generated number that uniquely identifies a security user.
APPLICATION USER ID - This column holds the application user ID set up in enterprise LDAP for the security user.
The security groups can be associated with specific locations using the SEC_GROUP_LOC_MATRIX tables.
The security group information is also used to determine the information that users have access to in RMS Search screens and LOVs/field validation. If a user is associated with a security group that has access to a limited range of items and the user searches in the item Search screen , the search will only return results that are in the items the user has access to. If the same user enters an item number in an item field, validation will ensure that the user has access to this item. Any item LOV will also display only the user 's list of items.
The intersection between security user groups and merchandise hierarchy levels are stored on the FILTER_GROUP_MERCH table.
SEC_GROUP_ID - This is the ID of the User Security group as defined on the SEC_GROUP table.
FILTER_MERCH_LEVEL - This is the merchandise hierarchy level assigned to the User Security Group. This can be a code representing group, department, class, or subclass.
FILTER_MERCH_ID - This is a group or department included in the filtering.
FILTER_MERCH_ID_CLASS - This is the class under the department which is included in the filtering.
FILTER_MERCH_ID_SUBCLASS - This is the subclass under the class which is included in the filtering.
The intersection between security user groups and organizational hierarchy level is stored in FILTER_GROUP_ORG table.
SEC_GROUP_ID - This is the ID of the User Security group as defined on the SEC_GROUP table.
FILTER_ORG_LEVEL - This is the Organization hierarchy level assigned to the User Security Group. The valid values are contained in the CODE_DETAIL table with a CODE_TYPE of FLOW.
FILTER_ORG_ID - This is the ID of the Organization hierarchy level assigned to the User Security Group.
RMS includes two install scripts that sets up some of this security information. The install script superGroup.sql creates a security group that must not to be associated with any level of the merchandise or organizational hierarchy. Members of this group will have access to all data in the Application. The install script superUser.sql associates the user running the script with the superUser group, and therefore ensures that the user running the script will have access to all data in the system.
You need to create user roles within RMS and provide users with a mechanism for accessing the system. When security is leveraged, it controls a user's access to individual application functions and data sets.
Users in RMS are set up by the database administrator using a user creation script.
The Database Roles are created in RMS. Object level privileges are assigned to the roles that are created. Then business users are created and assigned these roles, hence allowing users to have access to objects for all the roles that are assigned to them.
A sample script is packaged with the product which contains privileges for the following:
DELETE tables
EXECUTE type, procedure, package, and function
INSERT into tables and views
SELECT sequence, table, view, and materialized view (except four ReSA tables
SA_TRAN_TENDER_REV, SA_BANK_ACH, SA_TRAN_TENDER,
SA_BANK_STORE)
UPDATE table (except four ReSA tables SA_TRAN_TENDER_REV,
SA_BANK_ACH, SA_TRAN_TENDER, SA_BANK_STORE)
|
Note:
|
Each RMS database user has synonyms to the master RMS schema and is able to update and modify data within that schema, and cannot change the structure of the tables and objects. This user structure is specific to RMS and RTM. Applications such as RPM, Allocation, and ReIM use other means to manage users. User management for each application is discussed within its respective section.
When all of the security tools for RMS are effectively leveraged by a client a user can become a powerful tool to not only grant access to a system, but to ensure that every employee is systematically focused on the aspect of the client's business that they are responsible for.
Encryption and hashing techniques are a part of Oracle Advanced Security, hence System and Database Administrators are recommended to refer Oracle Database Advanced Security Administrator's Guide 12 C Release 1 for more details.
The details of encryption and hashing are as follows:
ORDCUST and SVC_FULFILORDCUST tables are in encrypted tablespace as it stores sensitive information about the customers.
RETAIL_SERVICE_REPORT_URL table is used to hold the retail service code, retail service name, and URL for the Web services for Oracle Retail Financial Integration (RFI). The column sys_account is an encrypted column which stores the system account name.
The function that perform encryption/decryption are further maintained as wrapped PLSQL functions.
For more information on Merch Mobile Security Consideration, see Functional Security for Applications Using Fusion Middleware chapter.
For more information on ReST Services Security Consideration, see the Applications Operations Guide.
The Order Approval amount which determines the upper limit a user can approve on an order can be restricted through the application user roles.
If a user has the privilege to approve a purchase order in RMS, the user can only approve an order up to a certain monetary amount. This limit is defined at the role level in RMS
For a user to approve any order amount, the LDAP user id used to login to the RMS application (e.g. RMS_ADMIN) must be defined in the SEC_USER table as an ’APPLICATION_USER_ID'.
The USER_SEQ on SEC_USER associated with the APPLICATION_USER_ID must be assigned to a security ROLE in the SEC_USER_ROLE table.
The security ROLE must be defined on the RTK_ROLE_PRIVS table. ORD_APPR_AMT on RTK_ROLE_PRIVS indicates the upper limit that the role is allowed to approve on an order. ORD_APPR_AMT is an optional field. If not defined, then the role can approve any order amount.
|
Note: To avoid errors, make sure you have set up the Purchase Order Approver permissions to access the Buyer Dashboard. |
