View Only

Deploying IBM Sterling External Authentication Server Using Certified Containers, an OpenLDAP Server, and Configuring IBM B2Bi/SFG and IBM Control Center Monitor for User Authentication

By Connor McGoey posted 18 days ago

Like

Deploying IBM Sterling External Authentication Server Using Certified Containers, an OpenLDAP Server, and Configuring IBM B2Bi/SFG and IBM Control Center Monitor for User Authentication

Introductory Notes

Products

IBM Sterling External Authentication Server (SEAS) "allows you to implement extended authentication and validation services for IBM products, called client applications".

Intent

The purpose of this blog is to provide non-production details on how to deploy IBM Sterling External Authentication Server using certified containers, configure an authentication profile within SEAS and connect both a B2Bi/SFG instance and CCM instance to SEAS for authenticating users.

Additionally, this blog covers the steps necessary to deploy an OpenLDAP server which will house and handle users and their authentication.

The B2Bi/SFG LDAP Adapter supports LDAP versions 2 and 3 "to the extent that the Sun LDAP/JNDI libraries do". Refer to the LDAP Adapter for more information about restrictions on its restrictions. In this blog, Bitnami OpenLDAP will be deployed.

Additionally, IBM SEAS supports other authentication methods besides LDAP. Configuring for other authentication types would follow a similar process.

Finally, this blog will not cover deploying either IBM B2Bi/SFG or IBM CCM since those were covered in the previously referenced blogs.

Presumptions

Prior to following the installation steps in this blog, it is important to note that the environment and resulting deployments should not be used to replicate and/or produce a production environment for an LDAP server, SEAS, or the connections between SEAS and other IBM products. Additionally, a few presumptions are made with regards to these installations and their steps:

- - These installations create a set of deployments that are not air-gapped as they use the non-secure ports for SEAS and do not use any secure connection configurations or options. For more information on SEAS secure connections, refer to the SEAS documents and/or IBM product documents for necessary steps.
  - A SFG or B2Bi deployment to exist and be accessible from your cluster. In my case, I will use the SFG deployment I previously deployed in my blog "Installing IBM Sterling File Gateway and ITX / ITXA on Red Hat OpenShift Using Certified Container"
  - A CCM deployment to exist and be accessible from your cluster. In my case, I will use the CCM deployment I previously deployed in my blog "Installing IBM Sterling Control Center Monitor to Monitor SFG, SFTP Adapter Transfers, ITXA, and SSP Servers"
  - These instructions were developed on an OpenShift cluster running in the IBM Cloud. However, kubectl commands have also been provided and the instructions should work in Kubernetes as well.
  - The Helm releases pull images for the deployments from the IBM container registry, for which the environment is already configured with required permissions and entitlement. Steps for configuring your development environment to pull the necessary images are referenced in the "Pre-installation tasks" subsection of the IBM SEAS documentation.
  - The SEAS Helm chart is version 1.5.1 which used SEAS version 6.1.0.

Deployment / Configuration Order

1. Prior to deploying IBM SEAS, an LDAP server will need to be deployed and configured to handle incoming requests. I will deploy an OpenLDAP server which will be configured to have one non-admin user named ldapuser with the password ldapuserpassword for demonstration.
2. With the OpenLDAP server deployed, I will then deploy IBM SEAS and configure an authentication profile that will validate the username and password sent against the LDAP server.
3. B2Bi/SFG and CCM will then both be configured to use SEAS, which will both require creating a user that uses SEAS to authenticate.

Helm

This blog uses Helm v3.14.3 but will work with any Helm version >= 3.13.x. With regards to B2Bi or SFG, using a different/older version of Helm may change how the charts should be handled. For issues regarding Helm, refer to the Helm documentation on how to install Helm and the commands available to you via the Helm CLI. The IBM SEAS version 1.5.1 Helm chart is available under the Resources subsection. For the purposes of this blog, Helm allows for automating the containerized installations and upgrades of SEAS when used in conjunction with a provided and configurable YAML file and Helm chart. The YAML file is used to define relative configuration for the charts.

Bitnami OpenLDAP Installation

To begin the installation of OpenLDAP, I will first create a namespace for both the LDAP and SEAS instances. I'll name this namespace seas-nonprod which I can create by running either of the following commands:

