docs(3149): what the SSO secrets are and where each one lives
The question this answers is "what do I have to configure, and where" — so the table of secrets is the deliverable and the prose is scaffolding around it. The organising idea worth keeping: a secret belongs in-container when nothing outside that container reads it. Every one of authelia's own secrets passes that test; the client secret's plaintext fails it, which is what makes delivery a problem at all rather than a detail.
This commit is contained in:
parent
cdb3c612b2
commit
b4a3eb75b0
3 changed files with 101 additions and 6 deletions
|
|
@ -18,12 +18,9 @@
|
|||
# for LDAP: what makes a directory necessary is the size of the subject
|
||||
# set, and this deployment's is bounded by one swarm.
|
||||
#
|
||||
# Two roles, and only the first is unconditional: this is a **session**
|
||||
# provider (`auth_request`) always, and an **OIDC** provider when
|
||||
# `oidc.clients` is non-empty. The second is derived from the client list
|
||||
# instead of carrying its own flag, because authelia refuses to start
|
||||
# with a provider that has no clients — a separate `enable` would be a
|
||||
# second fact that can disagree with the first.
|
||||
# Two roles: a **session** provider always, an **OIDC** provider when
|
||||
# `oidc.clients` is non-empty (derived, not flagged — authelia will not
|
||||
# start with a clientless provider). Secrets map: docs/swarm/sso.md.
|
||||
#
|
||||
# Per-service integration — putting authelia's `auth_request` in front
|
||||
# of the gateway's existing `auth_basic` locations — is deliberately NOT
|
||||
|
|
|
|||
Loading…
Reference in a new issue