Security/authentication approach

The 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:

• 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 Configure authentication and roles using Keycloak - v. 2.x).
• The Security tab has been removed from the Administration Center because global level roles are now configured directly in Keycloak (see Configure authentication and roles using Keycloak - v. 2.x). Resource level roles are still configured directly 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 Console v 1.x.

Node instances

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

• 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 Node instance)
  • and multiple database icons:  (shows the host name and port number of the CAST Storage Service/PostgreSQL instance that the Node can access
• The number of applications associated to the Node instance is no longer displayed because applications are not attached to any Node - instead Console will automatically choose the Node to use for the required job - you can see which Node instance is running the job using the live log panel:

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

Initial start-up wizard

The initial start-up wizard has been modified - see Complete start-up wizard - v. 2.x. 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 Node Database (delivered as a Docker container with 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 Console v.2. See Administration Center - Settings - CSS and Measurement settings.

Analysis/snapshot schema storage

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

By default, one database connection will already be predefined. This is a connection to the PostgreSQL Node database provided as a Docker container and is used to store options and settings common to all 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 Console will be available to any 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 Console:

Measurement schema

The Measurement schema is required for consolidating snapshot data from all 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 Console is preconfigured to use the built-in 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:

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 Configure authentication and roles using Keycloak - v. 2.x. Access to the Dashboards is exactly as in v. 1.x:

Technical notes about embedded Dashboards

Initial start-up with no applications

When 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 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.

Roles

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 Configure authentication and roles using Keycloak - v. 2.x:

Click to enlarge

Synchronization of applications

Application data should be automatically synchronized between 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:

Importing Applications from CAST Management Studio

If you would like to import into Console ≥ 2.x any existing applications that are currently managed entirely with CAST Management Studio, then you can use the Import Applications feature available in the Administration Center. See Administration Center - Applications for more information.

Application and schema upgrade using Console

The Application and schema upgrade process in Console v. 2.x functions in exactly the same way as in 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 Node instances are now stateless, the upgrade paths available for selection depend entirely on the releases of AIP Core that your Node instances are running:

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

• If you have multiple Node instances, the available upgrade paths for your Applications will be determined by the AIP Core releases running on all your Node instances. Therefore, if you have two 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 Node instance. Use the UI to select the target AIP Core release:

• If you have multiple 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 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 Node instances

Default Dynamic Link Rules files (*.dlm.xml) available in Administration Center - Settings - Default Dynamic Links Rules are no longer replicated to 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 Console v.1.x.

Move Architecture Studio from Console to Node instance

Architecture Studio features have been moved from Console to the 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 Console and Node, and no request wrapping, etc.

No Node instances available

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