OpenID Connect Authentication

If you configure authentication through OpenID Connect (OIDC), users log in to the loft interface via an OIDC single sign-on (SSO) provider, such as Okta, KeyCloak, or dex. In this case, you usually do not create user accounts in loft and manage them through the OIDC provider that delegates the correct authentication to external providers, such as Github, Google or Microsoft.

OpenID Connect allows users to authenticate using a third-party provider which is useful if organizations want to:

  • provide self sign-up for their users
  • mirror the team memberships of their users from another provider
  • enforce security standards such as two factor authentication (2FA)

OpenID Connect authentication is a paid feature of loft, so please make sure this feature is enabled in your loft instance.

Setup Dex for Single Sign-On

If you do not already have an OIDC provider, such as dex, Okta or KeyCloak, this section will show you how to deploy dex to let your users authenticate through external OAuth providers, such as Github, Google or Microsoft.

For an extensive GitHub dex configuration take a look at the official dex documentation.

In order to configure Github for dex, you'll have to create a new Github Application for dex and copy the client id and secret to a file called dex-values.yaml:

config:
issuer: http://my-dex-issuer.com # The domain of where dex will be available at
storage:
type: kubernetes
config:
inCluster: true
web:
http: 0.0.0.0:5556
# Uncomment for HTTPS options.
# https: 127.0.0.1:5554
# tlsCert: /etc/dex/tls.crt
# tlsKey: /etc/dex/tls.key
connectors:
- type: github
id: github
name: GitHub
config:
clientID: APP CLIENT ID # The github application client id
clientSecret: APP CLIENT SECRET # The github application client secret
redirectURI: http://my-dex-issuer.com/callback # The domain where dex will be available at
loadAllGroups: true
useLoginAsID: true
oauth2:
skipApprovalScreen: true
staticClients:
- id: loft
redirectURIs:
- 'https://my-loft-domain.com/auth/oidc/callback' # The domain where loft is available
name: 'Loft'
secret: ANYSECRETKEY # The secret key that you will configure for loft

After creating the dex-values.yaml for your OAuth provider (see above), you can now install dex via helm:

helm install dex dex --repo https://kubernetes-charts.storage.googleapis.com \
--create-namespace \
--namespace dex \
--set ingress.enabled=true \
--set ingress.hosts[0]=my-dex-issuer.com \
-f dex-values.yaml \
--wait

Configure an OIDC Provider in loft

In order to configure an OIDC provider in loft, you'll have to edit loft config in the admin section in the loft UI. If you don't have an OIDC provider installed, check out the previous section for how to install dex.

loft OIDC config
Example loft OIDC config

An example configuration for an OIDC provider could look like this:

auth:
oidc:
issuerUrl: http://my-dex-issuer.com # Required: The issuer url of the OIDC provider
clientId: "" # Required: Client ID to use
clientSecret: "" # Required: Client Secret to use
usernameClaim: "email" # Optional: The username claim within the ID token to use as kubernetes subject and loft username (default: email)
usernamePrefix: "" # Optional: if specified, causes claims mapping to username to be prefix with the provided value (default: '')
groupsClaim: "" # Optional: GroupsClaim, if specified, causes loft to try to populate the user's groups with an ID Token field (default: '')
groupsPrefix: "" # Optional: if specified, causes claims mapping to group names to be prefixed with the value (default: '')
caFile: "/path.crt" # Optional: Path to ca cert of the issuer within the loft container (default: '')
type: "github" # Optional: if specified, changes the button appearance in the loft UI login page (default: '')

Save the config and you should be able to login via your preferred OIDC provider after a couple of minutes.

For each new user that logs into loft that has not yet logged into loft, loft will create a new user object.

You can also automatically assign users based on their ID Token groups to teams (see below), by configuring the Kubernetes Groups in a loft team.

Mirror Team Memberships

Instead of statically assigning users to a team, you can also define "Kubernetes Groups" as team members. This is an advantage if you are using OpenID Connect for authentication because your existing team structure can be easily reflected in loft without the need to manually replicate team memberships.

Example: Your organization is working with GitHub and has existing teams with different members and access permissions in GitHub. If you configure loft to use GitHub as OpenID Connect Auth Provider and you create the teams you want to give Kubernetes access in loft, you can define a group membership for the GitHub team name. The result of this is that all users who are part of the GitHub team will also become a member of the corresponding team in loft.

The screenshot below shows the group "analytics-team" being added as member of the Analytics Team.

Kubernetes Groups as Team Members
loft UI - Kubernetes Groups as Team Members

Disable Password Auth

To disable password authentication, change the loft config:

loft disbale password
Disable password authentication in loft

loft as OIDC Provider

Loft can also act as an OIDC provider for other services, e.g. a self-hosted container registry using Harbor.

To configure loft to act as an OIDC provider you will have to edit the loft config under the admin section in the loft UI:

loft oidc provider config
Example loft OIDC provider config

An example configuration for loft to act as an OIDC provider could look like this:

oidc:
enabled: true
clients:
- name: "Example Client"
clientId: "example"
clientSecret: "MYCLIENTSECRET"
redirectURIs:
- http://my-allowed-redirect-uri

To configure loft as an OIDC provider somewhere else, you can fill out the following fields with:

  • OIDC Provider Endpoint / Issuer: https://my-loft-instance.com/oidc
  • OIDC Client ID: example
  • OIDC Client Secret: MYCLIENTSECRET
  • Group Claim Name: groups
  • Available OIDC Scopes: offline_access,openid,groups,email,profile

With this configuration your loft users are able to authenticate in another application that supports OIDC based authentication like Kubernetes or Harbor.