1. Preparing the necessary domain certificates.

• Download the full certificate chain for google.com

echo | openssl s_client -connect accounts.google.com:443 -showcerts | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /root/kubernetes/oms/certs/google_chain.crt

• This will extract the root, intermediate and leaf certificate from the chain

awk 'BEGIN{c=0;} /BEGIN CERTIFICATE/{c++} {print > "/root/kubernetes/oms/certs/google_cert" c ".crt"}' /root/kubernetes/oms/certs/google_chain.crt

• This will verify all three certificates

for i in 1 2 3; do echo "===== cert$i ====="; openssl x509 -in /root/kubernetes/oms/certs/google_cert$i.crt -noout -subject -issuer; done

• Generate a dummy trust store file with a temporary certificate in it.

keytool -genkeypair -alias temp -keyalg RSA -keysize 2048 -keystore truststore.jks -storepass mypassword -keypass mytemppassword -dname "CN=temp"

• Remove the temporary certificate from the above keystore file.

keytool -delete -alias temp -keystore truststore.jks -storepass mypassword

• Add the google certificates to the trust store.

keytool -importcert -alias google_cert1 -file google_cert1.crt -keystore truststore.jks -storepass mypassword -noprompt

keytool -importcert -alias google_cert2 -file google_cert2.crt -keystore truststore.jks -storepass mypassword -noprompt

keytool -importcert -alias google_cert3 -file google_cert3.crt -keystore truststore.jks -storepass mypassword -noprompt

• Verify if the google certs are added to truststore.

keytool -list -v -keystore truststore.jks -storepass mypassword

2. We are going to generate custom om-app image using the DTK's om-runtime container. The om-agent image need not be customized for OIDC implementation.

• Login to om-runtime container.

docker exec -it om-runtime bash

• Modify the /opt/ssfs/runtime/properties/sandbox.cfg file and add/update the below property.

ENABLE_IBMID_AUTHENTICATION=true

• Navigate to image build folder.

cd /opt/ssfs/runtime/container-scripts/imagebuild

• Generate the custom image using the below command

./generateImages.sh --MODE=app --EXPORT=false --WAR_FILES=smcfs,sbc,sma,isccs,wsc,isf,icc --OM_TAG=10.0

• Export this newly generated custom image to a container registry.

3. Add the OIDC credentials in OMS secret

• Modify oms-secret.yaml file and add the following:
  • stringData.trustStorePassword: '<trust_store_password>'
  • stringData.oidcClientId: '<obtained_from_google>'
  • stringData.oidcSecret: '<obtained_from_google>'
• Apply the secret file again

kubectl apply -f oms-secret.yaml

4. Add the newly created trust store to a config map

• Create a new configmap with the trust store file

kubectl create configmap oms-oidc-truststore --from-file=/root/kubernetes/oms/certs/truststore.jks -n oms

5. Modify the OMEnvironment file to incorporate the OIDC configurations

• Modify the oms-environment.yaml file and add the above config map as additional mount

spec:
  additionalMounts:
    configMaps:
      - name: oms-bindings
        mountPath: /opt/ssfs/bindings/.bindings
        subPath: .bindings
      - name: oms-oidc-truststore
        mountPath: /opt/ssfs/certs/truststore.jks
        subPath: truststore.jks

• Modify the oms-environment.yaml file and define the trust store location under security

spec:
  security:
    ssl:
      trust:
        storeLocation: "/opt/ssfs/certs/truststore.jks"
        storeType: JKS
        trustJavaCACerts: true

• Modify the oms-environment.yaml file and add the oidc parameters

spec:
  common:
    appServer:
      ports:
        http: 9080
    oidc:
      enabled: true
      provider: google
      discoveryurl: https://accounts.google.com/.well-known/openid-configuration
      logouturl: https://www.google.com/accounts/Logout

• Modify the oms-environment.yaml file by changing the image and tag of the om-app and om-agent images as per the custom image generated.
• Apply the new environment file

kubectl apply -f oms-environment.yaml

• Wait for the application pods to come up.

Authenticating with OIDC:

One important point to remember while using OIDC is, only the authentication happens at the OIDC layer. The authorization still happens inside the Sterling OMS application.

Once the application pods are up, access the application URLs in the browser. The browser will automatically redirect to Google login page. Login with any Google email ID. Upon successful login, there will be two outcomes.

• If a Sterling user is already created with contact email with which we login to Google, then the user is automatically logged in and redirected to the home page of the application.
• If there is no Sterling user linked to the Google email, then the browser will redirect back to OMS application login page. We have to login again (only for the first time) with the Sterling credentials. Upon login, the Google email will be linked to the Sterling user. During the subsequent login, the user can directly login with Google email.

What This Means for Sterling OMS

By integrating OMS with a trusted identity provider and leveraging standards-based authentication, organizations gain improved security, centralized identity management, and a streamlined user experience. This approach not only aligns Sterling OMS with modern enterprise identity practices but also makes the system more scalable, maintainable, and easier to integrate within broader IT ecosystems. With OIDC in place, businesses can confidently support secure access across users, applications, and services while future-proofing their OMS environment for evolving security needs.

Authors

Hariprasad As @Hariprasad AS

Pallavi Sinha @pallavi.sinha25