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 Martin Schmidt on May 17, 2019

Modernizing your B2C Portal Security – A thoughtful approach

As we have described the situation that many of our customers are in today, and our proposal for a better future state, we come to realize that for many, this transition is a journey, and a single big bang transition is not practical for many.  This blog entry will outline an approach to start such […]

Continue reading

By Martin Schmidt on May 4, 2019

Modernizing your B2C Portal Security – Desired End State

Proposition: As we have seen in part one of this series, managing customer identities for a portal can be a challenge and distraction for the business.  In this part of the series we will outline how a modernized solution for a portal security can simplify operations and free your team up to focus on the […]

Continue reading

By Martin Schmidt on April 19, 2019

Modernizing your B2C Portal Security – Introduction and Challenges

Introduction: Business to Consumer (B2C) is an incredibly common kind of identity and access management implementation. This implementation allows consumers to self-register and self-manage their digital identities for a given retailer or service provider.  The provider does this so that they can streamline subsequent interactions with consumers and to provide a seamless user experience while […]

Continue reading