Access and Authentication

Hybrid ISAM Environments

Share this post:

IBM Security Access Manager introduced support for Docker a few years ago with the publishing of the IBM Security Access Docker image.  The interest in Docker has recently increased and questions are now being asked around how to run both the appliance and Docker in the same environment.  This is especially useful for customers who have an existing ISAM environment and wish to explore the usage of Docker.

The good news is that it is possible to run both Docker and the ISAM appliances in the same environment.  However, there are a few restrictions which can make this challenging.   The biggest challenge to running a hybrid environment involves sharing certain services between the two environments.

The following figure provides an overview of the different services used by ISAM, and whether these services can be shared between the different environments:

 

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

 

Click here to rate this article

Rate this article :

IBM Security Access Manager Chief Programmer

More Access and Authentication stories
By Anthony Ferguson on March 15, 2019

Calling all IBM Tivoli Federated Identity Manager Customers

An open letter to our IBM Tivoli Federated Identity Manager customers,   As part of the IBM Security Access Manager development teams ongoing focus to support our customer base we are hoping to gain a better understanding as to how we can assist our IBM Tivoli Federated Identity Manager customers to migrate to our IBM […]

Continue reading

By nlloyd@us.ibm.com on March 14, 2019

ISAM Advanced Access Control Infomap to run info.js

In the past Level II Support has received Cases asking for various ways to force the running of the info.js script which is needed for AAC device registration.  The Knowledge Center section Configuring the attribute collection service notes to add the URL of info.js to the <head> block in the HTML landing page of your application.  […]

Continue reading

By Scott Exton on February 7, 2019

IBM Security Access Manager Helm Charts

IBM has published a Helm chart which can be used to easily deploy an IBM Security Access Manager environment within a Kubernetes infrastructure. What is Helm? In simple terms Helm is a management layer which sits in front of Kubernetes and can be used to manage the various elements of a Kubernetes environment (e.g. deployments […]

Continue reading