| Oracle® Retail Merchandising Security Guide Release 14.1.1 E61235-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:
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. Optionally Single Sign-On infrastructure can be deployed. In addition 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, Apworks, 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.
WebLogic Application Server executes server side of the application logic. Oracle Database provides data handling functionality. LDAP server provides authentication and user attributes handling. Single Sign-On infrastructure provides capability to share authentication tokens across multiple retail applications. FTP server provides delivery for EDI files. Workstation browsers 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 application that are a 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).
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 10.3:
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/security.html
Contact your vendor for other components of security guides.
SSL
The ReIM application should be deployed using a secure HTTP endpoint. It 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 Wallet is one of the possible implementations. Secure Wallet stores access credentials for database access, LDAP access, Web services access, and batch execution. ReIM application shares the wallet with WebLogic application, as WebLogic Application Server needs to store its own secure data in the wallet. ReIM will use separation partition for ReIM related credentials.
LDAP
The ReIM relies on LDAP for authentication logic. An LDAP server not only provides the storage for user data, but also serves as an authentication provider. Many LDAP implementations can define security policies that can define credential complexity, password history, unsuccessful login attempt count, and so on.
|
Note: Any valid ReIM user should be able to log in to LDAP. As such ReIM users should have read-only LDAP access. |
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. If the user can successfully log in to LDAP server with provided credentials then the user has passed the first step of authentication. For the authentication to complete successfully the user should also have all the mandatory attributes defined within LDAP entity. If some mandatory attributes are missing then the authentication process will fail.
All LDAP attribute mappings are defined in the ldap.properties file. The following attributes have to be defined for a user to be able to successfully authenticate with ReIM:
user_first_name_attribute_name
user_last_name_attribute_name
user_email_attribute_name
user_password_attribute_name
user_language_attribute_name
user_country_attribute_name
user_main_key
The attributes listed are not actual attribute names, but rather logical names and should be mapped to actual attribute names within ldap.properties configuration file.
Dedicated authentication credentials are either provided by the application online user in real time (entering user name and password on the ReIM provided login page) or are retrieved by the Application Server 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. The second step of authentication is exactly the same as in dedicated authentication - mandatory user attributes should be present in LDAP server.
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).
ReIM supports the following two types of authorization:
Enterprise
Business
Enterprise authorization is performed by Application Server logic with the data provided by LDAP server. Only application users that belong to a dedicated ReIM user role/group are authorized for ReIM. So if two users exist in LDAP and both can successfully log in to LDAP server, but only one is a member of ReIM group/role then only such ReIM user can be authorized for ReIM. Enterprise authorization is Yes/No kind and does not provide granular access control.
Business authorization on the other hand is performed by the Application Server logic based on the data in the database. This authorization is performed at the user group level. Each authenticated user should be a member of a valid ReIM user group (defined in the database). The authorization is done against the set of privileges defined for the user group. Only the user whose user group allows to perform the desired operation would be authorized to proceed. If a user is a valid user and is a member of a ReIM group in LDAP but does not belong to any valid user group in database then such a user will not be authorized into ReIM application.
ReIM authorization is performed for each user driven operation. Business authorization is not performed for batch processes, as it is assumed that the batch user is authorized to perform all operations.
This can be performed at the application level and at the infrastructure level. Operating System (OS) can be configured to audit user access and processes invoked. Network layer can be configured to audit entire communication data set. Application Server can be configured to audit access to the application, including all URL requested. Database can be configured to audit each table separately or entire session. ReIM application has some limited auditing capabilities. Besides operational tables ReIM has audit tables that hold data that may be required for audit purposes. The audit tables are as follows:
IM_EDIRJT_DOCDTL_ALW_AUDIT
IM_EDI_RJT_DOC_DTL_AUDIT
IM_EDI_RJT_DOC_HEAD_AUDIT
IM_EDI_RJT_DOC_NM_AUDIT
IM_ITEM_TAX_AUDIT
IM_ITEM_VAT_AUDIT
IM_ORDER_ITEM_TAX_AUDIT
IM_TOLERANCE_DEPT_AUDIT
IM_TOLERANCE_SUPP_AUDIT
IM_TOLERANCE_SUTRT_AUDIT
IM_TOLERANCE_SYS_AUDIT
|
Note: For database audit the result will not identify the application user who performed the operation, but rather the database user. In case of ReIM all application users share the same database user. |
ReIM audit data is stored in AUDIT tables. The application does not provide read access for the table. The tables are intended to be inspected through other means. Other kind of audit data access control is provided by the auditing component.
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 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 does not store or maintains users. Instead ReIM relies on external LDAP user management applications to provide user management functionality on its behalf.
To create a new user to be used within ReIM application, you need to create a new user in LDAP; the user should be assigned to the 'ReIM' role within the LDAP. A new ReIM user must also be added to an ReIM group defined in the ReIM database. This is done through the User Group Maintenance screen. Only the user who is a member of a group that allows adding user to groups can add a new user to a group. The user adding a new user to group is not required to be member of the group where the new user is being added to.
In order to remove the user from ReIM, you need to first remove the user from a user group within ReIM, then remove the user from a group in LDAP, and finally delete the user from LDAP.
ReIM uses a cryptographically strong pseudo-random number generator algorithm to generate Cross Site Request Forgery (CSRF) token. On Windows platform SHA1PRNG is used by default and Secure Random Number (SUN) is used as strong pseudo-random number generator provider. This gives 160-bit seed. On other platforms different algorithms and providers can be used. The configuration is done in Owasp.CsrfGuard.properties.
org.owasp.csrfguard.PRNG
org.owasp.csrfguard.PRNG.Provider
Also 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.
