Page tree
Skip to end of metadata
Go to start of metadata

Security/authentication approach

The AIP Console authentication provider has been totally restructured and now uses the open-source OAuth2 compatible Keycloak system. Keycloak provides local authentication, and can also interact with other enterprise authentication systems such as LDAP and SAML. This change greatly simplifies the configuration of the authentication method you choose.

As a result of this change:

  • AIP Console no longer provides any built in authentication mechanisms configured in .properties files. Users, user roles and identity providers are all configured directly in Keycloak.
  • There is no admin user selection in the initial start-up wizard because the first admin user is now created directly in Keycloak (see AIP Console - 2.x - Initial configuration).
  • The Security tab has been removed from the Administration Center because global level roles are now configured directly in Keycloak. Resource level roles are still configured directly AIP Console (see Administration Center - Security - User Roles).
  • Resource level roles have been simplified: there is now one single role available called Resource Owner. This role is similar to the Application Owner role available in AIP Console v 1.x.

AIP Node instances

All registered AIP Nodes are shown in the Nodes tab in Administration Center as in v. 1.x:

  • AIP Nodes instances are registered automatically when they are installed, so there is no need to add them manually (and which is why there are no add or edit buttons).
  • The right hand side of the panel displays two icon types. These icons represent the health indicator status. When the colour is green, the status is "OK".  When the mouse cursor hovers over the icons, a tooltip shows additional information for the indicator.
    • drive icon:(tooltip shows amount of free storage space on the AIP Node instance)
    • and multiple database icons (shows the host name and port number of the CAST Storage Service/PostgreSQL instance that the AIP Node can access
  • The number of applications associated to the AIP Node instance is no longer displayed because applications are not attached to any AIP Node - instead AIP Console will automatically choose the AIP Node to use for the required job - you can see which AIP Node instance is running the job using the live log panel:

  • Where multiple AIP Node instances are configured, AIP Console will automatically operate in load-balancing mode where the least used AIP Node instance is selected from the pool of AIP Node instances to perform the next job (analysis/snapshot etc.). By default, if multiple AIP Node instances are available, AIP Console will choose the AIP Node instance running the most recent release of AIP Core.

Initial start-up wizard

The initial start-up wizard has been modified. The following steps have all been removed:

  • Verify the installation - no longer necessary to fetch the unique key from the configurationKey.txt file
  • Assign administrator role - this action is instead performed in Keycloak
  • Configure Measurement schema - by default the AIP Node Database (delivered as a Docker container with AIP Console) will be configured to host the Measurement schema. CAST highly recommends configuring a dedicated CAST Storage Service/PostgreSQL instance for this instead. See Measurement schema below.

CAST Storage Service/PostgreSQL instance management

The management of CAST Storage Service/PostgreSQL instances that will be used for your analysis schema storage and for your Measurement schema has changed in AIP Console v.2:

Analysis/snapshot schema storage

CAST Storage Service/PostgreSQL instances for analysis/snapshot schemas are now configured directly in AIP Console in the Administration Center under the Global Configurations option, instead of when installing a new AIP Node:

By default, one database connection will already be predefined. This is a connection to the PostgreSQL AIP Node database provided as a Docker container and is used to store options and settings common to all AIP Node instances. It is possible to use this database for your analysis/snapshot schema storage needs, however this is not recommended and you should instead define additional CAST Storage Service/PostgreSQL instances.

Any CAST Storage Service/PostgreSQL instance defined in AIP Console will be available to any AIP Node instance. The specific CAST Storage Service/PostgreSQL instance that will be used for a given application is determined when the Application is created in AIP Console:

You can find more details about this in AIP Console - 2.x - Initial configuration.

Measurement schema

The Measurement schema is required for consolidating snapshot data from all AIP Nodes for display in the CAST Health Dashboard. The initial start-up wizard no longer prompts you to define your Measurement schema and CAST Storage Service/PostgreSQL host - instead AIP Console is preconfigured to use the built-in AIP Node Database, therefore if you do not wish to use this host, ensure you configure an alternative host in the Administration Center under the Global Configurations option:

You can find more details about this in AIP Console - 2.x - Initial configuration.

Embedded CAST Dashboards (Health and Engineering)

2.0.0-beta2 provides a new Docker container dedicated to the Health and Engineering Dashboards:

No configuration is required other than assigning the correct roles to users/groups to allow them to access the application data they need - this is explained in AIP Console - 2.x - Initial configuration. Access to the Dashboards is exactly as in v. 1.x:

Technical notes about embedded Dashboards

Initial start-up with no applications

When AIP Console starts up and no applications have been created you will see error messages in the dashboard container log. You will also notice an error if you try to access the Dashboards  (either Health or Engineering Dashboard). This is expected as AIP Console will not create the database that Dashboard will use until an application has been analyzed and a snapshot generated.

Once you have run an analysis and created a snapshot for an application these error messages will disappear.


You can assign the same access roles to your users/groups as are provided in standalone CAST Dashboards - see User roles. These roles are defined directly in Keycloak and are provided out of the box and are explained in Step 2 in AIP Console - 2.x - Initial configuration:

Click to enlarge

Synchronization of applications

Application data should be automatically synchronized between AIP Console and the embedded Dashboards, during the Application analysis/snapshot; namely during the "Create Snapshot" and "Publish to Health Dashboards" job steps. This synchronization process will reload application data from the CAST Storage Service(s) / PostgreSQL instance(s) to retrieve the latest information regarding analyses.

Should data not be synchronized correctly you can manually perform a synchronize action in the Administration Center under System Settings:

If you have upgraded from 2.0.0-beta1, you should run a manual Synchronize action to ensure that the applications that existed previously are now made available in the 2.0.0-beta2 Dashboards.

Importing Applications from AIP Console V1

  • This feature must NOT be considered as a full migration of an Application from v. 1.x to v. 2.x - any specific configuration applied to the Application in AIP Console v. 1.x will not be transferred to v. 2.x (for example a specific Reference Finder configuration applied in AIP Console 1.x). 
  • It is NOT possible to import existing Applications currently managed in CAST Management Studio.

If you would like to import any existing "test" applications that are currently managed with AIP Console v. 1.x into v. 2.x, then you can use the Import Applications feature available in the Administration Center:


  • The Delivery folder for the Applications you want to import must ALREADY be stored in the shared Delivery folder defined for AIP Console v. 2.x. In other words, the delivery folder path for the Application in v. 1.x must match the Delivery folder path defined for AIP Console v. 2.x. You can check the location of the Delivery folder for AIP Console v. 2.x by accessing the following URL and looking for the path defined by the entry
  • AIP Console v 2.x must have an AIP Node instance defined within it that is running the same release of AIP Core as used by the applications you want to import.
  • The Application schemas for the applications you want to import must be stored on a CAST Storage Service/PostgreSQL instance that has already been declared in AIP Console v 2x - see CAST Storage Service/PostgreSQL instance management above.


Click Import Applications and choose the host CAST Storage Service/PostgreSQL instance on which the schemas for your Application are stored - AIP Console will then scan the selected host and display a list of Applications that are not already managed in AIP Console v. 2.x:

Select the Application(s) you want to import, then click the Import button:

During the import, AIP Console will check that the selected Application's delivery folder can be located in the shared Delivery folder location. If this Delivery folder is located, a successful import will be indicated by the following message (the Application will also appear in the list of available applications in the Administration Center and in the AIP Console - Application Management screen:

 The following message indicates that AIP Console cannot find the Application's Delivery folder (in the shared Delivery folder location) and the import has failed:

Application and schema upgrade using AIP Console

The Application and schema upgrade process in AIP Console v.2 functions in exactly the same was as in AIP Console v 1.x (see Application and schema upgrade using AIP Console) with some small differences:

UI changes

  • The interface has changed slightly and Applications that can be upgraded are now indicated in the UI using a specific icon:

  • Clicking the icon will open a dialog box allow you to choose the target release of AIP Core:

Technical changes

Since AIP Nodes instances are now stateless, the upgrade paths available for selection depend entirely on the releases of AIP Core that your AIP Node instances are running:

  • If you have one AIP Node instance and you have upgraded AIP Core to a newer release on this AIP Node instance, you will be able to choose that specific release for all Applications managed in AIP Console which are eligible for upgrade (i.e. that are running an AIP Core release that is older than the release on your AIP Node instance):

  • If you have multiple AIP Node instances, the available upgrade paths for your Applications will be determined by the AIP Core releases running on all your AIP Node instances. Therefore, if you have two AIP Node instances both running different AIP Core releases, any Applications you select for upgrade can be upgraded to either of the AIP Core releases running on either AIP Node instance. Use the UI to select the target AIP Core release:

  • If you have multiple AIP Node instances each running a different release of AIP Core, and you choose to perform a multi-application upgrade (instead of a single Application upgrade) using the check boxes, then the available upgrade paths for all the Applications will be determined by the Application(s) running the most recent release of AIP Core. In the example below, there are two Applications (one running 8.3.36 and one running 8.3.37) and two AIP Node instances (one running 8.3.37 and 8.3.38). If you select both Applications for upgrade, then the target AIP Core release will be limited to 8.3.38. In this situation, if you want to choose the specific target release you require, then you should perform a single application upgrade instead.

Global Dynamic Links Rules files are no longer replicated to AIP Node instances

Default Dynamic Link Rules files (*.dlm.xml) available in the Administration Center under the Global Configurations option are no longer replicated to AIP Node instances as Application level rules. All *.dlm.xml files configured under the Global Configurations option will automatically be applied to all Applications.

It is still possible to define Default Dynamic Link Rules files (*.dlm.xml) at Application level (see Application - Config - Dynamic Links Rules) as in AIP Console v.1.x.

Move Architecture Studio from AIP Console to AIP Node instance

Architecture Studio features have been moved from AIP Console to the AIP Node instance. This change is nearly entirely invisible to end-users (except that Architecture Studio now uses the same upload folder for portfolio and application model files), however, the majority of the back-end operations have been simplified as there are no longer any upload/download of files between AIP Console and AIP Node, and no request wrapping, etc.

No AIP Node instances available

When no AIP Node instances are available (i.e they are down for maintenance, or network issues prevent them from reaching AIP Console), no functionality is available in AIP Console and a flashing warning message is displayed:

  • No labels