Scroll

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 ID 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 session ID 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.

Note: This article references <WebApp>\ as a placeholder for the applications install location. The default install locations are /opt/Exago/ on Linux and C:\Program Files\Exago\ExagoWeb\ on Windows; however, these directories may be changed during installation. 

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 session ID 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 ID 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 session ID 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 token 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 token 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 connection, the payload is encrypted, thus making it nearly impossible for a malicious party to derive the token.

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

Cross-Origin Resource Sharing

If the Exago BI application is being accessed over a network, the Exago web server must be configured to allow cross-origin requests to the client host application.

By default, a web application making a request for content that originates from a remote server sends a cross-origin HTTP request. For security reasons, browsers restrict these types of requests when they originate from scripts.

To permit content to be accessed by whitelisted resources, you can configure the Exago web server to send a Access-Control-Allow-Origin header. For example:

Access-Control-Allow-Origin: "hostapp.server.com"

In IIS, this is either set in the HTTP Response Headers or added manually to the web.config file.

In Apache, following line is added to all relevant .conf files:

Header set Access-Control-Allow-Origin "hostapp.server.com"

See Cross-Origin Resource Sharing (CORS) - HTTP | MDN (Mozilla) for more information.


Hidden Article Information

Article Author
Exago Development
created 2018-05-08 16:41:51 UTC
updated 2018-12-06 21:40:59 UTC

Labels
security, config, state, web, server, memory, encrypt, process, api, javascript, url, cookie, token, guid, https, ssl, secure,
Have more questions? Submit a request