| 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 RPM 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:
Appendix 20 shows the physical deployment of RPM.
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 on the server and on the client (if required). Optionally 3rd party batch running infrastructure can be deployed to run batch scripts (for example, Appworx, and so on). The client workstation should be at the corporate data center. The client workstations need to run supported Java runtime.
WebLogic Application server executes server side of the application logic. Oracle Database provides data handling functionality. An LDAP server provides user attributes handling. Single Sign-On infrastructure provides capability to share authentication tokens across multiple retail applications. An FTP server provides delivery for incoming/outgoing files. Workstation Java runtime executes client side application logic.
RPM is exchanging data with other retail applications that are part of the Oracle Retail Suite, such as RMS, SIM, and POS.
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:
https://docs.oracle.com/middleware/1213/wls/wls-secure.htm
Contact your vendor for other components of security guides.
RPM relies on Java runtime on the client workstations to provide client side code execution.
RPM replies on WebLogic to provide authorization for accessing application services. Only authenticated authorized users should be allowed to access Enterprise JavaBeans (EJBs) and data sources installed as part of RPM installation on WebLogic servers. For more information, see the Authorization section.
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 authentication users should have access to RPM application. By the point of application authentication the user potentially successfully authenticates with the network and/or the workstation OS.
RPM supports the following two types of authentication:
Dedicated
Single Sign-On
Dedicated authentication - User credentials (username and password) are verified by WebLogic Authenticator. For information on registering an Authenticator with WebLogic, see the Oracle Retail Price Management Installation Guide. LDAP authenticator should be used where actual authentication data is provided by LDAP.
|
Note: Even though LDAP provides the data, the actual verification of provided credentials is done by WebLogic. |
If the WebLogic has been successfully verified the user 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 security.properties file. The following attributes (besides user identifier attribute) have to be defined for a user to be able to successfully authenticate with RPM:
ldap.firstname.attrname
ldap.lastname.attrname
The attributes listed are not actual attribute name, but rather logical name and should be mapped to actual attribute name within security.properties configuration file.
Dedicated authentication credentials are either provided by the application online user in real time (entering the user name and password on the RPM 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).
RPM supports the following two types of authorization:
Enterprise
Business
Enterprise authorization - This is performed by application server logic. WebLogic will make sure (if configured correctly - see the Oracle Retail Price Management Installation Guide for more information on required WebLogic configuration) that already authenticated user is the member of RPM user role/group (Role is created LDAP). Only the users who are members of RPM groups are allowed to get access to RPM functionality. All EJBs and data sources are accessible to RPM Secure User.
When the user submits a request to the server, the request (after authentication) is handled by a Controller EJB. This controller EJB will determine appropriate EJB to perform the action. When controller EJB will issue another request to Worker EJB, this request will be performed under RPM Secure User principal. Same discussion applies to accessing Data sources.
Business authorization - This is performed by Oracle Retail Security Management (RSM) logic. RSM is a part of RPM distribution. RMS will define what action each user role can perform and in what mode those action can be performed (allowed modes are Edit, View, None, Emergency). In addition to action security RSM provides ability to define data security. Data security allows system to associate appropriate level of location and merchandising hierarchy with a user role. Note that RSM operates on the user role level and not on the user level.
RPM does not provide extensive audit capabilities. Only price event tables carry the user information. The user information is relevant only as the creation identifier and does not guarantee that the final price event was completed by the same user who created the price event. Hence if auditing is required, it should be done at the database level. For information on how to turn on the database auditing, see the Oracle database documentation. The database auditing will be not be able to differentiate application users modifying data, as it is done at the database user level and all RPM application users share the same database user.
RPM does not store or maintain users. Instead RPM relies on LDAP to provide user management functionality on its behalf.
To create a new user to be used within RPM application, a new user should be created in LDAP; the user should be assigned to LDAP RPM role. Through backend the newly created user should be associated with a user role. If a new user role is required, it should be created through RSM screen first. It is recommended to create user roles with the minimum set of user privileges required for the user.
In order to remove the user from RPM, you need to first remove the user from the user group within RSM, then remove the user from a group in LDAP, and finally delete the user from LDAP.
This section covers securing the applications using encryption and hashing.
RPM uses encryptions as part of a security key generated on the server to deliver a client to the user workstation. To access RMS the user issues a requests to the server for Java Network Launch Protocol (JNLP) file. The server will generate temporary token based on the encryption method configured in the security.properties file.
user.signature.cipher.algorithm
By default HmacSHA1 is used, but the algorithm can be changed if required.