oc new project seas-nonprod

kubectl create namespace seas-nonprod

Bitnami's OpenLDAP requires that the Service Account used to be given permissions. In OpenShift, this means that I need to provide the Service Account with the anyuid Security Context Constraint. My OpenLDAP deployment will be automatically configured to use the namespace's default Service Account. I'll run the following command:

oc adm policy add-scc-to-user anyuid -n seas-nonprod -z default

I can now deploy Bitnami OpenLDAP by running the following kubectl command which is a copy of example given on the Bitnami OpenLDAP docker image page. However, I have changed the username and password to ldapuser and ldapuserpassword:

kubectl run openldap-test --image bitnami/openldap:latest -n seas-nonprod \
--expose=true \
--port='1389' \
--env="LDAP_ADMIN_USERNAME=admin" \
--env="LDAP_ADMIN_PASSWORD=adminpassword" \
--env="LDAP_USERS=ldapuser" \
--env="LDAP_PASSWORDS=ldapuserpassword" \
--env="LDAP_ROOT=dc=example,dc=org" \
--env="LDAP_ADMIN_DN=cn=admin,dc=example,dc=org"

Specifying --expose=true and --port='1389' creates a ClusterIP service which will automatically select the OpenLDAP pod.

I'll need the service's IP later when configuring SEAS. I'll run either of the following commands to find it:

oc describe get services -n seas-nonprod | grep openldap

kubectl describe get services -n seas-nonprod | grep openldap

I'll refer to the IP later as <OpenLDAP IP> .

SEAS Installation

Pre-Installation

Prior to installing SEAS, I will need to setup the cluster and namespace with the setup scripts located in the Helm chart. These will create security Cluster Roles, Security Context Constraints, Role Bindings, etc. for us. From within the Helm chart's base directory, I run the following commands:

./ibm_cloud_pak/pak_extensions/pre-install/clusterAdministration/createSecurityClusterPrereqs.sh

./ibm_cloud_pak/pak_extensions/pre-install/namespaceAdministration/createSecurityNamespacePrereqs.sh seas-nonprod

Then I will create the SEAS secret located under ibm_cloud_pak/pak_extensions/pre-install/secret/ibm-seas-secret.yaml. I'll name this YAML file my-seas-secret.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: ibm-seas-secret
type: Opaque
stringData:
  sysPassphrase: <SEAS Pasphrase>
  adminPassword: <SEAS Admin Password>
  keyStorePassphrase: <SEAS KeyStore Passphrase>
  trustStorePassphrase: <SEAS TrustStore Passphrase>

In this blog, we are not going to be concerned with the KeyStore or TrustStore, but a passphrase for both is still required for installation.

To create the secret, I'll run either of the following commands:

oc create -f my-seas-secret.yaml -n seas-nonprod

kubectl create -f my-seas-secret.yaml -n seas-nonprod

Configuring override.yaml

Next, I will create a new file named override.yaml to specify only the values from the values.yaml file in the SEAS Helm chart that I will override for installation specifics. In this file, I'll place the following values to meet my specification:

license: true

lcenseType: non-prod

persistentVolume.useDynamicProvisioning: true

persistentVolume.storageClassName: "ibmc-file-gold-gid"

secret.secretName: "ibm-seas-secret"

serviceAccount.create: false

serviceAccount.name: "default"

route.enabled: true

Helm Install of SEAS

After saving the override.yaml file, I am now ready to install SEAS. To do so, I'll run the following Helm command from within the Helm chart's base directory:

helm install my-seas-deployment -f values.yaml -f override.yaml --timeout 90m0s

To verify my installation, I can run the following Helm command:

helm status my-seas-deployment -n seas-nonprod

I can also check the status of my SEAS by running either of the following commands:

oc describe pods -n seas-nonprod | grep seas

kubectl describe pods -n seas-nonprod | grep seas

Creating SEAS Authentication Profile

To create a SEAS Authentication Profile, I will first need to access the SEAS user interface. By specifying route.enabled: true in the override.yaml file, OpenShift has created a route for me which I can find by running either of the following commands:

oc get routes -n seas-nonprod

