Configuring single sign-on (SSO) for applications in containers

Setting up image build-time configuration

1. Define the build-argument (ARG) SEC_SSO_PROVIDERS in your Dockerfile with a space-delimited list of the identity providers to use.

   If more than one is specified, the user can choose which one to authenticate with. Valid values include oidc oauth2 facebook twitter github google linkedin.

   ARG SEC_SSO_PROVIDERS="(your choices go here)"

   You can also use multiple OIDC and OAuth 2.0 providers for authentication. For example, set the following statement in your Dockerfile.

   ARG SEC_SSO_PROVIDERS="google oidc:provider1,provider2
               oauth2:provider3,provider4"

   The provider name must be unique and must contain only alphanumeric characters. The name of the provider is specified for the id attribute in the server configuration (by default, oidc or oauth2). The name of the provider is also used to compose the corresponding environment variables by following this naming convention.

   SEC_SSO_<provider-name>_<attribute-name>

   For example,

   SEC_SSO_PROVIDER2_CLIENTSECRET

2. To use HTTPS, specify ARG TLS=true in your Dockerfile. Most providers require the use of HTTPS.
3. Include the RUN configure.sh command in your Dockerfile for your settings to take effect.

Setting up configuration needed at image build time or container deployment time

Set up HTTPS. Providers typically require HTTPS.

1. Enable automatic trusting of certificates.
   • To automatically trust certificates from identity providers:

     ENV SEC_TLS_TRUSTDEFAULTCERTS=true

   • To automatically trust certificates issued by the Kubernetes cluster:

     ENV SEC_IMPORT_K8S_CERTS=true

   In some container environments, the pod needs for these values to be specified.

2. Set up provider-specific configuration requirements. The necessary variables can be supplied in several ways:
   • At build time, they can be variables in a server.xml file. For example,

     <variable name="variable_name" value="value" />

   • At build time, they can be ENV variables in the Dockerfile, although this configuration is less secure. For example,

     ENV name=value

   • They can be passed as environment variables to the container when it is deployed.
   • They can be supplied in a deployment YAML file or by the WebSphere® Liberty operator, which passes them to the container at deployment time.
   Client ID and client secret are obtained from the provider. The provider sends the browser back to the protocol, host, and port defined in the SEC_SSO_REDIRECTTORPHOSTANDPORT variable after authentication. For example,

   https://myApp-myNamespace-myClusterHostname.example.com

3. Set up other variables that might be needed. These other variables are documented in detail in the Open Liberty Documentation under each type of provider. The oidc and oauth2 configurations can be used with any provider that uses the OpenID Connect 1.0 or OAuth 2.0 specifications.

A sample Dockerfile and WebSphere Liberty operator YAML file are available from the WASdev GitHub repository.