Oracle Retail Merchandising

System

Security Overview White Paper

Release 16.0

January 2017
Note: The following is intended to outline our general
product direction. It is intended for information purposes
only, and may not be incorporated into any contract. It is not
a commitment to deliver any material, code, or functionality,
and should not be relied upon in making purchasing
decisions. The development, release, and timing of any
features or functionality described for Oracles products
remains at the sole discretion of Oracle.
 Contents
Contents............................................................................................................................. ii
1 Security Overview ........................................................................................................ 1
2 Application Level Security .......................................................................................... 3
Roles................................................................................................................................... 3
Duties and Privileges....................................................................................................... 4
Oracle Retail Application Administration Console .................................................... 5
3 Data level Security ....................................................................................................... 7
Configuring Data Level Security .......................................................................................... 7
Data Security Tables ........................................................................................................ 8
Other Notes..................................................................................................................... 10
Data Security Views ...................................................................................................... 10
Purchase Order Approval Limits ....................................................................................... 11
 1
Security Overview
This document provides an overview of the security functionality that is available as part
of the Oracle Retail Merchandising System (RMS).It will outline the security model that is
based on roles and allows flexibility for retailers to configure the application at the
screen, task, and data levels.
The security features of the application are as follows:
Authentication
This is the process of verifying the identity of a user. The authentication process
usually requires the user to provide a username and password or a combination
thereof, upon signing into an application. This is done based on a repository, such as
Lightweight Directory Access Protocol (LDAP) that holds the user data required for
authentication and authorization processes.
Role-Based Access/Authorization
This is the process of checking to see if an authenticated user has the privilege to
access specific system functionality. Within RMS, users are assigned to roles. The
logical grouping of duties within these roles provides different access rights to
specific functions within the various applications.
Data Authorization
This 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 merchandise or organization hierarchy.
These security tools for RMS should be effectively leveraged by the client based on the
respective business processes and the users who will be executing those processes within
RMS. This controls not just access to the system, but ensures that every employee is
systematically focused on the aspect of the client's business that they are responsible for.
Database level security is a feature of the Oracle database and will not be covered in the
scope of this document. For more information on securing the database for RMS, refer to
the Oracle Retail Merchandising Security Guide.

Security Overview 1
 2
Application Level Security
Application level security requires that the users are authenticated at the time of logging
into the application and it restricts them only to the resources for which they are
authorized. Based on the business role, the user's access could be restricted either to
entire areas of the system, purchase orders for example, or to the way that they can
access areas. For example, a user associated with a business role of Buyer may be able to
perform only the tasks associated to a Buyer profile such as, creating, modifying, and
approving purchase orders, deals, contracts, and so on. He might additionally have view
only access to return to vendor (RTV) screens, but not be able to create or modify an RTV.
On the other hand, an Inventory Analyst might have access to the set of tasks that are
linked with movement of goods within the application, such as creating, modifying, and
approving transfers, RTVs, and purchase orders.

Roles
The Oracle Retail Fusion security model is built upon the Oracle Fusion Middleware
platform leveraging the Oracle Platform Security Services (OPSS), which incorporates the
Java Access and Authorization Specifications (JAAS). Fusion security supports a role-
based, declarative model that employs container-managed security where resources are
protected by roles that are assigned to users. There is a generic database user configured

Application Level Security 3

Configuring Data Level Security

as the data source in the WebLogic application server. All the database interactions
triggered from the application screens are handled through this data source.
A default security configuration is available with RMS after installation and is configured
to use the Oracle Fusion Middleware security model. The default configuration includes
the eleven predefined security roles listed below for application-specific permission
grants:
Application Administrator
Data Steward
Buyer
Inventory Analyst
Inventory Manager
Corporate Inventory Control Analyst
Inventory Control Manger
Sourcing Analyst
Finance Analyst
Supply Chain Analyst
Finance Manager

This is intended to be a starting point for retailers to use as they define the roles that
make sense for their specific business and users. Each user is assigned to a role and then
the application roles are associated to a set of duties, which in turn are associated to a set
of privileges. In this manner, an application role becomes the container that grants
permissions to its members to access the RMS screens and the functionalities within it.

Duties and Privileges

