icCube can have different deployments and security setups.

  • Single instance / single schema
  • Single instance / multiple schemas
  • Single instance with Multi-tenant environments
  • Several instances

Find below more information on each setup.

Single instance / single schema

This is the advised setup if you need to access all data (from all customers) at once.

  • One icCube server/deployment.
  • Role definition(s) will be in this single environment.
  • Each role with his data permissions (setup for each customer to see only their own data within this same schema)
  • All dashboards in the shared repository will be visible by all users
  • Same set of plugins for all users (theme and custom widgets)

Single instance / multiple schemas (one schema per customer)

You can also have multiple schemas in a single instance and only allow for customers to access their own schema only. Note that you can’t make a single query over multiple schemas in this setup.

  • Role definition(s) will be in this single environment.
  • All dashboards in the shared repository will be visible by all users
  • Same set of plugins for all users.

Single instance with Multi-tenant environments (one tenant per customer)

You can have a single icCube running with different tenants. What icCube calls a tenant is a separate environment in a same instance.

  • Each tenant has their own set of schemas
  • Role definition(s) will be in this single environment.
  • Each tenant has their own dashboard repository.
  • Own set of themes and plugins per tenant.

Several instances

For a complete separation of each customer, you can have an icCube instance per client, or an instance for each big client and other one(s) that gather the smaller clients. Security-wise this is the safest way to make sure the data/environments/dashboards will never mix between clients.

  • Each icCube instance has its own set of schemas.
  • Each icCube instance has its Role definition(s).
  • Each icCube instance has its own dashboard repository.
  • Own set of themes and plugins per instance.
  • Horizontal scalability is possible

Bear in mind that icCube uses files for persistency and might be copied across environments.

Find here more info on multi-tenant vs. permissions.

To have both v7 Reporting and v8 Dashboards on a same icCube instance, ensure to have the following in your icCube.xml :

<!--
    Reporting (v8): the new Dashboards application (since reporting v8).

        true : (default)
-->
<report.v8.enabled value="true"/>

<!--
    Reporting (viz): the old (prior to the Dashboards v8) reporting. Deprecated.

        false : (default)
-->
<report.viz.enabled value="true"/>

Note that:

  • v8 is the default application in the top right icon where you can switch the apps
  • In the home console, you’ll have the two boxes
  • In the Admin console, you’ll have two use cases for installing v7 and v8

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.

We advise putting 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 and/or CORS requests. All the HTTP requests that are hitting the customer Web Application targeted to icCube are being forwarded by the reverse proxy.

Authentication

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

	IC3_USER_NAME
	IC3_ROLE_NAME

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.

Authorization

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
</Proxy>

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.

<uxComponentConfiguration>

	<static>
		<filter>PASSTHROUGH</filter>
	</static>

	<ux-api>
		<filter>PASSTHROUGH</filter>
	</ux-api>

	<api>
		<filter>PASSTHROUGH</filter>
	</api>

</uxComponentConfiguration>

<reportingComponentConfiguration>
	<filter>PASSTHROUGH</filter>
</reportingComponentConfiguration>

<gviComponentConfiguration>
	<filter>PASSTHROUGH</filter>
</gviComponentConfiguration>

<filterConfiguration>
	<filter>
		<filter-name>PASSTHROUGH</filter-name>
		<filter-class>
			crazydev.iccube.server.authentication.passthrough.IcCubePassthroughAuthenticationServletFilter
		</filter-class>
	<init-param>
		<param-name>anonymousLogon</param-name>
		<param-value>false</param-value>
	</init-param>
	</filter>
	
</filterConfiguration>
		

The authentication service is configured to accept the HTTP headers:

	IC3_USER_NAME
	IC3_ROLE_NAME

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

<icCubeAuthenticationService>

	<serviceclass> crazydev.iccube.server.authentication.IcCubeHeaderAuthenticationService</service-class>
	
	<param>
		<name>header.user</name>
		<value>IC3_USER_NAME</value>
	</param>
	
	<param>
		<name>header.role</name>
		<value>IC3_ROLE_NAME</value>
	</param>
	
	<param>
		<name>header.role.onTheFly</name>
		<value>false</value>
	</param>
	
</icCubeAuthenticationService>

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>

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

Embedding icCube

To check the single sign-on within icCube via the your Web application, you can add an iFrame or DIV 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):

For more information, check our documentation page on embedding and an example on GitHub.

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.