icCube

Documentation

Authentication

icCube is following J2EE standards. As such, it is accessed via a set of servlets (e.g., XMLA, reporting, cube builder, monitoring, etc...). Accesses to these servlets are authenticated using the standard servlet filter mechanism as defined in icCube.xml configuration file. This section details the default configuration. For more details please consult our forum. Note that configuring icCube behind the Apache Web Server is explained here.

Authentication Service

icCube provides an authentication service that is based on user definitions stored in a file. But, you can provide your own authentication service (i.e., Java class) via the <icCubeAuthenticationService> configuration in the icCube.xml file. As an example, the following is showing how the default service is configured. Note that you can configure whether or not the user name are case sensitive. E.g., if you're using Windows SSO, user names should be case insensitive (the authentication service is then used to attach the icCube role of the Windows authenticated user).

This service is using the user definitions as defined in the file icCubeUsers.icc-users available in the application users directory. When starting icCube for the very first time, the initial content of this file is sourced from the file available in the bin directory of the icCube installation directory.

<icCubeAuthenticationService>

    <service-class>crazydev.iccube.server.authentication.IcCubeAuthenticationService</service-class>

        <!--
          Optional parameter to specify whether or not the user names are case sensitive ( value: true | false ).
          Default value is : false.
        -->
        <!--
          <param>
            <name>caseInsensitive</name>
            <value>true</value>
          </param>
        -->

    </icCubeAuthenticationService>
    

Anonymous Logon

Anonymous logon is controlled via a servlet filter init parameter (see below); for the sake of simplicity, it is enabled by default. For production, we strongly advise to disable it and delete the 'anonymous' role as well.

Servlet Filter Configuration

The <filterConfiguration> section defines the filters being referenced later in each component configuration (e.g.,, XMLA, GVI, etc...).

icCube Web Applications (e.g., IDE, Monitoring, ...)

Users log into icCube using their user-name and password. Once logged in, users are authorized to access data and application according to their default role. To log with a specific role, users can log using their user-name and role simply replacing their "userName" by "userName/roleName". The user interface is using the HTTP Form Authentication that is configured in the icCube.xml file as following:

<gwtServiceComponentConfiguration>
        <filter>GWT Authentication</filter>
</gwtServiceComponentConfiguration>

<filterConfiguration>
        <filter>
            <filter-name>GWT Authentication</filter-name>
            <filter-class>crazydev.iccube.server.authentication.IcCubeGwtAuthenticationServletFilter</filter-class>
            <init-param>
                <param-name>anonymousLogon</param-name>
                <param-value>true</param-value>
            </init-param>
        </filter>
</filterConfiguration>
    

XMLA

Similarly to the Web user interface, users can be authenticated using a specific role : "userName/roleName". The XMLA interface is authenticated using HTTP Basic Authentication.

<xmlaComponentConfiguration>
        <filter>HTTP Basic Authentication</filter>
</xmlaComponentConfiguration>

<filterConfiguration>
        <filter>
            <filter-name>HTTP Basic Authentication</filter-name>
            <filter-class>crazydev.iccube.server.authentication.IcCubeBasicAuthenticationServletFilter</filter-class>
            <init-param>
                <param-name>realm</param-name>
                <param-value>icCube</param-value>
            </init-param>
            <init-param>
                <param-name>anonymousLogon</param-name>
                <param-value>true</param-value>
            </init-param>
        </filter>
</filterConfiguration>
    

Google Visualization Interface (GVI)

Two filters are being used: the first one is extracting the username/password from the GVI requests and the second one is handling logout requests.

<gviComponentConfiguration>

    <url>/icCube/gvi</url>

    <filter>GVI Request Authentication</filter>
    <filter>GVI Authentication (logout)</filter>

</gviComponentConfiguration>

<filterConfiguration>
        <filter>
            <filter-name>GVI Request Authentication</filter-name>
            <filter-class>crazydev.iccube.server.authentication.IcCubeGviRequestAuthenticationServletFilter</filter-class>
            <init-param>
                <param-name>anonymousLogon</param-name>
                <param-value>false</param-value>
            </init-param>
        </filter>
        <filter>
            <filter-name>GVI Authentication (logout)</filter-name>
            <filter-class>crazydev.iccube.server.authentication.IcCubeGviLogoutAuthenticationServletFilter</filter-class>
        </filter>
</filterConfiguration>
    

Windows Single Sign-On (SSO)

Windows SSO is supported for the XMLA interface using the following configuration:

<xmlaComponentConfiguration>
        <filter>Windows SSO (waffle)</filter>
        <filter>Windows SSO (adapter)</filter>
</xmlaComponentConfiguration>
        
<filterConfiguration>
    <filter>
        <filter-name>Windows SSO (waffle)</filter-name>
        <filter-class>waffle.servlet.NegotiateSecurityFilter</filter-class>
        <init-param>
            <param-name>principalFormat</param-name>
            <param-value>fqn</param-value>
        </init-param>
        <init-param>
            <param-name>roleFormat</param-name>
            <param-value>both</param-value>
        </init-param>
        <init-param>
            <param-name>allowGuestLogin</param-name>
            <param-value>false</param-value>
        </init-param>
        <init-param>
            <param-name>securityFilterProviders</param-name>
            <param-value>waffle.servlet.spi.NegotiateSecurityFilterProvider</param-value>
        </init-param>
        <init-param>
            <param-name>waffle.servlet.spi.NegotiateSecurityFilterProvider/protocols</param-name>
            <param-value>Negotiate NTLM</param-value>
        </init-param>
    </filter>
    <filter>
        <filter-name>Windows SSO (adapter)</filter-name>
        <filter-class>crazydev.iccube.server.authentication.IcCubeWindowsSSOAuthenticationServletFilter</filter-class>
        <init-param>
            <param-name>ignoreDomainInPrincipal</param-name>
            <param-value>true</param-value>
        </init-param>
        <init-param>
            <param-name>domainPrincipalSplitter</param-name>
            <param-value>\\</param-value>
        </init-param>
    </filter>
</filterConfiguration>
    

Windows SSO is as well supported for the other interfaces; please see the icCube.xml for more details.

On-The-Fly Authorization

The authentication service and servlet filters as described above are assuming that users are using predefined roles (aka. access rights) as defined in icCube. Nevertheless, it is possible to create on-the-fly a role description once the user has been successfully authenticated. This role can then match exactly your own requirements. This scenario is pretty well suited for OEM installation when users and their access rights are more likely defined elsewhere.

In that case, a new service has to be used using your own authentication mechanism; once a user has been successfully authenticated, you can create an on-the-fly role description that is going to be used by icCube to setup the actual permissions.

As this is quite an advanced feature, please contact us and/or consult our forum.

Latest Features / Servlet Filters

The icCube team is adding new filters based on the customers demand; so please have a look to the icCube.xml file for up-to-date information and/or contact our support should you have any question.



Next chapter : Configure SSL (HTTPS) connector.