diff --git a/docs/auth/google/gcp-iap-auth.md b/docs/auth/google/gcp-iap-auth.md index 5ac75e6691..1ebfcaf15b 100644 --- a/docs/auth/google/gcp-iap-auth.md +++ b/docs/auth/google/gcp-iap-auth.md @@ -90,23 +90,8 @@ sign-in mechanism to poll that endpoint through the IAP, on the user's behalf. ## Frontend Changes -All Backstage apps need a `SignInPage` to be configured. Its purpose is to -establish who the user is and what their identifying credentials are, blocking -rendering the rest of the UI until that's complete, and then keeping those -credentials fresh. - -When using IAP Proxy authentication, the Backstage UI will only be loaded once -the user has already successfully completely authenticated themselves with the -IAP and has an active session, so we don't want to make the user have to go -through a _second_ layer of authentication flows after that. - -As such, we want to not display a sign-in page visually at all. Instead, we will -pick a `SignInPage` implementation component which knows how to silently make -requests to the backend provider we configured above, and just trusting its -output to properly represent the current user. Luckily, Backstage comes with a -component for this purpose out of the box. - -Update your `createApp` call in `packages/app/src/App.tsx`, as follows. +It is recommended to use the `ProxiedSignInPage` for this provider, which is +installed in `packages/app/src/App.tsx` like this: ```diff +import { ProxiedSignInPage } from '@backstage/core-components'; @@ -116,5 +101,4 @@ Update your `createApp` call in `packages/app/src/App.tsx`, as follows. + SignInPage: props => , ``` -After this, your app should be ready to leverage the Identity-Aware Proxy for -authentication! +See the [Sign-In with Proxy Providers](../index.md#sign-in-with-proxy-providers) section for more information. diff --git a/docs/auth/index.md b/docs/auth/index.md index c83005a974..c34d244886 100644 --- a/docs/auth/index.md +++ b/docs/auth/index.md @@ -127,6 +127,64 @@ allows allowing guest access: bindRoutes({ bind }) { ``` +## Sign-In with Proxy Providers + +Some auth providers are so-called "proxy" providers, meaning they're meant to be used +behind an authentication proxy. Examples of these are +[AWS ALB](https://github.com/backstage/backstage/blob/master/contrib/docs/tutorials/aws-alb-aad-oidc-auth.md), +[GCP IAP](./google/gcp-iap-auth.md), and [OAuth2 Proxy](./oauth2-proxy/provider.md). + +When using a proxy provider, you'll end up wanting to use a different sign-in page, as +there is no need for further user interaction once you've signed in towards the proxy. +All the sign-in page needs to do is to call the `/refresh` endpoint of the auth providers +to get the existing session, which is exactly what the `ProxiedSignInPage` does. The only +thing you need to do to configure the `ProxiedSignInPage` is to pass the ID of the provider like this: + +```tsx +const app = createApp({ + ..., + components: { + SignInPage: props => , + }, +}); +``` + +A downside of this method is that it can be cumbersome to set up for local development. +As a workaround for this, it's possible to dynamically select the sign-in page based on +what environment the app is running in, and then use a different sign-in method for local +development, if one is needed at all. Depending on the exact setup, one might choose to +select the sign-in method based on the `process.env.NODE_ENV` environment variable, +by checking the `hostname` of the current location, or by accessing the configuration API +to read a configuration value. For example: + +```tsx +const app = createApp({ + ..., + components: { + SignInPage: props => { + const configApi = useApi(configApiRef); + if (configApi.getString('auth.environment') === 'development') { + return ( + + ); + } + return ; + }, + }, +}); +``` + +When using multiple auth providers like this, it's important that you configure the different +sign-in resolvers so that they resolve to the same identity regardless of the method used. + ## For Plugin Developers The Backstage frontend core APIs provide a set of Utility APIs for plugin developers diff --git a/docs/auth/oauth2-proxy/provider.md b/docs/auth/oauth2-proxy/provider.md index 644219ffa0..966596e268 100644 --- a/docs/auth/oauth2-proxy/provider.md +++ b/docs/auth/oauth2-proxy/provider.md @@ -57,25 +57,15 @@ providers.oauth2Proxy.create({ ## Adding the provider to the Backstage frontend -All Backstage apps need a `SignInPage` to be configured. Its purpose is to -establish who the user is and what their identifying credentials are, blocking -rendering the rest of the UI until that's complete, and then keeping those -credentials fresh. - -When using the OAuth2-Proxy, the Backstage UI can only be accessed after the -user has already been authenticated at the proxy. Instead of showing the user -another login page when accessing Backstage, it will handle the login in the -background. Backstage provides for this case the `ProxiedSignInPage` component -which has no UI. - -Update your `createApp` call in `packages/app/src/App.tsx`, as follows. +It is recommended to use the `ProxiedSignInPage` for this provider, which is +installed in `packages/app/src/App.tsx` like this: ```diff +import { ProxiedSignInPage } from '@backstage/core-components'; + const app = createApp({ components: { + SignInPage: props => , ``` -After this, your app should be ready to leverage the OAuth2-Proxy for -authentication! +See the [Sign-In with Proxy Providers](../index.md#sign-in-with-proxy-providers) section for more information.