Duties are intended to build on one another and work in a hierarchical manner. The
example in the table below illustrates how this works using purchase orders as an
example. The most basic purchase order duty is Purchase Order Inquiry, which grants
the user permission to search and view purchase orders. The next level of access is
Purchase Order Management, which grants the user the ability to search and view
purchase orders, but also maintain and submit them. The final level of access in this
example is Purchase Order Approval, which grants the user the ability to approve orders,
in addition to searching, viewing, and maintaining them.

Duty Privilege

Purchase Order Inquiry Search Purchase Orders

Purchase Order Management
Purchase Order Approval
View Purchase Orders
All Privileges in Purchase Order Inquiry
Maintain Purchase Orders
Submit Purchase Orders
All Privileges in Purchase Order Management
Approve Purchase Orders

The figure below is an example of how this is structured using two of the roles in the
default RMS configuration as an example. This diagram also highlights another feature of
the security configuration available in RMS, which is the ability to assign a user with

4 Oracle Retail Oracle Retail Merchandising System

 Configuring Data Level Security

maintain privileges to a screen that is accessed through another screen that they have
view only access to. In this example the Supply Chain Analyst role has access to view
items, but can maintain item supplier data, which is only accessed through the main Item
screen in RMS.

Role Supply Chain Analyst Data Steward

Item Item Item Item

Duty

Item Inquiry Supplier Supplier Item Inquiry Item Management Supplier Supplier
Inquiry Mgmt Inquiry Mgmt
Privilege

View Maintain View Maintain

Search View Search View Maintain Submit
Item Item Item Item
Items Items Items Items Items Items
Suppliers Suppliers Suppliers Suppliers

In RMS, role-based security is implemented to control:

Access to navigational links/tasks in the application. The role associated with the
user (for example a Buyer or Inventory Analyst) determines the set of links visible in
the task pane.
Access to various UI widgets in the screens like buttons, menu items, LOVs, Panels
and so on. The role determines if the UI widgets are to be shown or hidden and if
shown whether they need to be enabled or disabled.
How the screens will be opened, such as in an edit or view only mode based on the
role the user belongs to and the duties and privileges mapped to that role.
The individual dashboard reports that are displayed to a user, as well as which
dashboards they can access.
The actions that can be launched from the dashboard reports.

RMS also has two privileges that work a bit differently and are intended to help
configure the application by retail vertical. The first of these is called Use Diffs Priv. This
is meant to be assigned to roles that use differentiators for their items. For most fashion
or department store retailers, this would likely be associated to all roles. But, for other
businesses that may have a mix of fashion items and hardline items, this may only be
associated to certain roles in the organization. Users which have this privilege assigned
to them will have access to the Diff Matrix, Diff Distribution, Re-distribution by Diff, and
the Order, Transfer and Contract Parent/Diff Summary contextual reports. This privilege
also provides access to the differentiator container in the Item screen. Users without this
privilege will have these hidden from their view.
Another privilege that was added for users who work primarily in the Grocery retail
vertical is called Maintain/View Grocery Attributes Priv. Similar to the Use Diffs Priv, it
is intended show or hide grocery related attributes for items, such as the catch weight
indicator.

Oracle Retail Application Administration Console

Roles and duties can be created/modified/removed on the Oracle Retail Application
Administration Console (ORAAC) by appropriately mapping the RMS provided

Application Level Security 5

Configuring Data Level Security

privileges. These mappings should be created only after thorough analysis of the client
business processes and business user actions ensuring that it does not break the logical
screen navigation flows.
Please refer to the Retail Merchandising Security Guide for the complete list of pre-defined
RMS roles, duties, and privileges, as well as more details on creating users, roles and
duties.

6 Oracle Retail Oracle Retail Merchandising System

 3
Data level Security
Data-level security restricts user access to specific data sets within RMS. Retailers have
the ability to limit user data access both from a merchandise hierarchy perspective and
an organizational hierarchy perspective. For example, a buyer linked with the Garden
Tools department could have data level security put in place so that he or she has the
ability to access items only within that department. This helps filter the data presented to
the user to make it easier for them to do their job and to prevent access to information
that does not pertain to their job. This is achieved through the data security views that
are driven by the data set up in the RMS security tables.

Configuring Data Level Security

