Changing how item type access is determined

In some deployments of i2 Analyze, it is necessary to configure the system so that users are only able to access and interact with records with particular item types. By default, i2 Analyze determines which item types a user can access by their user group membership using the type-access-configuration.xml file. If this suits your needs, see Item type security to learn how to configure users' access to item types in this way. To determine which item types a user can access based on other user information, you must implement the item type security SPI.

By implementing the item type security SPI, user item type access can be determined by any combination of:

  • User principal name

  • User group membership

  • User security dimension access permissions (defined by the i2 Analyze security schema)

The SPI is a set of Java interfaces that you can implement with your own Java classes. Then, you can configure i2 Analyze to use your implementation instead of the default one.

Implementing the SPI

See the com.i2group.disco.security.spi package in the i2 Analyze Security SPI documentation for details, but the two interfaces that you need to implement are:

  • IUserItemTypeAccessResolver. This interface is used to get the access levels assigned to a specific user for each item type.

  • IUserItemTypeAccessResolverProvider. This is the interface that i2 Analyze uses to obtain IUserItemTypeAccessResolver instances for specific users. It also exposes a method that allows you to validate and reload the item type security configuration on server startup and reload.

You must package your SPI implementation into a single JAR file.

Configuring i2 Analyze to use your implementation

Note: Customizing item type access resolution should take place during the development phase of your deployment, in the configuration development environment. See Deployment phases and environments

for more information.

For i2 Analyze to use your item type security implementation, you must:

  1. Copy the JAR file containing your implementation into the toolkit/configuration/fragments/opal-services/WEB-INF/lib i2 Analyze toolkit directory where it will be deployed into the application.

  2. Instruct i2 Analyze to use your implementation by setting the IUserItemTypeAccessResolverProvider property in the toolkit/configuration/fragments/opal-services/WEB-INF/classes/DiscoServerSettingsCommon.properties file to the fully qualified class name of your IUserItemTypeAccessResolverProvider implementation. For example:

    IUserItemTypeAccessResolverProvider=com.example.ImplementationClassName

  3. Redeploy and restart liberty. From the toolkit/scripts directory, run:

    setup -t stopLiberty
setup -t deployLiberty
setup -t startLiberty

High availability deployments

For high availability and disaster recovery deployment topologies, performing the above procedure in the configuration development environment ensures that your SPI implementation is copied to each Liberty server when you configure the pre-production environment. To make changes to the SPI implementation in a pre-production or test environment that has multiple Liberty servers, you must ensure that the updated JAR file is copied to the toolkit of each Liberty server.