High Availability Configuration for SAML 2.0 and Kerberos Single Sign-On in Oracle Analytics Server using Docker Container

April 24, 2024 | 5 minute read
Veera Raghavendra Rao Koka
Consulting Member of Technical Staff
Text Size 100%:

REDWOOD

Using a hybrid custom SSO environment approach, you can configure SAML 2.0 and Kerberos single sign-on (SSO) for Oracle Analytics Server (OAS). The custom SSO configuration follows the steps documented in the blog SAML 2.0 and Kerberos Single Sign-On Configuration for Oracle Analytics Server (and Oracle Support Doc ID 2761678.1). See also, Configure Custom SSO Environments.

This blog covers the high availability configuration of the SAML 2.0 and Kerberos SSO Docker containers.

Prerequisites

Configure SSO for OAS for a single OAS server or cluster nodes of the OAS server. Follow the steps in the blog (or Doc ID 2761678.1).

Configure a single SAML 2.0 and Kerberos SSO Docker container on the OAS server or other OCI compute instance, with single or multiple OAS server nodes as the backend to the Docker container.

Architecture

This diagram shows the authentication flow in the SAML SSO Docker container:

ha_sso1

This diagram shows the authentication flow in the Kerberos SSO Docker container:

ha_sso2

 

Architecture 1

  1. Load balancer balancing between the two OASSO Docker containers.
  2. Each OASSO Docker container has a dedicated OAS server as its backend.
  3. Session cookie persistence is managed at the OASSO Docker containers.

ha_oasso3

Architecture 2

  1. Load balancer balancing between the two OASSO Docker containers.
  2. Each OASSO Docker container load balancing between the two OAS servers as its backend.
  3. Session or cookie persistence is managed at the OASSO Docker containers.

ha_oasso4

High Availability

Scenario 1

Using architecture 1, configure the first OASSO Docker container on OAS Server1, or OCI compute instance1 with a dedicated OAS server as the backend server.

In this configuration, the analytics.conf file in the ${Docker_Zip_Extracted_Location}/oasso/{saml_or_kerb}/conf.d folder is configured to have a dedicated OAS server as its backend.

Scenario 2

Using architecture 2, configure the first OASSO Docker container on OAS Server1, or OCI compute instance1 with the OAS cluster nodes as its backend servers.

In this configuration, the analytics.conf file is not included in the httpd.conf file in the ${Docker_Zip_Extracted_Location}/oasso/saml/conf folder.

Rename the files analyticsclustered.conf.txt and workers.conf.txt to analyticsclustered.conf and workers.conf in the folder ${Docker_Zip_Extracted_Location}/oasso/{saml_or_kerb}/conf.d.

Include the analyticsclustered.conf and workers.conf in the httpd.conf file, which has the two OAS servers as the backend.

Test that the SSO configuration is successful.

When the first OASSO Docker environment is successful, configure the second docker container for high availability.

Configure the Second Docker Container

On OAS server1 (or OCI compute instance1):

  1. ZIP the extracted file ${Docker_Zip_Extracted_Location}/oasso/oasso.tar
    • gzip ${Docker_Zip_Extracted_Location}/oasso/oasso.tar
  2. Copy the oasso.tar.gz file to the host machine for the second Docker container.

On OAS server2 (or OCI compute instance2):

  1. Install the Docker engine.
  2. Install Python 3.6 or higher, gunicorn, lxml and flask packages required for the configUI utility.
  3. Perform all the steps in Support Doc ID 2761678.1.

Configure SAML SSO or Configure Kerberos SSO to Run the configUI Utility

For SAML SSO:

To configure Docker containers on both hosts:

  1. Use the same load balancer DNS Name in the URL. For example: https://load-balancer.com/analytics
  2. Use the same load balancer SSL certificates when configuring the containers.
  3. Use the same SAML IDP Metadata XML file.
  4. In the OAS Configuration page of the configUI utility, use the respective IP address of the OAS server.
  5. Ensure the backend docker containers are identified through the frontend load balancer to have the same information as the SP Metadata details and signing/encryption certificates.
  6. Skip the SP Metadata exchange between the SAML IDP and the second container, as this step is completed in the first host.
  7. At this stage, both containers are running individually with the same information but they can't maintain session or cookie persistence. This can cause login and session failures for end users.
  8. Edit the shibboleth2.xml file to configure session persistence and then restart.

    vi ${Docker_Zip_Extracted_Location}/oasso/saml/shibboleth/shibboleth2.xml

    Change the section:

    <Sessions lifetime="28800" timeout="3600" relayState="ss:mem" checkAddress="false" handlerSSL="true" cookieProps="https" redirectLimit="exact">

    To:

    <Sessions lifetime="28800" timeout="3600" relayState="ss:mem" checkAddress="false" consistentAddress="false" cookieName="oasprod" handlerSSL="true" cookieProps="https" redirectLimit="exact">

Restart the Services

service oasso-ctl stop

service oasso-ctl start

For Kerberos SSO:

Create the keytab file using the ktpass command with the Load Balancer DNS Name as the principal

e.g. ktpass -princ HTTP/<load-balancer-dnsname>@KERBREALMNAME.COM -mapuser ser_lb-hostname -pass Oracle123 -crypto All -ptype KRB5_NT_PRINCIPAL -out C:\lb-hostname.keytab -kvno 0

If you access only through load balancer keytab file with above command is sufficient.

If you also access through the respective OAS server 1 and 2 hostnames for internal use, set spn for the oas server hostnames as well.

setspn -A HTTP/oas-server1.com ser_lb-hostname

setspn -A HTTP/oas-server2.com ser_lb-hostname

When configuring docker containers on both hosts:

  1. Use the same Load Balancer DNS Name in the URL, e.g., https://load-balancer.com/analytics.
  2. Use the same Load Balancer SSL Certificates while configuring the containers.
  3. Use the same REALM Name, krb5.conf file, Service Name with LB-hostname, and keytab files that were used while configuring the first container.
  4. In the OAS Configuration page of the configUI utility, use the respective IP address of the OAS server.
  5. Since Kerberos SSO does not have a configuration area for session persistence, you may need to configure this at your Load Balancer.

Restart the Services

service oasso-ctl stop

service oasso-ctl start

NOTE: The rest of the steps remain the same for both SSO configurations.

Call to Action

This blog covers configuring SAML 2.0 and Kerberos SSO using the Docker containers.  Once you try it, share your results on the Oracle Analytics Community. 

Refer to more similar blogs, such as Single Sign-On Solutions for Oracle Analytics Server on On-Premise and on Oracle Cloud.

REDWOOD

 

Veera Raghavendra Rao Koka

Consulting Member of Technical Staff

Oracle Analytics Service Excellence, CEAL Team


Previous Post

Automating Oracle Analytics Server Silent Installation, Critical Patch Update, and Configuration on Linux

Next Post


Configuring Multiple Docker Containers for SAML and Kerberos SSO on a Single Host to Support Multiple OAS Environments