1. Security Guide
  2. AI Foundation Security Features

4 AI Foundation Security Features

Technology-Specific Security Features

Oracle Retail AI Foundation Cloud Services uses several common technologies and services and provides specific security features as described below.

Web Services

The web services in Oracle Retail AI Foundation Cloud Services are stateless, so state is not stored or managed. Pagination such as the batch size of data and parameters such as export data time, product, location, and so on are used to manage payload size and to handle session timeouts only.

SOAP

Oracle Retail AI Foundation Cloud Services has an Outbound Interface to push Customer Segment and its members to Oracle Retail Customer Engagement (ORCE). This interface supports the following security features:

  • Message authentication is enabled in ORCE, and the Oracle Retail AI Foundation Cloud Services message includes authentication information in the HTTP header for the message. This authentication information is specific to ORCE and is stored in the Credential Stores. The Credential Stores are created or updated from the Data Management task, which is enabled for an Administrator. The Base64 encoding tool is used to encode the authorization key that is sent as part of the Message HTTP Header request. The Credential Stores use APIs that applications can use to create, read, update, and manage credentials securely and mark code as being "privileged", thus affecting subsequent access determinations.

  • Oracle Retail AI Foundation Cloud Services provides configuration to set up proxy settings for both HTTP and HTTPS.

  • XML sent as part of the message relies on marshalling and un-marshalling to and from Java Objects generated using the WSDL/Schema exposed through ORCE. This ensure that the XML generated is well formed and valid. It is the responsibility of ORCE to convert XML; Oracle Retail AI Foundation Cloud Services does not perform any XML Conversion. There are no concerns regarding XXE and XEE.

REST

Oracle Retail AI Foundation Cloud Services has an Outbound Interface to export data (GET request), and it uses REST to expose data. These web services are REST-based; it is assumed that callers are familiar with the basic REST principles (such as the usage of HTTP verbs). AC and ASO export web services can serve as a means of obtaining incremental update data from a specified point in time. All services support the query parameter contentType and the HTTP header Content-Type, with supported values application/json and application/xml. The query parameter takes precedence; if no content type is supplied, then application/json serves as the default. Basic authentication is used, so you may use any client software that supports it. Authorization is done for ADF-LDAP (OID) mapped roles, and only administrator roles are used (that is, the calling user must be in a duty that is mapped to the defined administrator roles). JSON/XML parsing is done using standard JAXB request parameters that are validated before data is fetched.

ORDS

The following three security features are provided:

  • Single Sign On (SSO) - AIF integration with ORDS supports SSO, using ORDS-provided authentication schemes called the HTTP Header Variable. User credential verification is performed by OCI IAM, which passes the user's name to Oracle Application Express using an HTTP header variable such as IDCS REMOTE_USER. While setting up the scheme in ORDS, the logout URL is also configured by Oracle.

  • Schema used in the ORDS Workspace - AIF integration with ORDS includes defining a new schema called Retail Workspace Schema (RTLWSP01) in the ORDS workspace. This is provided to the retailer, and in turn is associated with the AIF product schema. The retailer may not create other workspaces; they are expected to use only the provided one in conjunction with AI Foundation applications.

  • Declarative REST API – AIF integration with ORDS also provides the retailer with a declarative way to create new service endpoints in the system. Access to such endpoints are enabled through oAuth2.0. This REST API request is authorized using the OCI IAM client credential grants type, where the retailer requests an access code from OCI IAM and passes the token in subsequent calls to access data.

Authentication and Authorization

For authorization, Oracle Retail AI Foundation Cloud Services modules have been built with role-based access. Access to application user interface components is done by assigning application roles. Application roles are defined as part of the application and deployed as part of the installation process. Application roles are mapped to enterprise roles during the initial environment provisioning. For Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) users, the enterprise roles are available from the user interface and are managed in the same way as other security groups. Refer to the Retail Identity Management Startup Guide for OCI IAM for details on all available enterprise roles for each AIF application and module.

Analytics Client Security

The Oracle Analytics Server (OAS) client used for BI reporting and data analysis has additional client-side security measures, mainly for the Retail Insights (RI) application usage.

Authentication for OAS is automatically sourced from OCI IAM; however, the application also uses authorization roles, which are defined within the products themselves (such as Retail Insights). These application roles are linked to OCI IAM user groups, but do not share the same naming structure. For example, the OCI IAM group swef98w4f4nf009-SalesInsights_JOB appears simply as the “Sales Insights” group within OAS. The relationship between OCI IAM groups and OAS application roles is covered in more detail in the Identity Management for OCI IAM Startup Guide.

OAS also provides object-level security within the application UI. Example objects are reports, datasets, dashboards, and connections. Object-level security is managed from the OAS user interface by right-clicking an object and inspecting it for access and sharing permissions. More details can be found in the Oracle Analytics Server User Guides.

Retail Insights includes metadata security in OAS, which restricts the metrics and attributes a user has access to based on their OCI IAM group assignments. For example, the Sales folder of metrics is not available to all users; it requires one of a set list of OCI IAM groups to be assigned first. The mapping between application roles and metadata objects is provided in the Metrics and Attributes Catalog (MAC) document in My Oracle Support (Doc ID 2539848.1).

Hierarchy Position Security

In the Retail Insights (RI) and AI Foundation (AIF) applications, position-level security is managed using database tables and associated flat file loads. Unlike RPAS application position security, the data provided through this process is more like data filtering; it is not a guaranteed limit to the user’s access in all cases. The data-level security mapping is provided though interface files: RAF_SEC_USER.dat, RAF_SEC_GROUP.dat, RAF_SEC_USER_GROUP.dat, RAF_FILTER_GROUP_MERCH.dat, and RAF_FILTER_GROUP_ORG.dat. If you are accessing the tables from APEX, then the table name is the same as the filename without the extension (such as RAF_SEC_USER). The security tables exist in multiple database schemas, so specify the application user when querying or writing to the tables (RADM01 or RASE01 user schemas for RI and AIF, respectively).

  • RAF_SEC_USER.dat contains the USER_ID (LDAP ID) for any user who has data access limits defined

  • RAF_SEC_GROUP.dat contains the GROUP_ID to group together multiple sets of users having the same access levels.

  • RAF_SEC_USER_GROUP.dat contains the mapping between USER_ID and GROUP_ID. Individual users are not assigned data permissions, it is done with security groups.

  • RAF_FILTER_GROUP_MERCH.dat contains the access mapping between any merchandise hierarchy level, Merch ID on that level, and the GROUP IDs. This mapping defines what the group is allowed to access. Anything not included is restricted.

  • RAF_FILTER_GROUP_ORG.dat contains the access mapping between Organization hierarchy level, Org ID on that level, and the GROUP IDs. This mapping defines what the group is allowed to access. Anything not included is restricted.

If a user is not mapped into any of these files, then they have full access to the data in RI and AIF applications. If a user runs a report in RI that is above the security level (such as a Division level report when the security settings are at Department level) then they will get all data from the database returned without restriction, as it is not possible to filter the report at levels above the security level. The data filtering does not apply to custom datasets built using DV, nor does it apply to queries run in Innovation Workbench. You are expected to limit the user’s access to these tools if you do not want them to have unrestricted data access.

If you do not wish to use the files and want to populate the data from APEX instead, separate functionality is provided to do so. Refer to the “Extensibility” chapter of the RAP Implementation Guide for more details.