User Provider

Concepts

The container is secured by default. Users and services must authenticate before they are allowed to use the container. Containers built from within the Digital Enterprise Suite (DES) are automatically configured to use that DES instance as its authorization server. No additional configuration is required aside from network connectivity between the deployed DDC and the DES instance.

Important security aspects that should be taken into account when building and running digital distributed containers:

  1. Containers are built for in a given execution environment e.g. prod

  2. Security restrictions (access control list) from the execution environment are included in the container

  3. Access rights are enforced based on execution environment settings

Users that have access to DES will also have access to container’s services as long as they are granted roles within the execution environment the container was built from.
there is no post build synchronisation of the environment access contorl list after the DDC container has been built. This removes the runtime dependency between the DDC to the Digital Enterprise Suite.

Security of the Digital Distributed Containers is based on the OpenID Connect standard to allow easy configuration with external OpenID Connect providers as an alternative to the Digital Enterprise Suite.

Using an external OIDC Identity Provider

When using an external OpenID Connect (OIDC) provider not all security features are available. Information about the groups that a user is a member of are not available (by default), execution environment access is not synced at runtime thus might result in users not being granted to perform certain operations.

The OIDC provider becomes the source of information for DDC authentication and authorisation. Authentication is mainly based on validation of the tokens supplied to the DDC while authorisation follows the access list that is bundled with the container image and group claim from the OIDC token.

Following are the token claims supported:

  • email - associates user with identity (CAL) in DDC - string claim

  • name - displays name of the user - string claim

  • groups or namespaced version of it (https://trisotech.com/groups) - list of group names matching those defined in DES and assigned to environment - array claim

  • picture - url that represents the picture of the user (png or svg) - string claim

  • environment_access - optional claim in case override of access list in DDC is required e.g. user had performer right at the time of building DDC but now has admin right - this claim allows to do so by supplying int claim with predefined values (Admin - 8, Performer - 4, Deployer - 2, Builder - 1). These values can be summed to include multiple access rights (12 to include Admin and Performer).

Disabling Security

Security can be disabled to be able to run containers in an open mode without requiring authentication. This could be required if there is no connectivity between the container and the DES or if you want to implement an external authorization mechanism (api gateway or otherwise).

Using the following helm variable on installation or upgrade disables the security:

--set ddc.SSO_METHOD=none

Using an external OpenID Connect provider

To be able to use external OpenID Connect provider, the following environment variables must be provided when starting the container

Using the following helm variable on installation or upgrade use an external OpenID Connect provider:

--set ddc.OIDC_ISSUER=https://...
--set ddc.OIDC_CLIENT_ID=XXX-XXX-XXX
--set ddc.OIDC_CLIENT_SECRET=XXX-XXX-XXX

Complete list of configuration variables and their description

Configurations Variable Description

OIDC_ISSUER

URL to the provider that acts as issuer and also the starting point of discovery of OpenID Connect configuration.

OIDC_CLIENT_ID

Client id of the application created in the Open ID Connect provider.

OIDC_CLIENT_SECRET

Corresponding client secret created in the Open ID Connect provider. Required when the Open ID Connect provider does not allow to use PKCE or requires both client secret and PKCE.

OIDC_PKCE_REQUIRED

Configures OIDC client to ensure that both client secret and PKCE challange is used.

If group-based access is needed, the OpenID Connect provider must include a groups claim in the ID token, listing the user’s group names as an array. This is configured in the client application’s settings on the identity provider. We can also take group names from the namespaced version of the claim: https://trisotech.com/groups.