Data level security is configured by assigning users to a group. All users within a group
would have similar access to a particular section of the merchandise or organizational
hierarchy. For example, a group may be defined for a particular division, giving users
across roles access to the departments, classes, subclasses, and items in that division.
Additionally, certain attributes in RMS can be assigned to levels of the merchandise or
organizational hierarchy and also controlled by this functionality; it is user defined
attributes (UDAs), ticket types, seasons, diff groups, item lists, location lists, and location
traits. An example of how this might be used is to limit the list of diff groups or item lists
shown to users in a particular division or to users associated to a certain chain. The level
of each hierarchy that is used for this assignment is a set of system options. This makes
RMS a more configurable solution for large retailers who are implementing several
chains across multiple geographies within a single instance of RMS.
This level of security can be configured by the retailer in RMS by setting up appropriate
data into the following security tables:
SEC_USER
SEC_GROUP
SEC_USER_GROUP
FILTER_GROUP_MERCH
FILTER_GROUP_ORG
SEC_GROUP_LOC_MATRIX

Data level Security 7

Configuring Data Level Security

Data Security Tables

Security Groups (SEC_GROUP)

The SEC_GROUP table stores group attributes. The security groups allow users who
need to access a similar set of data to be grouped together. These security groups are
meant to define user groups with multiple job tasks that need to access the same
information. An example for this is the buying group, which may include the buyer, one
or more inventory analysts and data stewards, that would need access to the same
department or group of departments. Key attributes on this table are:
GROUP_ID - This contains the unique identifier associated with the security group.
GROUP_NAME - This contains the name of the security group.

Users (SEC_USER)
This table holds the application user ID, which is associated with a user when they log
into RMS. The data security function uses this application user ID for applying the
security policy. Key attributes 1 on this table are:
USER SEQ - This is a sequence-generated number that uniquely identifies a user.
APPLICATION USER ID 2 - This column holds the application user ID set up in the
enterprise Lightweight Directory Access Protocol (LDAP) for the user. The user ID
must be in all capital letters.

User Groups (SEC_USER_GROUP)

The SEC_USER_GROUP table links users defined above to the security groups defined
above. Key attributes on this table are:
GROUP ID - This contains the unique identifier associated with the security group as
defined in the SEC_GROUP table.

1
There are also indicators on this table that identify the application that the user is
associated with across other Merchandising applications outside of RMS, including Sales
Audit (ReSA), Invoice Matching (ReIM), and Allocation. These applications would use a
similar setup for data level security as is outlined in this document, with the exception of
Allocation which does not use this functionality at this time.
2
Although there is a database user ID on the table, this is not used in RMS as of version
16.0

8 Oracle Retail Oracle Retail Merchandising System

 Configuring Data Level Security

USER SEQ - This contains the security user assigned to the security group. It
references the user sequence defined on SEC_USER table.

Location Matrix (SEC_GROUP_ LOC_MATRIX)

The security groups can also be used to define the locations that a particular security
group can transfer to and from. This is intended primarily to be used with intercompany
transfers and control, which users can view or create/update transfers between legal
entities for a retailer, but could be used for other types of transfers as well. This is
managed using the SEC_GROUP_ LOC_MATRIX table.
This association determines locations the users will have access to and is also used to
determine the information that users have access to in RMS Search screens and in any of
the Item or Location related LOVs.
COLUMN_CODE this can be either Transfers From or Transfers To (based on the
code type ICTS on CODE_DETAIL).
GROUP ID - this contains the unique identifier associated with the security group as
defined in the SEC_GROUP table.
REGION indicates the region for which the group has access.
DISTRICT indicates the district for which the group has access.
STORE indicates the store for which the group has access.
WH indicates the warehouse for which the group has access; it can be either a
physical or virtual warehouse.
SELECT_IND indicates whether the user can view a transfer with a from or to
location (depending on the COLUMN_CODE) for the stores or warehouses
represented by this record.
UPDATE_IND indicates whether the user can create a transfer with a from or
to location (depending on the COLUMN_CODE) for the stores or warehouses
represented by this record.

Filter Based on Merchandise Hierarchy (FILTER_GROUP_MERCH)

