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: |
gashcrumb
force-pushed
the
RHIDP-5484
branch
5 times, most recently
from
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:
|
gashcrumb
force-pushed
the
RHIDP-5484
branch
from
4b07d7d to
b2d543e
Compare
|
The image is available at: |
gashcrumb
force-pushed
the
RHIDP-5484
branch
from
b2d543e to
f982271
Compare
|
The image is available at: |
gashcrumb
force-pushed
the
RHIDP-5484
branch
from
f982271 to
cfb1a5d
Compare
|
The image is available at: |
gashcrumb
force-pushed
the
RHIDP-5484
branch
from
cfb1a5d to
29e2b2b
Compare
|
The image is available at: |
gashcrumb
force-pushed
the
RHIDP-5484
branch
from
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]>
gashcrumb
force-pushed
the
RHIDP-5484
branch
from
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: |
openshift-merge-bot
bot
merged commit 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_OVERRIDEcontrols 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
signInPageconfiguration for frontenddynamic plugins which is required for dynamic plugins to be able to
provide a custom SignInPage component, for example:
Where the named export
CustomSignInPagewill be mapped tocomponents.SignInPagewhen the frontend is initialized.Finally, to ensure authentication providers can be managed by the user a
new
providerSettingsconfiguration field is available for frontenddynamic plugins, which can be used to inform the user settings page of
the new provider, for example:
Each
providerSettingsitem will be turned into a new row under the"Authentication Providers" tab on the user settings page. The
providerfield 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