User Session Management

This page describes how user sessions are managed in QPR ProcessAnalyzer.

Authentication and session tokens

All requests done to QPR ProcessAnalyzer are performed by a user account. First the user needs to authenticate to start a new session, and all subsequent requests use that session. As a result of the successful authentication, the user will get a session token. The session token is a 128-bit number called Global Unique IDentifier (GUID). The length of the GUID (128 bits) can guarantee uniqueness across space and time. New GUIDs are created by using the NEWID() function provided by SQL Server (https://docs.microsoft.com/en-us/sql/t-sql/functions/newid-transact-sql?view=sql-server-2017). The generated GUID is compliant with RFC 4122 (https://tools.ietf.org/html/rfc4122).

Once the user is authenticated, subsequent requests authenticate the session. Users prove they own a session by submitting session id as parameters with each request. The session is then validated to all requests sent to QPR ProcessAnalyzer. Session token is also included during the log off mechanism.

For the session management to work in a secure way, the communication channel between the user and the server needs to be secure in terms in confidentiality and integrity. Thus the server needs to be configured to use the HTTPS protocol, with only secure ciphers allowed (more information in the security hardening instructions).

User accounts are stored to the QPR ProcessAnalyzer database and their passwords are stored as one-way hash values calculated with the SHA-256 algorithm. Salt is used in the hashing for protection against the use of rainbow tables.

QPR ProcessAnalyzer can load data from external systems, such as SAP or Salesforce.com. When a session is created, credentials are entered by the user and are stored in Windows profile with additional encryption. Users loading data from Salesforce.com enter their Salesforce credentials in the Integration Service for Salesforce web UI when launching the transfer. Credentials are not stored on the QPR ProcessAnalyzer.

Server log keep track of all the usernames that try to authenticate to QPR ProcessAnalyzer. Also, client IP address is logged.

Log off and session expiration

When user logs offs a session, its session token is marked as invalid in the sessions table in QPR ProcessAnalyzer database, and thus the session cannot be used anymore. There are the following settings related to session management (more information):

• Session idle timeout: If the user session has not been used (i.e. there are no requests sent to the server), the session is invalidated after this duration. The purpose is to get the session invalidated soon, e.g. if user has forgotten to log out the session. By default this time is one hour.
• Session maximum duration: Duration starting from the login after which the session is invalidated anyways (even though it is used continuously). The purpose is to get the session invalidated e.g. in cases where some automated script maintains the user session for ever. The best practice for these kind of scripts is to logout the session after the communication has been completed. The session maximum duration is by default 24 hours.

Preventing password guessing attacks

QPR ProcessAnalyzer has a mechanism to prevent brute-force password guessing attacks. Each failed login attempt is recorded, and if there has been total of five (5) failed login attempts to a specific account, that account is locked for five (5) minutes. After the lockout period, the account is again available for logins. In the longer period, this mechanism allows to make on average maximum of one password guessing attempt per minute. If using strong passwords (at least 8 characters long), the probability of a successful guess in an attack that lasts for examples weeks, is very low.

The failed login attempts are logged (more information about logging, and it's important for the system administrator to monitor the logs regularly, to detect possible password guessing attack that have been in progress for a longer time. In case there is an attack in progress, it's recommended to ask users to change password and make sure that strong passwords are used. In addition, if the attack comes from specific IP addresses, it may be possible to block those IP addresses, to stop the attack.