kubectl get routes -n seas-nonprod

The route is located under the HOST/PORT column. For me, the route is

my-seas-deployment-ibm-seas-seas-nonprod.us-south.containers.appdomain.cloud

Going to this domain brings me to the login page for SEAS. I use the user admin and password <SEAS Admin Password> that I provided in the secret to login.

Once logged in, I navigate to Settings > Listeners in the left side pane. Here, I will enable Non-Secure Listeners and ensure that the port is the same port specified in the Helm chart under service.nonSecure.servicePort which is 61365 by default. I can confirm this is the port by running either of the following commands:

oc describe service my-seas-deployment-ibm-seas -n seas-nonprod | grep non-secure

kubectl describe service my-seas-deployment-ibm-seas -n seas-nonprod | grep non-secure

The SEAS setting should look like this:

I will then click Save to ensure that HTTP connections are enabled.

I'll then navigate to Authentication in the side pane and then click the button Add Authentication + to configure my LDAP Authentication Profile.

I specify the following for the General configuration:

Authentication Type: LDAP

Name: userAuth

Host: <OpenLDAP IP>

Port: 1389

LDAP Principal to bind: Specify user DN

cn ={userid} ou=users,dc=example,dc=org

After specifying the General configuration, I will continue to click Next until I can save the profile. I then click Save to finish.

Configuring B2Bi/SFG for SEAS Authentication

Creating B2Bi/SFG Network Policy for SEAS

Before B2Bi/SFG can make requests to my SEAS server, I need to ensure that outbound traffic from my B2Bi/SFG namespace allows traffic to SEAS. I can do this by adding a Network Policy within my B2Bi/SFG namespace. Recalling from my B2Bi/SFG blog that the namespace name is sfg-itxa-nonprod and the release name for the deployment is my-sfg-release, I will put the following definition in a YAML file named seas_network_policy.yaml:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
   name: 'seas-egress-policy'
   namespace: sfg-itxa-nonprod
spec:
  podSelector:
    matchLabels:
      release: my-sfg-release
  egress:
    - ports:
      - protocol: TCP
        port: 61365
  policyTypes:
    - Egress

I'll then create the Network Policy by running either of the following commands:

oc apply -f seas_network_policy.yaml

kubectl apply -f seas_network_policy.yaml

IBM SEAS Helm chart handles creating Network Policies that allow ingress traffic by default. The specification for the Network Policy is in the values.yaml / override.yaml file under networkPolicy.ingress.

Copying Files from SEAS and Configuring for B2Bi/SFG

Referring to the B2Bi/SFG docs, I will need to obtain some files from SEAS and place them within my B2Bi/SFG instance. To obtain these files, I will first need to open a shell into my SEAS pod. To find the name of my SEAS pod I'll run either:

oc get pods -n seas-nonprod

kubectl get pods -n seas-nonprod

For me, the pod name is my-seas-deployment-ibm-seas-0. I can then open a shell into the pod by running either of the following:

oc rsh my-seas-deployment-ibm-seas-0

kubectl exec --stdin --tty my-seas-deployment-ibm-seas-0 -- /bin/bash

I need to locate and take note of the following files:

- - authentication_policy.properties_seas-auth_ext.in
  - security.properties_seas-sso_ext.in
  - servers.properties_seas-auth_ext
  - servers.properties_seas-sso_ext
  - seas-sso-impl.jar
  - seas-client.jar
  - hadrian-client.jar
  - jdom-<version>.jar
  - seas-sso.jar
  - seas-sso.properties
  - seas-auth.properties

Where jdom-<version>.jar is the specific file within the SEAS pod.

I can find all these files by individually running a find command and ensuring each file is located somewhere under the .../sfg-sso-plugin/ directory using a command of the form:

find / -type f -regex ".*sfg.*<File Name>" 2>/dev/null

Or you can run my script from within the SEAS pod which will give you the location of each file:

