Merge pull request #19365 from VladMasarik/add-auth-docs
Docs: Add warning about backend APIs not having auth by default
This commit is contained in:
+7
-7
@@ -10,6 +10,13 @@ configure Backstage to have any number of authentication providers, but only
|
||||
one of these will typically be used for sign-in, with the rest being used to provide
|
||||
access to external resources.
|
||||
|
||||
> NOTE: Identity management and the Sign-In page in Backstage is NOT a method for blocking
|
||||
> access for unauthorized users. The identity system only serves to provide a personalized
|
||||
> experience and access to a Backstage Identity Token, which can be passed to backend plugins.
|
||||
> This also means that your Backstage backend APIs are by default unauthenticated.
|
||||
> Thus, if your Backstage instance is exposed to the Internet, anyone can access
|
||||
> information in the Backstage. You can learn more [here](../overview/threat-model.md#integrator-responsibilities).
|
||||
|
||||
## Built-in Authentication Providers
|
||||
|
||||
Backstage comes with many common authentication providers in the core library:
|
||||
@@ -60,13 +67,6 @@ the local `auth.environment` setting will be selected.
|
||||
|
||||
## Sign-In Configuration
|
||||
|
||||
> NOTE: Identity management and the `SignInPage` in Backstage is NOT a method
|
||||
> for blocking access for unauthorized users, that either requires additional
|
||||
> backend implementation or a separate service like Google's Identity-Aware
|
||||
> Proxy. The identity system only serves to provide a personalized experience
|
||||
> and access to a Backstage Identity Token, which can be passed to backend
|
||||
> plugins.
|
||||
|
||||
Using an authentication provider for sign-in is something you need to configure
|
||||
both in the frontend app, as well as the `auth` backend plugin. For information
|
||||
on how to configure the backend app, see [Sign-in Identities and Resolvers](./identity-resolver.md).
|
||||
|
||||
Reference in New Issue
Block a user