| Oracle® Retail Merchandising Security Guide Release 15.0 E65442-01 |
|
 Previous |
 Next |
This chapter provides an overview of all the security features available in the ReIM application. It is provided as a reference for how the application securely communicates with other applications; how the application authenticates, authorizes, and audits users; and the encryption and hashing mechanisms used by the application.
The following topics are covered in this chapter:
Figure 15-1 shows the physical deployment of ReIM.
The Application Server is deployed on the corporate intranet on WebLogic cluster. The Application Server is connected to a cluster of Oracle databases and a corporate LDAP server or any other authentication provider. Optionally Single Sign-On infrastructure can be deployed. In addition, a secure FTP server is responsible for transferring files in/out of the application if EDI functionality is used. Optionally 3rd party batch running infrastructure can be deployed to run batch scripts (for example, Appworx, and so on). The client workstation can be either at the corporate data center or at the retailer locations (stores and warehouses). The client workstations need to run supported browsers with optionally printers attached. For file processing batches such as EDIInjector, the files should be on the network location accessible by the server.
The WebLogic Application Server executes the server side of the application logic. Oracle Database provides data handling functionality. A configured LDAP server can provide authentication or any other authentication provider can be used. Single Sign-On infrastructure provides capability to share authentication tokens across multiple retail applications. FTP server provides delivery for EDI files. Workstation browsers can be used to execute client side application logic. Printers can be used to create physical outbound documents when EDI functionality is not used.
ReIM exchanges data with other retail applications that are part of the Oracle Retail Suite, such as RMS, and with the applications that are not part of Oracle Retail Suite, such as Enterprise Business Suite (EBS) and PeopleSoft.
Each component of the deployment should be secured to provide minimum required access. This includes OS security, network security, browser security, LDAP security, WebLogic security, database Security, and FTP server security. For information on how to secure each component, see the reference documentation.
Security Guides for dependent applications are found at the following Web sites:
Oracle Database 12 C Release 1:
http://docs.oracle.com/database/121/TDPSG/E17609-19.pdf
Oracle WebLogic 12.1.3:
http://docs.oracle.com/middleware/1213/wls/INTRO/security.htm#INTRO232
Contact your vendor for other components of security guides.
SSL
The ReIM application should be deployed using a secure HTTP endpoint, but at the same ime regular HTTP can be used (not advised). Secure application should only be available through an "https:" URL. This requires the associated Oracle HTTP Server to be configured appropriately and to register the secure endpoint with the Single Sign-On Server. Configuration of the WebLogic hosting ReIM application should be secured as per WebLogic documentation.
Single Sign-On
In the standard supported deployment, ReIM leverages Single Sign-On infrastructure for authentication (optional). To avoid clear-text transmission of user IDs and passwords, Single Sign-On infrastructure must be configured to user TLS/SSL within all offered URLs. For specific information on configuring Single Sign-On to use TLS/SSL, see the WebLogic Single Sign-On Administrator's Guide.
WebLogic Wallet
The ReIM application relies on WebLogic Application Server to provide secure storage and retrieval for username and passwords required to communicate with other security conscious components or to run batches. WebLogic stores data securely in Credential Store, where a Wallet is one of the possible implementations. Credential Store stores access credentials for Web services access on the server and Secure Wallet implementation of Credential Store is used on the client to store batch user credentials.
The following section describes the authentication, authorization, audit, and user management.
The relevant security features fall into one or more of the following categories. For information on these categories, see the following sections:
Only authenticated users should have access to ReIM application. By the point of application authentication the user potentially successfully authenticates with the network and/or the workstation OS.
ReIM supports the following two types of authentication:
Dedicated
Single Sign-On
Dedicated authentication - User credentials (username and password) are submitted by the Application Server logic to the LDAP server or any other configured authentication provider If the authentication provider can successfully identify the user then such user is considered authenticated with ReIM application. Dedicated authentication credentials are either provided by the online application user in real time (entering user name and password on the ReIM provided login page) or are retrieved by the client from the Secure Wallet in the case of batch process. The batch user still needs to provide credentials alias, so that appropriate username and passwords are retrieved from the Secure Wallet.
Single Sign-On authentication - In case of Single Sign-On authentication happens only once per application suite. Authentication is performed by Single Sign-On infrastructure (potentially backed by the same LDAP server as the case for dedicated authentication). In this case login page is provided by the Single Sign-On infrastructure.
In both cases of authentication, the authentication is performed when it is determined that the session is not authenticated or the session has been invalidated (in case of dedicated authentication).
Only application users that belong to one of the ReIM user roles will be authorized to use functionality provided by the ReIM application. If the user is a valid enterprise user, login may be successful but authorization may prevent access to specific workflows based on the user's assigned role. Authorization is performed for each user driven operation. It is assumed that the batch user is assigned to the administrator role which is authorized to perform all operations.
Auditing can be performed at the application level and at the infrastructure level. The operating system (OS) can be configured to audit user access and processes invoked. The network layer can be configured to audit entire communication data set. The application server can be configured to audit access to the application, including all URL requested. The database can be configured to audit each table separately or entire session. The ReIM application also has some limited auditing capabilities.
The application will maintain some level of audit trail by keeping track of the last user modifying data and the date and time it was done, as well as version id of the data. See LAST_UPDATED_BY.
LAST_UPDATED_BY
LAST_UPDATE_DATE
CREATED_BY
CREATION_DATE
OBJECT_VERSION_ID
Additional audit can be performed by decreasing logging level of the application. In this case additional information is reported into logs. The drawback is that performance can suffer and that amount of log entries to be recorded will increase. You can selectively decrease logging (see Log4J and Java Logging documentation on logging configuration for more information). Also make sure that the log files generated by the application are secure and are accessible to authorized OS users only.
The ReIM application does not store or maintains users. Instead, ReIM relies on external systems such as LDAP to provide user management functionality on its behalf.
To create a new user to be used within the ReIM application, you need to create a new user in the LDAP or whatever data store the configured authentication provider relies on. To access ReIM workflows, the user should be assigned to a valid ReIM user role. If RMS data security is enabled, users must be added to the SEC_USER table and have REIM_USER_IND enabled. The user must also be mapped to a valid RMS security group in the SEC_USER_GROUP table.
|
Note: When removing a user, you must also delete the user entries from the RMS security tables. Failure to do this could result in inherited privileges. |
JPS encrypts data stored into the Secure Wallet. For more information on the default encryption algorithm used, see Credential Store Manager section in WebLogic documentation.