#!/usr/bin/env bash
files=( 
    ".*sfg.*authentication_policy\.properties_seas-auth_ext\.in"
    ".*sfg.*security\.properties_seas-sso_ext\.in"
    ".*sfg.*servers\.properties_seas-auth_ext"
    ".*sfg.*servers\.properties_seas-sso_ext"
    ".*sfg.*seas-sso-impl\.jar"
    ".*sfg.*seas-client\.jar"
    ".*sfg.*hadrian-client\.jar"
    ".*sfg.*jdom-.+\.jar"
    ".*sfg.*seas-sso\.jar"
    ".*sfg.*seas-sso\.properties"
    ".*sfg.*seas-auth\.properties"
)
for file in "${files[@]}"; do
    find / -type f -regex "${file}" 2>/dev/null
done

With the location of each file written down, I can now exit out of the SEAS pod and run either of the following commands for each file. I'll do this from my local machine in a folder SEAS_Files where I will temporarily keep them:

oc cp my-seas-deployment-ibm-seas-0:/<File Location> ./SEAS_Files/<File Name>

kubectl cp my-seas-deployment-ibm-seas-0:/<File Location> ./SEAS_Files/<File Name>

I will then edit the servers.properties_seas-auth_ext and servers.properties_seas-sso_ext files to ensure that the seas-auth and seas-sso properties are uncommented and have <SI_install_dir> changed to the installation directory of SFG/B2Bi which for me is /ibm/b2bi/install (this can be found within any of your B2Bi/SFG pods using a similar find command from above). After changing, the properties should be uncommented and look like this in their respective files:

seas-auth=/ibm/b2bi/install/properties/seas-auth/1.0/seas-auth.properties

seas-sso=/ibm/b2bi/install/properties/seas-sso/1.0/seas-sso.properties

Finally, in my seas-sso.properties file I will add the connection details for my SEAS server:

EA_HOST=<SEAS Service IP>

EA_PORT=61365

Where <SEAS Service IP> is the IP from the SEAS service, which can be found via:

oc describe service my-seas-deployment-ibm-seas -n seas-nonprod

kubectl describe service my-seas-deployment-ibm-seas -n seas-nonprod

The seas-auth.properties file is already configured to use the userAuth authentication profile. If you chose a different name for your authentication profile in SEAS, change the following line to match your authentication profile name:

authentication_2.profile=userAuth

Creating B2Bi/SFG Custom Resources Init Container

The next step for me is to create a custom resources init container which will copy DB2 driver JAR and my copied SEAS JARs into the /resources and /resources/seas folders respectively.

First, I'll create a folder on my local machine which I'll call ../SEAS_Resources_Init. In this directory I will make a sub-directory ../SEAS_Resources_Init/seas. With the directory structure setup, I will copy my DB2 JDBC driver into the ../SEAS_Resources_Init directory and the SEAS JAR files (which I previously saved on my local machine within the SEAS_Files folder) into the ../SEAS_Resources_Init/seas folder:

cp <Path to DB2 JDBC Driver> ../SEAS_Resources_Init

cp <Path to SEAS_Files>/seas-client.jar ../SEAS_Resources_init/seas

cp <Path to SEAS_Files>/jdom-<version>.jar ../SEAS_Resources_init/seas

cp <Path to SEAS_Files>/hadrian-client.jar ..SEAS_Resources_init/seas

cp <Path to SEAS_Files>/seas-sso-impl.jar ..SEAS_Resources_init/seas

I will then create a Dockerfile in the base ../SEAS_Resources_Init directory and place the following in it:

FROM registry.access.redhat.com/ubi8/ubi-minimal:8.7

RUN mkdir /resources
RUN mkdir /resources/seas

#Add DB2 JDBC Driver JAR
COPY ./db2jcc4.jar /resources

