Cookieless Sessions

Cookieless sessions are available in versions 2018.1 and above.

When a user enters Exago BI, the application creates a session in order to preserve the user's working state and environment while they engage in application tasks. The session information is stored on the web application server or state server (depending on the network configuration). Whenever requests are made, the user's browser sends a unique, randomly generated token to the web server in order to authenticate the user and preserve the connection between user and session.

By default, and in versions of Exago BI prior to 2018.1, the token is stored as a browser cookie. However, when embedding using the JavaScript API in a cross-origin environment (where the Exago BI application and host application are on separate servers with different domains), cookies are considered a potential attack vector for cross-site scripting (see IBM: Prevent a cross-site scripting attack for more information). Therefore, most modern web browsers prevent embedded content from separate origins from using cookies.

If you are embedding Exago BI using the REST API and JavaScript API, and your host application and Exago BI are on separate domains, you will need to use cookieless sessions.

To enable cookieless sessions, locate the following line in the WebApp\web.config file and set the cookieless attribute to true:

<sessionState mode="InProc" cookieless="true" timeout="20" />

Cookieless sessions work to preserve state by appending the token to the URL string itself, which is used to connect to the web server. For example, a standard application URL generated by the server API after creating a session looks similar to the following:

//ExagoBI/ExagoHome.aspx?sn=0

With cookieless sessions enabled, the session token is added to the URL, for example:

//ExagoBI/(S(rim43x0e3cz2hf4sjw24ezdk))/ExagoHome.aspx?sn=0

This has no direct implications for the embedding process into the host application.

Secured Authentication

When the web application server is exposed to the internet or any insecure public network or intranet, you need to enable secured authentication to prevent unauthorized access.

Because the token is passed as a part of the URL, it can be used by malicious third parties to send unauthorized requests to the web server. Secured authentication causes the web server to require a secondary security key in order to authenticate the session. This does not require any additional effort on the part of the end-user.

To enable secured authentication, edit the WebApp\appSettings.config file and add the following line:

<add key="useSecurityToken" value="True" />

The server API generates a security key with the session and embeds it into the page markup. It is sent with every client request as a part of the payload. When using a secured SSL connection, the payload is encrypted, thus making it nearly impossible for a malicious party to derive the key.

Caution: Unsecured connections will compromise any security intended by the use of two-factor authentication. If the payload is unencrypted, the key can be easily intercepted by a third party. The web server must enforce HTTPS in order for secured authentication to function properly.