In addition to authentication via token, administrators can choose to use an OIDC-enabled identity provider (e.g. Azure AD, Okta) as an alternative authentication method in order to enable single sign-on (SSO) or multi-factor authentication (MFA) for end-users. Using OIDC also provides access to permission based features in redgate Clone.

Contents

Identity Provider Requirements

Our authentication process uses a specific OIDC authentication flow, called device flow, which means that any identity providers that do not provide this as an option are incompatible.

The specific requirements for an identity provider are:

1. It supports OpenID Connect.
2. It supports device flow without requiring a client secret for any authentication requests.
3. Access tokens are returned as JWT tokens rather than as plain strings.

While we have not investigated all identity providers, of the ones we have tested we are confident that Okta and Azure AD meet these requirements, while Google Cloud Platform (GCP) and GitHub do not.

Setting Up an OIDC-enabled Identity Provider in redgate Clone

In order to enable redgate Clone to use an OIDC-enabled identity provider, you’ll need to add some configuration values via the Admin Console.

At the bottom of the Admin Console’s configuration tab there is a section titled OpenID Connect (OIDC) Settings. You’ll need to enter a few values that you’ll find in your OIDC-enabled identity provider’s configuration page.

1. The URI pointing to the identity provider’s /.well-known/openid-configuration metadata. (Where to find: Okta, Azure AD).
2. The client ID of your identity provider application (Where to find: Okta, Azure AD).
3. The audience for your access token, contained within the aud claim of the token. (Where to find: Okta, Azure AD).
4. Any additional scopes that may be required for an authentication request. This is optional dependent on your identity provider. Azure AD, for example, requires an additional API scope, which would then be added here. Okta has no such requirement.
5. The claim name that represents a unique username in your identity provider. The value contained in this claim within the access token will be attached to a resource, and will appear in any CLI output that shows a specific user (e.g. the image owner). Defaults to preferred_username. (For more information about claims: Okta, Azure AD).

Set up a Redgate clone admin

From your OIDC-enabled identity provide, add a claim named,  rgclone_admin and assign the user as the value. Use the same values you'd pass into your preferred_username.

Authenticating with the Identity Provider

After setting up your OIDC-enabled identity provider in the redgate Clone Admin Console, an end-user will be able authenticate via the redgate Clone CLI by simply running rgclone auth without any flags. Access to a browser is required to complete the authentication process

Please check Authenticate CLI against API Server for more details.

Identity Provider Configuration Guides

Azure AD

Okta