#Add SEAS JARs
COPY ./seas/*.jar /resources/seas

ENTRYPOINT [“sh”, “-c”, “cp -rv /resources/* /ibm/resources”]

After saving my Dockerfile, I'll run the following commands from within the ../SEAS_Resources_Init directory to build, tag, and push my image to a registry accessible to my cluster:

docker build -t b2bi-seas-init:1.0 .

docker tag b2bi-seas-init:1.0 <Your Registry URL>/b2bi-seas-init:1.0

docker push <Your Registry URL>/b2bi-seas-init:1.0

Putting SEAS Files in B2Bi/SFG

With my resources PVC created, I now need to modify my B2Bi/SFG Helm chart and override.yaml file.

First, I will copy the following files into the /config folder within the base level of the Helm chart:

- - authentication_policy.properties_seas-auth_ext.in
  - security.properties_seas-sso_ext.in
  - servers.properties_seas-auth_ext
  - servers.properties_seas-sso_ext

Then, in my B2Bi/SFG override.yaml file, I'll change the following values:

integrations.seasIntegration.isEnabled: true

appResourcesPVC.enabled: true

appResourcesPVC.preDefinedResourcesPVCName: sfg-resources-pvc

resourcesInit.enabled: false

The last thing I need to do before running a Helm upgrade is to specify my resources init container. In my override.yaml file, I will change the resourcesInit section to the following:

resourcesInit:
  enabled: true
  image:
    repository: <Your Registry URL>
    name: b2bi-seas-init
    tag: 1.0
    digest: ""
    pullPolicy: "IfNotPresent"

I'll then run a Helm upgrade on my B2Bi/SFG release:

helm upgrade my-sfg-release -f override.yaml --timeout 90m0s <Path to B2Bi/SFG Helm Chart>

Once B2Bi/SFG is re-deployed and running, I'll need to access the Customization UI. I can find the route for the Customization UI by running either of the following commands:

oc get routes -n sfg-itxa-nonprod | grep customization

kubectl get routes -n sfg-itxa-nonprod | grep customization

I'll login with my admin credentials and then navigate to the CustomJar option on the top of the screen:

I'll then create the following three custom JARs:

Vendor Name: seas-sso

Vendor Version: 1.0

Jar Type: Library

Target Path: Every

File: seas-sso.jar

Vendor Name: seas-sso

Vendor Version: 1.0

Jar Type: Property File

Target Path: Every

File: seas-sso.properties

Vendor Name: seas-auth

Vendor Version: 1.0

Jar Type: Property File

Target Path: Every

File: seas-auth.properties

Finally, I will restart the B2Bi/SFG pods by deleting them. The ASI, AC, and API deployments will handle creating new pods once they are detected as deleted:

oc delete pod -n sfg-itxa-nonprod <ASI Pod Name>

oc delete pod -n sfg-itxa-nonprod <AC Pod Name>

oc delete pod -n sfg-itxa-nonprod <API Pod Name>

Or, if using kubectl:

kubectl delete pod -n sfg-itxa-nonprod <ASI Pod Name>

kubectl delete pod -n sfg-itxa-nonprod <AC Pod Name>

kubectl delete pod -n sfg-itxa-nonprod <API Pod Name>

Creating a New User in B2Bi/SFG

SEAS authentication is now configured in B2Bi/SFG. I will now create a user that uses my SEAS server for authentication.

Recall the B2Bi/SFG Verification section of my B2Bi/SFG blog where I show how to access the web UI.

I'll first navigate to User Accounts under the Accounts section. Here, I'll click Go! to create a new account:

On the page for creating a new user, I'll click the option External, and give the following definition:

The User ID I give is ldapuser which is the only user in my OpenLDAP server.

I continue to click Next until I get to the User Information page. Here I'll give any name and surname:

On the Confirm page I confirm my user information and then click Finish:

Verifying B2Bi/SFG SEAS Configuration

With everything configured for B2Bi/SFG and a user made, I can verify everything is correctly configured by trying to log back into the B2Bi/SFG.

First, I'll try to login as ldapuser with the wrong password such as wrongpassword:

Then, I'll try to login as ldapuser with the correct password ldapuserpassword which I specified during my OpenLDAP installation. This will bring me into the B2Bi/SFG UI as normal:

Configuring CCM for SEAS Authentication

Enabling and Configuring External Auth Server

To enable SEAS authentication in CCM, I will first login to CCM.

Recall the Configuring CCM to Monitor SFG - Verification subsection of my CCM blog where I describe how to access the CCM user interface.

After logging in as admin, I navigate to the Menu button on the top right of the screen and select System Settings:

On the left pane, I'll navigate to External Auth Server and put my SEAS server configuration here. I'll specify my <SEAS Service IP> and userAuth authentication profile (change if you named your authentication profile something else). So, if your <SEAS Service IP> were 1.1.1.1 for example: