Version 2.10

Centrifuge Analytics v2.10

Press Announcement

 

Centrifuge Systems announced the general availability of Centrifuge Analytics v2.10, an industry leading security-focused release of its unique data discovery through link analysis and visualization platform.

Extend and refine the already robust Centrifuge access control and security policies to specify not only who is allowed access to restricted projects, but also who is NOT.

Traditionally applications are based on the whitelist access models: if you have a key, you can open the door. It is typically done that way because it’s easier to create a list of people who can use the application rather than who cannot. With Centrifuge whenever a data artifact is created it is owned and only accessible by the person that created that artifact. It has always been up to that person to then share that work with other Centrifuge users. With Centrifuge 2.10 the sharing action can now be further restricted by only allowing sharing with users that belong to the same restricted groups as the original user. This provides for added control and potential miss-sharing of sensitive data with users that may not have the appropriate level of access. 

Support hidden data sources, data connections, and parameters so that authorized users can access secured information without being aware of the mechanisms used.

When working with data source connectors extra care should be taken to ensure that users stay within their authorized areas and not use the connection details to gain backdoor access. Centrifuge 2.10 comes with two important levels of support to ensure that the right users use only the data source connectivity capabilities they are authorized to use:

  • Centrifuge 2.10 uses “hidden Properties” in its configuration files to define the connector details which will not appear in any Centrifuge dialogues, data views or export files.
  • When working with the Centrifuge Data Source Editor (DSE) additional capabilities have been provided to fine tune the level of access control needed for a specific customer’s environment. Centrifuge 2.10 provides additional user group level DSE roles as follows: edit source, access connection, access customer queries and view data values

Dynamically mark all Centrifuge visualizations with a visible banner reflecting the highest security sensitivity or classification present in the data being analyzed.

There are situations when it is important to clearly mark the application display as being sensitive or proprietary so as to inform the viewer that they may be looking at information that they should not be looking at. Centrifuge provides an optional ability to dynamically display a custom indicator (banner) that warns the user that the information being displayed may be sensitive and that they (or nearby staff) are authorize to view this information. 

Integrate login validation to use different, and potentially multiple, external enterprise authentication solutions and auto-registration capabilities.

The Centrifuge 2.10 authentication architecture has been extended to easily integrate with existing enterprise authentication capabilities like Active Directory. Why recreate the wheel when you can simply leverage your existing enterprise authentication environment.  Using a centralized password policy greatly simplifies the creation and deletion of users, the ongoing maintenance of passwords and the user’s need to keep track of additional passwords that may potentially cause an access vulnerability.  It is also worth noting that the original Centrifuge authentication architecture remains intact and by default continues to function as with previous Centrifuge releases unless specifically configured during the installation process to use the new capability.

Leverage a modular and extensible security architecture where customs authentication logic can be provided to augment the already robust capabilities.

For total flexibility and access control Centrifuge 2.10 leverages the Java Authentication and Authorization Service (JAAS) infrastructure and APIs to authenticate users independently of the underneath mechanism. As a result the authentication may be implemented in conjunction with existing Centrifuge capabilities or deploy as independent modules completely decoupled from the provided mechanism. For example, there may be situations where there is a need to incorporate some biometric authentication in addition to the active directory password validation before granting that user access to the application.