Session Handling

Purpose

Control how long sessions are kept alive.

Details

Sessions are used to group multiple requests from clients together as executed by the same end-user. A session can be authenticated, at which time it is associated with a user who provided valid credentials during the authentication process. The user of an authenticated session is often called principal.

Sessions are tracked by the server, where they are stored in the database. Server and client communicate their session information through HTTP cookies:

cookie name: skpsession
value: unique session ID, an alphanumeric string
path: /
domain: the FQDN of the storagehost that the client connects to

Example of a new cookie sent by the server:

Set-Cookie: skpsession=0rn97f5ckglktfd4t2ol6b46bgvh29mu7km23hm027g9tp20rhe0; path=/; domain=free.teambeam.de; secure; HttpOnly

Session cookies have no expiration date (contrary to persistent cookies). Typically a client (browser, commandline client) will store the cookie in memory only. When the browser / commandline client is closed, the cookie is deleted.

Note: session cookies must be protected from eavesdropping and disclosure. They must only ever be transported over a secure (SSL-encrypted) channel.

Session ID

The unique session ID is generated by the server and sent to the client. From then on, the client must send the session ID with every request, until it is regenerated by the server.

The following events lead to session ID regeneration:

after successful authentication (privilege elevation)

In such a case, the server will inform the client of the new session ID that is to be used from that moment on.

Session Expiration

Every session is terminated latest after a configurable timeout (session lifetime), regardless if the session is kept continuously active. At this time, the session ID is dropped from the database, and the client must obtain a new session ID and reauthenticate it.

Inactive sessions are terminated if they have been idle too long (“session idletime”). At this time, the session ID is dropped from the database, and the client must obtain a new session ID and re-authenticate it.

Attempts at session injection, whereby the client attempts to specify the session-ID that is to be used, are detected by the server and refused.

Session Highjacking Protection

It is possible to protect agains session highjacking by terminating the session if all of the following items change from one request to the next:

the client's IP-address (as reported to the server in the HTTP header x-forwarded-for)
the client's user agent (as reported to the server in the HTTP header user-agent)

If only one of the items change, the metadata for the session is updated and it remains valid. If both change, the current session is dropped. A new session ID will then be generated, which must be re-authenticated.

Configuration

Scope: configuration applies to a storagehost
Privileges: server-administrator privileges required
Default:
- Cookie domain: FQDN of the storagehost
- Instruct browser to send the cookie over HTTPS only: enabled
- Maximum session lifetime: 24h
- Maximum session idletime: 1h
- Session highjacking protection: disabled`

To configure the feature, server administrators must update the ENVchain:

$ENV['cookie_domain']       = "[STORAGEHOST]";  // the domain-part of the cookie. "[STORAGEHOST]" will be replaced with the FQDN dynamically.
$ENV['cookie_secure']       = true;         // controls the 'secure' flag in cookies. set to false, if MyTeamBeam shall be reachable over HTTP.
$ENV['session_lifetime']    = 60 * 60 * 24;     // in secs. Sessions older than this will be terminated.
$ENV['session_idletime']    = 60 * 60 * 1;      // in secs, max time a session can be idle before it needs to be reauthenticated
$ENV['session_block_hijacking'] = false;        // if set, sessions will be considered stolen, if both IP and UserAgent change within one request

Dependencies

none

Conflicts