Currently we incorporate many of the Authentication providers available within Backstage. The Showcase supports the following providers:
Auth Provider | Auth Provider ID |
---|---|
Auth0 | auth0 |
Atlassian | atlassian |
Azure | microsoft |
Azure Easy Auth | azure-easyauth |
Bitbucket | bitbucket |
Bitbucket Server | bitbucketServer |
Cloudflare Access | cfaccess |
GitHub | github |
GitLab | gitlab |
google |
|
Google IAP | gcp-iap |
OIDC | oidc |
Okta | okta |
OAuth 2 Custom Proxy | oauth2Proxy |
OneLogin | onelogin |
SAML | saml |
-
Add the GitHub Authentication provider details as outlined below.
auth: environment: development providers: github: development: clientId: ${AUTH_GITHUB_CLIENT_ID} clientSecret: ${AUTH_GITHUB_CLIENT_SECRET} ## uncomment if using GitHub Enterprise # enterpriseInstanceUrl: ${AUTH_GITHUB_ENTERPRISE_INSTANCE_URL} ## uncomment if using a custom callback url # callbackUrl: ${AUTH_GITHUB_CALLBACK_URL}
For more information on setting up the GitHub auth provider, consult the Backstage documentation.
-
Add the GitLab Authentication provider details as outlined below.
auth: environment: development providers: gitlab: development: clientId: ${AUTH_GITLAB_CLIENT_ID} clientSecret: ${AUTH_GITLAB_CLIENT_SECRET} ## uncomment if using self-hosted GitLab # audience: https://gitlab.company.com ## uncomment if using a custom redirect URI # callbackUrl: https://${BASE_URL}/api/auth/gitlab/handler/frame
For more information on setting up the GitLab auth provider, consult the Backstage documentation.
The OAuth2 Proxy Authentication provider will require an OAuth2 Proxy server. You can consult the official documentation for OAuth2 Proxy, as well as our available blog post on the topic.
-
Add the OAuth2 Proxy Authentication provider details as outlined below.
auth: environment: development providers: oauth2Proxy: {}
For more information on setting up the OAuth2 Proxy auth provider, consult the Backstage documentation.
-
Add the OIDC Authentication provider details as outlined below.
auth: environment: development # Providing an auth.session.secret will enable session support in the auth-backend session: secret: ${SESSION_SECRET} providers: oidc: development: metadataUrl: ${AUTH_OIDC_METADATA_URL} clientId: ${AUTH_OIDC_CLIENT_ID} clientSecret: ${AUTH_OIDC_CLIENT_SECRET} prompt: ${AUTH_OIDC_PROMPT} # recommended to use auto ## uncomment for additional configuration options # callbackUrl: ${AUTH_OIDC_CALLBACK_URL} # tokenEndpointAuthMethod: ${AUTH_OIDC_TOKEN_ENDPOINT_METHOD} # tokenSignedResponseAlg: ${AUTH_OIDC_SIGNED_RESPONSE_ALG} # scope: ${AUTH_OIDC_SCOPE} ## Auth provider will try each resolver until it succeeds. Uncomment the resolvers you want to use to override the default resolver: `emailLocalPartMatchingUserEntityName` # signIn: # resolvers: # - resolver: preferredUsernameMatchingUserEntityName # - resolver: emailMatchingUserEntityProfileEmail # - resolver: emailLocalPartMatchingUserEntityName # - resolver: oidcSubClaimMatchingKeycloakUserId
In an example using Keycloak for authentication with the OIDC provider, there are a few steps that need to be taken to get everything working:
- Create a realm named keycloak.
- Create the client backstage with Client authentication checked.
- Set the Valid redirect URIs to
<BACKSTAGE_URL>/api/auth/oidc/handler/frame
. If running RHDH locally, it would look something like this:http://localhost:7007/api/auth/oidc/handler/frame
. - Set the
metadataUrl
to the URL of your Keycloak instance and realm. It should look similar to this:<KEYCLOAK_URL>/realms/keycloak
. - Set the
clientId
tobackstage
. - Obtain the client secret for the client backstage within Keycloak and set
clientSecret
. - Set the
prompt
toauto
. - Finally, set
auth.session.secret
tosuperSecretSecret
.
The default resolver provided by the oidc
auth provider is the emailLocalPartMatchingUserEntityName
resolver.
If you want to use a different resolver, add the resolver you want to use in the auth.providers.oidc.[environment].signIn.resolvers
configuration as soon in the example above, and it will override the default resolver.
- For enhanced security, consider using the
oidcSubClaimMatchingKeycloakUserId
resolver which matches the user with the immutablesub
parameter from OIDC to the Keycloak user ID.
For more information on setting up the OIDC auth provider, consult the Backstage documentation.
After selecting the authentication provider you wish to use with your RHDH instance, ensure to add the signInPage
configuration value to ensure that the frontend displays the appropriate authentication provider.
-
Add the corresponding Authentication provider key as the value to
signInPage
in yourapp-config
. Whereprovider-id
matches the chosen provider from the table above.signInPage: <provider-id>
The guest login is provided by a special authentication provider that must be explicitly enabled. This authentication provider should be used for development purposes only and is not intended for production, as it creates a default user that has user-level access to the Backstage instance.
-
To enable the guest provider for local development:
auth: providers: guest: {}
This will sign you in as
user:development/guest
-
To customize the
userEntity
the auth provider signs you in with:auth: providers: guest: userEntityRef: user:custom-namespace/custom-name
-
To customize the ownership of the
userEntity
the auth provider signs you in with:auth: providers: guest: ownershipEntityRefs: ['user:custom/user', 'user:custom2/user2']
-
To enable the guest provider when running the container:
auth: providers: guest: dangerouslyAllowOutsideDevelopment: true
-
To disable the guest login set
auth.environment
toproduction
.
This option allows users to sign in even if their profile has not been ingested into the catalog. By default, this option is set to false. Enabling this option is dangerous as it may allow unauthorized users to gain access.
To enable this option:
auth:
providers:
oidc:
development:
...
signIn:
resolvers:
- resolver: preferredUsernameMatchingUserEntityName
dangerouslyAllowSignInWithoutUserInCatalog: true
# provider configs ...
This option allows users to add transitive parent groups into the resolved user group membership during the authentication process. i.e., the parent group of the user's direct group will be included in the user ownership entities. By default, this option is set to false.
For instance, with this group hierarchy:
group_admin
└── group_developers
└── user_alice
- If
includeTransitiveGroupOwnership: false
,user_alice
is only a member ofgroup_developers
. - If
includeTransitiveGroupOwnership: true
,user_alice
is a member ofgroup_developers
ANDgroup_admin
.
To enable this option:
includeTransitiveGroupOwnership: true
auth:
providers:
# provider configs ...
External authentication providers can be loaded using the dynamic plugins mechanism. Typically this will require a backend plugin to provide the authentication provider API implementation and callback handling, and a frontend plugin to connect this API to important parts of the UI in the form of a custom SignInPage and provider settings entries for the user settings page.
The existing Developer Hub authentication module will need to be disabled by setting an environment variable, ENABLE_AUTH_PROVIDER_MODULE_OVERRIDE
to true
for the Developer Hub backend.
Some examples of composing dynamic plugins to provide an authentication solution are available in the dynamic plugins examples.