| Oracle® Retail Merchandising Security Guide Release 14.1.1 E61235-01 |
|
 Previous |
 Next |
This chapter provides information about application administrative tasks related to security. How to manage users and roles as well as some other common application administrative tasks such as secure credential management and logging are discussed.
This chapter discusses post installing the application administration.
The following topics are covered in this chapter:
RPM uses the following two kinds of user roles:
Enterprise
Business
There should be only a single enterprise user role created and it is defaulted to rpm_secure_users. This role is created in LDAP by the system administrator. Any LDAP user that should be considered for RPM processing should be made a member of this role. RPM makes an assumption that LDAP implementation will have groups that keep track of its member and the users will not be aware about their group membership. It implies that there will be a reference maintained by the user group to the user group member by means of a static member DN attribute. For example if this attribute is uniqueMember, then uniqueMember attribute will point to the group member. The user, on the other hand does not have any attributes pointing to the rpm_secure_users group. RPM does not provide any LDIF scripts to create the rpm_secure_users role.
If the data seeding script has been run, then the script would create a single business user role - Administrator Role. If the script has not been run, then no user roles exist by default and the retailer is responsible for creating the groups manually by inserting data into appropriate table (demo data script can be used as a starting point). The role Administrator Role, as the name suggests, has the highest level of privileges. The name of the group is completely arbitrary. Retailers can create as many additional roles as they require. The best approach when creating a user role is to define it based on the set of task the role members are supposed to perform and assign only the minimum required set of privileges to that group. For example, an employee can be part of a group which only allows the submission of price events and does not allow direct approval. This allows users with approval privileges the chance to review submitted price events and decide whether or not to approve them.
Despite it being the only role created by the data seed script, try to avoid assigning all users to Administrator Role. This will grant all users more privileges than is likely required. Create user roles that best fit the user's requirements and assign them only the privileges they require.
It is recommended to create the Administrator Role and an Admin user through a script and then to use Application logic (RSM Role Administration Screen) to maintain user roles.
The application logic allows the following actions:
Create/delete/update an user group
Assign/remove users to/from a role
Define a role's workflow permissions
Assign Location Hierarchy to the role
Assign Merchandise Hierarchy to the role
You cannot delete a user role from the UI, however it is possible to remove all the privileges from the role effectively eliminating it.
As a part of the operational workflow, RPM needs to have credential information to authenticate application users or to authenticate application itself with other dependent components such as database, LDAP or Oracle Retail Integration Bus (RIB). For the case of remote users connecting to RPM servers through RMI credentials are retrieved in real time through client provided form. For all other cases the credentials are determined at installation and are stored in Secure Wallet by means of Credential Store Manager Component. At runtime the credentials are retrieved from the wallet and supplied to the component for authentication. The credentials can be updated if required. As part of installation RPM provides convenience scripts that allow credential entries to be updated. The scripts allow the system administrator to see usernames stored in RPM wallet partition and to change the password if necessary. The script does not display original passwords. For more information, see the Operations Guide.
There are two set of logs that are generated by RPM application - infrastructure logs and actual Application logs. Infrastructure logs are configured and maintained by appropriate tools for infrastructure component. An example of infrastructure log would be WebLogic application server various logs. The logging level and other logging parameters can be adjusted through WebLogic component. Such logs are owned by the OS user that own WebLogic process. WebLogic log files are located within WebLogic directory structure. Application logs are generated by RPM application logic. RPM log configuration is done through RPM log configuration file (on the client and on the server). The administrator has the rights to configure the location of the RPM log files. RPM log files are also owned by the OS user that own WebLogic process (on the server) and OS user running client Java runtime (on the client workstation). It is recommended to grant access to log files only to the administrators.
RPM application does not restrict concurrent sessions from the same user. It means that more than a single user can log in to RPM server with the same credentials. There will be more than one session from application standpoint, but there will be the same user from database standpoint of view. It is recommended not to use the same credentials for different sessions.
Session timeout is defined at the application server level. It is 60 minutes by default, but can be changed through WebLogic configuration.
