This article is explaining a typical way to embed icCube into an existing customer Web Application and configure the authentication.

icCube will always be “behind” the customer Web application/web-server that is responsible for authentication. Once the authentication is performed, the customer Web application is sending the user information (e.g., user name, role name) to icCube via HTTP headers. icCube is being configured to retrieve this information and perform the authorization.

In the customer Web page that is embedding icCube Dashboards, we advise using an iFrame and put in place a reverse proxy to make icCube appear (for the browser) in the same domain as the Web application to avoid all issues related to iFrame usage. All the HTTP requests that are hitting the customer Web Application targeted to icCube are being forwarded by the reverse proxy.


It is performed by the customer Web Application that is responsible to add (for example) the following HTTP headers:


The IC3_ROLE_NAME must be an existing role within icCube. This is not an obligation. In a later article, we’ll explain how to perform custom/on-the-fly authorization to prevent duplicating user management into icCube.


Simply define the required roles. Once logged the authenticated user will be attached to one of them. Find here the documentation for the access rights.

Reverse Proxy Setup

The reverse proxy is responsible for mapping the requested URLs (in the webapp.com domain) to the “internal” icCube URLs.

For example using Apache you could do something like:

ProxyRequests Off

<Proxy *>
  Order deny,allow
  Allow from all

ProxyPass /analytics/icCube http://localhost:8282/icCube
ProxyPassReverse /analytics/icCube http://localhost:8282/icCube

meaning www.webapp.com/analytics would be internally forwarded to http://localhost:8282/icCube. Note that the browser will not see this internal forwarding. Everything would appear as if icCube is fully part of the www.webapp.com domain.

File: icCube.xml

You’ll have to change the <filter> configuration for each service. We’re going to use a filter that is passing through the HTTP request to the icCube authentication service.

Note that we’re removing the anonymous login as well (highly recommended for production usage). The same way you can manually remove the ‘anonymous’ role using the icCube/console (icCube/console/admin/Roles) to ensure there is no way to connect as anonymous in icCube.









The authentication service is configured to accept the HTTP headers:


The roles have to be defined within icCube. Note the name of the administrator role is: administrator.


	<serviceclass> crazydev.iccube.server.authentication.IcCubeHeaderAuthenticationService</service-class>

Configuration: log4j.xml is controlling the logging level/information in the files: /log/icCube.log.

The following two loggers may be set to “debug” for tracing HTTP requests headers/parameters while putting in place the authorization:

<logger name="icCube.authorization">
	<level value="debug"/>

<logger name="icCube.http.request">
	<level value="debug"/>

Reporting Integration : iFrame

To check the single sign-on within icCube via the your Web application, you can add an iFrame within your Web application and setup its source attribute to either the permalink of a report or a report application as following (assuming your webapp is available at www.webapp.com/analytics):

Note that a two-way communication between the customer Web application and icCube can be set up but this is for another article.

Do not hesitate to contact us if you need more information.

By Nathalie Leroy Tapia Heredia