Skip to content
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

Merged
merged 1 commit into from
Feb 24, 2025

Conversation

gashcrumb
Copy link
Member

@gashcrumb gashcrumb commented Jan 10, 2025

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 frontend
dynamic plugins which is required for dynamic plugins to be able to
provide a custom SignInPage component, for example:

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:

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:

export const ghTwoAuthApiRef: ApiRef<
  OAuthApi & ProfileInfoApi & BackstageIdentityApi & SessionApi
> = createApiRef({
  id: 'core.auth.github-two',  // <--- this string
})

PR acceptance criteria

Please make sure that the following steps are complete:

  • GitHub Actions are completed and successful
  • Unit Tests are updated and passing
  • E2E Tests are updated and passing
  • Documentation is updated if necessary (requirement for new features)
  • Add a screenshot if the change is UX/UI related

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

Copy link
Contributor

Copy link
Contributor

Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Contributor

github-actions bot commented Feb 5, 2025

@gashcrumb gashcrumb force-pushed the RHIDP-5484 branch 5 times, most recently from e2d623d to 4b07d7d Compare February 10, 2025 12:29
Copy link
Contributor

@gashcrumb
Copy link
Member Author

gashcrumb commented Feb 10, 2025

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:

  • Rename "components" to "SignInPage" and remove "name" field, restricting this to the intended purpose
  • Look at not specifying apiFactories in the configuration for the examples, apiFactories should be discoverable from the plugin.
  • On that last point, revisit how API factories for external auth providers are discovered in the code
  • Use the complete API factory ID string in the config vs the simple provider name

Copy link
Contributor

Copy link
Contributor

Copy link
Contributor

Copy link
Contributor

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]>
@kadel
Copy link
Member

kadel commented Feb 24, 2025

/approve
/lgtm

Copy link

openshift-ci bot commented Feb 24, 2025

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Copy link
Contributor

@openshift-merge-bot openshift-merge-bot bot merged commit 9c3c4ab into redhat-developer:main Feb 24, 2025
11 checks passed
@gashcrumb
Copy link
Member Author

/cherry-pick release-1.5

@openshift-cherrypick-robot
Copy link
Contributor

@gashcrumb: new pull request created: #2466

In response to this:

/cherry-pick release-1.5

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants