feat(app): dynamic authentication provider support (release-1.4) (not for merge) #2217
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Just to clarify why this is labelled with For an image that won't expire immediately, see |
|
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. |
|
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. |
gashcrumb
force-pushed
the
RHIDP-5484-1.4
branch
from
5aabfbd to
d7063c5
Compare
|
The image is available at: |
gashcrumb
force-pushed
the
RHIDP-5484-1.4
branch
from
d7063c5 to
0a51a97
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
})
```
Signed-off-by: Stan Lewis <[email protected]>
gashcrumb
force-pushed
the
RHIDP-5484-1.4
branch
from
0a51a97 to
6d8ac62
Compare
gashcrumb
changed the title
|
The image is available at: |
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:Which issue(s) does this PR fix
This is a manual cherry-pick of #2167 onto release-1.4
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.