-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(app): dynamic authentication provider support #2167
feat(app): dynamic authentication provider support #2167
Conversation
The image is available at: |
The image is available at: |
This PR is stale because it has been open 7 days with no activity. Remove stale label or comment or this will be closed in 21 days. |
1 similar comment
This PR is stale because it has been open 7 days with no activity. Remove stale label or comment or this will be closed in 21 days. |
The image is available at: |
e2d623d
to
4b07d7d
Compare
The image is available at: |
Some feedback from @davidfestal that I will implement in the next day or so to help keep this future-proof against the new frontend system:
|
4b07d7d
to
b2d543e
Compare
The image is available at: |
b2d543e
to
f982271
Compare
The image is available at: |
f982271
to
cfb1a5d
Compare
The image is available at: |
cfb1a5d
to
29e2b2b
Compare
The image is available at: |
29e2b2b
to
65039c6
Compare
This change adds support for loading authentication providers or modules from dynamic plugins via 3 main changes to the code. First, an environment variable `ENABLE_AUTH_PROVIDER_MODULE_OVERRIDE` controls whether or not the backend installs the default authentication provider module. When this override is enabled dynamic plugins can be used to supply custom authentication providers. Secondly this change also adds a `signInPage` configuration for frontend dynamic plugins which is required for dynamic plugins to be able to provide a custom SignInPage component, for example: ```yaml dynamicPlugins: frontend: my-plugin-package: signInPage: importName: CustomSignInPage ``` Where the named export `CustomSignInPage` will be mapped to `components.SignInPage` when the frontend is initialized. Finally, to ensure authentication providers can be managed by the user a new `providerSettings` configuration field is available for frontend dynamic plugins, which can be used to inform the user settings page of the new provider, for example: ```yaml dynamicPlugins: frontend: my-plugin-package: providerSettings: - title: Github Two description: Sign in with GitHub Org Two provider: core.auth.github-two ``` Each `providerSettings` item will be turned into a new row under the "Authentication Providers" tab on the user settings page. The `provider` field is used to look up and connect the API ref for the external authentication provider and should be the same string used when calling `createApiRef`, for example: ```javascript export const ghTwoAuthApiRef: ApiRef< OAuthApi & ProfileInfoApi & BackstageIdentityApi & SessionApi > = createApiRef({ id: 'core.auth.github-two', // <--- this string }) ``` This commit also updates the app config.d.ts with some missing definitions as well as adds definitions for the above. Signed-off-by: Stan Lewis <[email protected]>
65039c6
to
f56b50b
Compare
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kadel The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
The image is available at: |
9c3c4ab
into
redhat-developer:main
/cherry-pick release-1.5 |
@gashcrumb: new pull request created: #2466 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Description
This change adds support for loading authentication providers or modules
from dynamic plugins via 3 main changes to the code.
First, an environment variable
ENABLE_AUTH_PROVIDER_MODULE_OVERRIDE
controls whether or not the backend installs the default authentication
provider module. When this override is enabled dynamic plugins can be
used to supply custom authentication providers.
Secondly this change also adds a
signInPage
configuration for frontenddynamic plugins which is required for dynamic plugins to be able to
provide a custom SignInPage component, for example:
Where the named export
CustomSignInPage
will be mapped tocomponents.SignInPage
when the frontend is initialized.Finally, to ensure authentication providers can be managed by the user a
new
providerSettings
configuration field is available for frontenddynamic plugins, which can be used to inform the user settings page of
the new provider, for example:
Each
providerSettings
item will be turned into a new row under the"Authentication Providers" tab on the user settings page. The
provider
field is used to look up and connect the API ref for theexternal authentication provider and should be the same string used when
calling
createApiRef
, for example:PR acceptance criteria
Please make sure that the following steps are complete:
How to test changes / Special notes to the reviewer
It's mostly enough to ensure that this change does not break the existing e2e tests. However to actually try this out locally I've prepared this example here. And there's also a second less good example that shows another common use-case for this functionality here