User Registry

It is possible to share the ‘user’ suffix of the user registry between the hybrid environments, but it is not possible to share the ISAM data which is stored in the user registry (this is usually stored in the ‘secAuthority=Default’ suffix).  There are a number of options available to overcome this restriction:

1. A separate user registry can be configured to house the ISAM data (i.e. the ‘secAuthority=Default’ suffix).  The original user registry can then be ‘federated’ into the environment to utilise the existing user data.  Information on how to federate a user registry into ISAM can be found in the knowledge centre.
2. The embedded user registry can be configured to house the ISAM data (i.e. the ‘secAuthority=Default’ suffix).  Please note that in a Docker environment the embedded user registry should only ever store static data.  This means that it should only ever really be used in conjunction with ISAM ‘basic’ users.  The original user registry can then be ‘federated’ into the environment to utilise the existing user data.
3. The existing user registry can be used by creating a separate ‘secAuthority’ suffix for each environment.  To do this:
   1. Create a new ‘secAuthority’ suffix in the user registry (e.g. ‘secAuthority=docker’)
   2. When configuring the runtime environment ensure that the ‘Domain’ matches the new ‘secAuthority’ suffix (e.g. ‘docker’).  Further information on configuring the runtime environment for different domains is available in the knowledge centre.

Policy Server

The ‘Policy Server’ is used within the appliance to manage the various ISAM servers and to also manage the policy database (i.e. ACLs/POPs/etc).  The dependency on an external Policy Server has been removed in the Docker environment so that WebSEAL can take advantage of the auto-scaling capabilities of Docker.  As a result of this it is not possible to share a Policy Server, and the policy database, between the appliance and Docker environments.

Federation/AAC Runtime

It is possible to share a single Federation/AAC runtime between both the appliance and Docker environments.  This would allow a single federation/AAC runtime to be shared by WebSEAL instances which are running in both the appliance and Docker environments.

Configuration Database

A database is used by the Federation and AAC capabilities to store configuration information.  In a Docker environment this database is ‘hidden’ from the administrator and embedded within the Docker container.  This means that it is not possible to share the configuration of the Federation/AAC capabilities between the different environments.

Runtime Database

A database is used by the Federation and AAC capabilities to store runtime information.

If an external runtime database is being used it can be shared by a runtime in both the appliance and Docker environments without any issues.

The ISAM appliance also provides an embedded runtime database capability – although it is not recommended that this be used in production.  If the embedded runtime database is being used it cannot be shared by runtimes in the appliance and Docker environments.  This is due to the fact that the embedded runtime database cannot be accessed from outside of the cluster (the Docker environment does not have the concept of a cluster).  In this situation separate runtime databases should be used, or the existing embedded runtime database data should be migrated to an external database.  The knowledge centre contains information on how to export existing embedded runtime database information and how to set up an external runtime database.

Distributed Session Cache

A single distributed session cache can be used in both the appliance and Docker environments.  If the distributed session cache server is running within the appliance it will however need to be configured to support external clients (the knowledge centre contains information on how to do this).