2 Application Administration

This chapter discusses application administration.

Roles and Permissions

In Oracle Retail Point-of-Service and Oracle Retail Mobile Point-of-Service, you specify user access to the application by assigning a role to each user. Each role contains a list of the security access points of the application, specifying which access points that role is allowed to use. You can create as many roles as you need. Roles are typically named for job titles; by creating a manager role and a clerk role, for example, you define two classes of employees with different access to Point-of-Service functions. All clerks, however, would have the same access rights.

In Oracle Retail Central Office, Back Office, and Returns Management, security restricts access to functions and data by the use of security roles. Each role identifies those functions that a user is allowed to perform. A security role is assigned to your user ID. If you are not allowed to use a function, the tab or link for that function is not displayed on the screen. For example, your defined role might allow you to see tasks, but not add or remove any tasks.

To reduce the administrative time required to set up security for users, a role can be defined for each security level and the functions that role may and may not access can be specified. Each user ID is then assigned to one role and has access to all functions allowed for that role. Different roles may have identical function accessibility. If a role is changed, any user IDs assigned to that role are not affected until the next time the user logs in.

Other Common Application Administration

This section discusses common application administration.

Securing Web Services

Oracle Retail Point-of-Service uses web services for its integrations with Oracle Retail Central Office, Oracle Retail Returns Management and Oracle Retail Store Inventory Management. This section discusses security for the web services.

WS-Security

The OASIS WS-Security specification is the open standard for web services security. Its goal is to enable applications to secure SOAP message exchanges by providing encryption, integrity, and authentication support. WS-Security offers a general-purpose mechanism for associating security tokens with message content. The specification defines these approved token types:

Username Token Profile
X.509 Certificate Token Profile
Security Assertion Markup Language (SAML) Token Profile

Web Service Security Implementation

Oracle Retail Returns Management and Oracle Retail Store Inventory Management web services are protected using the WS-Security user authentication mechanism. Clients who want to access these web services have to provide a valid user ID and password using a WS-Security Username Token.

Oracle Retail Returns Management Web Service

Oracle Retail Point-of-Service adds the WS-Security UsernameToken for the Oracle Retail Returns Management web service using JAX-WS handlers security modules.

Note:

The WS-Security Username Token only provides SOAP message-level security. For transport level security, Oracle Retail Point-of-Service and Oracle Retail Returns Management support HTTPS (SSL). If transport level security is required, enable SSL communication through the installer.

Oracle Retail Store Inventory Management Web Service

Oracle Retail Point-of-Service can communicate with both secured and unsecured Oracle Retail Store Inventory Management web services. If the web service is secured, the Oracle Retail Point-of-Service application adds the Username Token using the stub classes provided by the Oracle Retail Store Inventory Management application.

Securing JMS

Securing JMS communication varies based on the vendor. For information on securing JMS for Oracle WebLogic Application Server, see the following web sites:

Caution:

Never set the user name and password to the connection factory settings.

Doing this gives any user with JNDI read-access, full access to all JMS destinations. It also increases the risk of exposure if the serializable connection factory contains the user name and password. The client, or the client context, should always provide the user name and password for authentication. Therefore, it is not necessary to supply those in the connection factory.

Application Specific Feature Administration

This section describes administration that is specific to each application.

POS Suite Applications Audit Log

The Release 14.1 Oracle Retail POS Suite applications enable out-of-the-box audit logging by default. These logs should not be disabled.

Application log files are configurable. If you modify the settings, you must ensure they are compliant with PCI-DSS requirements 10.2 and 10.3.

The POS Suite applications implement automated audit trails for all system components to reconstruct the following events:

All actions taken by any individual with administrative privileges as assigned in the application
Access to application audit trails managed by or within the application
Invalid logical access attempts
Use of application's identification and authentication mechanisms
Initialization of the application audit logs
Creation and deletion of system-level objects within or by the application

The Release 14.1 Oracle Retail POS Suite applications implement an automated audit trail logging of various events happening on the system. The audit trail logging is configured in the log4j configuration file maintained for each application. The various events that need to be logged and the file where the audit logging information will be captured are configured in the log4j configuration file.

Caution:

Do not comment out any of the entries or prevent the logging from occurring.

Oracle Retail Point-of-Service implements an automated audit trail system that logs all system activities into a log file. The log file is configured in the log4j.xml file in the /OracleRetailStore/<Server or Client>/pos/config directory. The events that are logged are listed in the file.

For each event, the Oracle Retail Audit log service logs the point of Origination of the event. In addition, the audit log framework logs the Initialization of the Audit log itself.

The log files are created with the following names and in following locations:

Oracle Retail Back Office:

File Name: BackOffice_audit.log

Location (Oracle stack implementation):

<WEBLOGIC_INSTALL_DIR>\domains\<Domain Name>\servers\<Admin Server Name>\logs
Oracle Retail Central Office:

File Name: CentralOffice_audit.log

Location (Oracle stack implementation):

<WEBLOGIC_INSTALL_DIR>/domains/<Domain Name>/servers/<Admin Server Name>/logs
Oracle Retail Point-of-Service:

File Name: audit.log

Location (in each register):

$INSTALL_DIR/Client/pos/logs

The following events should be captured at the system level:

Logon or logoff
Start or stop a process
Use of user rights
Account administration
Change the security policy
Restart and shut down the system
USB events and Mount and Unmount events
Access a file or directory (create a file, remove a file, read a file, or change file descriptors)

Various tools are available to collect audit trail information. Audit trails should be maintained for the applications and for external system events.