| 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.
The following topics are covered in this chapter:
ReIM 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 ReIM. This role is created in LDAP by the system administrator. Any LDAP user that should be considered for ReIM processing should be made a member of this role. ReIM 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 role_member mapped attribute. For example if role_member attribute is mapped to uniqueMember, then uniqueMember attribute will point to the group member. The user, on the other hand does not have any attributes pointing to the ReIM group. ReIM does not provide any Lightweight Directory Interchange Format (LDIF) scripts to create ReIM user role.
The script creates the following three business user groups when you run the demo data script: Admin, Demo Users, and Limited Privs Users. No user groups exists by default and the retailer is responsible for creating the groups manually by inserting data into the appropriate table (demo data script can be used as a starting point), if the script is not run. As the names suggest the Admin group has the highest level of privileges, Demo Users group has smaller set of privileges and the Limited Privs Users has very limited set of privileges. The name of the group is completely arbitrary. There can be as many groups as required. The best approach is defined as the user group based on the set of task the user group members are supposed to perform and assign only the minimum required set of privileges to that group. For example, if the user is a warehouse manager who is responsible for resolving quantity discrepancies associated with his/her warehouses then a Warehouse Manager role can be created and Quantity Discrepancy Resolution privilege assigned to it.
You need to avoid assigning all users to Administrator role. This will grant all users more privileges than it is required. The best approach is to assign new users to Limited Privs Users group and then move user to another group as needed.
It is recommended to create an Admin group and an Admin user through a script and then to use Application logic (User Group Maintenance Screen) to maintain user groups.
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
Location and Merchandising Hierarchy data security is limited and mostly tied to discrepancy resolution functionality.
To address the issue of discrepancies between user references kept within LDAP and in ReIM application (as part of user role dependency), a new batch process is added. The process will identify the users that have been valid within ReIM but at some point have been removed from LDAP. Reference to such users will be removed. It is advised to run such process after invalidating users in LDAP or at least daily, as part of nightly batch window.
See the following examples of the issue (due to non-autonomous user deletion across LDAP and ReIM):
User Admin is created in LDAP.
User Admin is assigned to Manager Role within ReIM through the ReIM user maintenance screen.
User Admin is removed from LDAP.
User Admin is newly created in LDAP. This new user will automatically inherit Manager Privileges of the previous Admin user, as role/user association still exists within ReIM. The batch process will address the issue.
Another approach would be to guarantee, through LDAP policies, that user names will not be reused. In this case the batch process is not required and maybe excluded from the daily schedule.
As a part of the operational workflow, ReIM needs to have credential information to authenticate application users or to authenticate application itself with other dependent components such as database, LDAP, or Web services. For the case of remote users connecting to ReIM servers through browsers credentials are retrieved in real time through an online 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 ReIM provides convenience scripts that allow credential entries to be updated. The scripts allow the system administrator to see usernames stored in ReIM 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 ReIM 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 ReIM application logic. ReIM log configuration is done through ReIM log configuration file. The administrator has the rights to configure the location of the ReIM log files. ReIM log files are also owned by the OS user that own WebLogic process. It is recommended to grant access to log files only to the administrators.
ReIM application does not restrict concurrent sessions from the same user. It means that more than a single user can log in to ReIM 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.
The session is maintained per browser instance. So if more than a single browser is used then the server will consider such scenario as multiple user logins. At the same time multiple tabs of the same browser would share the session.
Session timeout is defined at the application server level. It is 60 minutes by default, but can be changed through WebLogic configuration.
