Session Management

For security reasons, each login attempt to a Rhapsody engine takes by design a non-trivial amount of time to evaluate in order to prevent brute-forcing of the password store in the event that it is compromised. Internally, Rhapsody uses PBKDF2 for password storage, which salts the password, and then hashes it a large number of times which deliberately takes time to calculate (Rhapsody uses SHA-512 done 25000 times by default). This process takes a small amount of CPU processing time to process each login attempt, which normally is not a problem (there are slowdown and lockout mechanisms in place that slow down login attempts when those attempts are failing to prevent attacks). However, there is a potential risk that a large number of successful login attempts in a short period of time could consume a fair amount of CPU resources, particularly on a smaller box. This is not an issue with normal logins to Rhapsody IDE or the Management Console, but certainly could become an issue if using the REST API.

Rhapsody addresses these problems in the following ways:

• An authenticated session can be re-used with the REST API, therefore there is no need to log in a second and subsequent time.
• Rhapsody's user management service provides a configurable limit of the maximum number of login attempts permitted each minute.

• Rhapsody's web monitoring service provides a configurable maximum upload size allowed during a failure before the connection is aborted.

Re-Using Sessions

Re-using sessions for the Rhapsody REST API is straightforward as the sessions are tracked using cookies that are provided to the requester in the initial response. If those cookies are provided to the REST API in the next request then it will use that same session again without requiring a new login to be performed. If the cookies reference a session that no longer exists, then a new login attempt is made automatically (in other words, there is no need to handle the case where the session is no longer valid).

This functionality is simple to use from cURL, as it provides support to send (-b parameter) and receive (-c parameter) cookies. If both the -b and -c parameters are provided on the command line, then it will store all received cookies in that file, and send those same cookies on each request.

curl -v -b cookies.txt -c cookies.txt --cacert myCert.cer --basic -u administrator:r https://engine:8444/api/alerts/active

The authentication credentials are still provided on the command line as this allows the new session to be created and authenticated if the previous session no longer exists in Rhapsody (internally REST API sessions timeout after about two minutes).

Preventing Too Many Logins

The Rhapsody user management service internally tracks the number of login attempts made every minute, and refuses to allow further attempts when this limit has been reached until the minute has elapsed. Limits apply to the REST API, Rhapsody IDE, and the Management Console. These limits, however, are enforced independently and are configured to use different defaults. These values can be modified in the rhapsody.properties file as follows:

# Configure the maximum number of login attempts per minute
#UserManagementService.maximumLoginAttemptsPerMinute.ide_view=20
#UserManagementService.maximumLoginAttemptsPerMinute.monitoring_view=20
#UserManagementService.maximumLoginAttemptsPerMinute.rest_api_call=5

To edit one of these default values, uncomment the relevant lines and then restart Rhapsody.

The default value for the REST API of 5 has deliberately been set low to encourage session re-use because this is considerably less CPU intensive than re-authenticating on each request. The limit can of course be increased if there is a genuine need to do so and the Rhapsody server is able to handle the additional load.

If a REST API call is rejected for this reason, it is sent a 429 Too Many Requests HTTP status code indicating that too many requests have been made.

# Configure the maximum upload size (in bytes) allowed during a failure before the connection is aborted
#WebMonitoringService.http.maxswallowsize=104857600
#WebMonitoringService.https.maxswallowsize=104857600