The intersection between security user groups and merchandise hierarchy levels are
stored on the FILTER_GROUP_MERCH table. This association determines which
merchandise hierarchy levels the users will have access to.
SEC_GROUP_ID - This contains the unique identifier associated with the security
group as defined in the SEC_GROUP table.
FILTER_MERCH_LEVEL - This is the merchandise hierarchy level assigned to the
group. This can be a code representing a division (D), group (G), department (D),
class (C), or subclass (S).
FILTER_MERCH_ID - This is a division, group, or department included in the filter.
FILTER_MERCH_ID_CLASS - This is the class under the department which is
included in the filter.
FILTER_MERCH_ID_SUBCLASS - This is the subclass under the class which is
included in the filter.

Data level Security 9

Configuring Data Level Security

Filter Based on Organizational Hierarchy (FILTER_GROUP_ORG)

The intersection between the security user groups and organizational hierarchy level is
stored in the FILTER_GROUP_ORG table. This association determines which
organization hierarchy levels the users will have access to.
SEC_GROUP_ID - This contains the unique identifier associated with the security
group as defined in the SEC_GROUP table.
FILTER_ORG_LEVEL - This is the organization hierarchy level assigned to the User
Security Group. In addition to the organizational hierarchy levels, external finisher,
org unit and transfer entity can also be used here. The valid codes 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.

Other Notes
Data security is configured in RMS using the Data Loading function, which uses
spreadsheets to manage the upload and download of data into the RMS tables. See
the Foundation Data Loading Overview white paper for more details on this
functionality.
For a user to have access to any data, the LDAP user ID that is used to log in 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 merchandise hierarchies and the organization
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 merchandise hierarchies or all organization hierarchies,
respectively

Data Security Views

Restricting a users access to a subset of information has been implemented through the
data security views. These views have been incorporated into the Search screens and
item and location related LOVs.
This has been achieved through the add_filter_policy.sql script. This script associates a
dynamic predicate for the views listed below generated by PL/SQL functions, which is
associated with a security policy through a PL/SQL interface. This script adds a filter
policy to four main categories of data in RMS as described below:

10 Oracle Retail Oracle Retail Merchandising System

 Purchase Order Approval Limits

Filter Policy Category Security Views

Organizational Hierarchy V_CHAIN

V_AREA
V_REGION
V_DISTRICT
V_STORE
V_WH
V_ EXTERNAL_FINISHER
V_INTERNAL_FINISHER
V_TSF_ENTITY

Merchandise Hierarchy V_DIVISION,

V_GROUPS,
V_ DEPS,
V_CLASS,
V_SUBCLASS
V_ITEM_MASTER

Data Elements V_DIFF_GROUP_HEAD

V_LOC_LIST_ HEAD
V_LOC_TRAITS
V_SEASONS
V_SKULIST_HEAD
V_TICKET_ TYPE_HEAD
V_UDA
V_SUPS

Product Location V_TRANSFER_FROM_STORE

V_ TRANSFER_FROM_WH
V_TRANSFER_TO_STORE
V_TRANSFER_ TO_WH

Purchase Order Approval Limits

Another type of data related security that can be configured in RMS is related to order
approval. If a user has the privilege to approve a purchase order in RMS, the user can be
restricted to only approving an order up to a certain monetary amount, either in terms of
cost or retail 3. This limit is defined at the role level in RMS. Using the USER_SEQ as
defined on SEC_USER, a record must be added to the SEC_USER_ROLE table 4. Then, this

3
The determination of whether cost or retail is used is based on the system option setting
PROCUREMENT_UNIT_OPTIONS.ORD_APPR_AMT_CODE.
4
Information on this table can also be managed using spreadsheets and the Data Loading
function in RMS.

Data level Security 11

Purchase Order Approval Limits

role should be defined on the RTK_ROLE_PRIVS table. The ORD_APPR_AMT on

RTK_ROLE_PRIVS indicates the upper limit that the role is allowed to approve on an
order. If ORD_APPR_AMT is not defined, then the role can approve any order amount. If
a user is not assigned to a role on SEC_USER_ROLE, then it is assumed that they cannot
approve an order.

12 Oracle Retail Oracle Retail Merchandising System

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com

Copyright 2017, Oracle. All rights reserved.

All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is not warranted to
be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed either directly or indirectly by
this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written
permission.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of
SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered
trademark of The Open Group.