# Jednotné přihlášení (https://docs.vitrinka.ai/cs/operator/sso)



## Nastavení [#configure]

**Settings → Organization → SSO.** Zadejte issuer, client id a secret a namapujte skupiny z IdP na role. Než to potvrdíte, pomůžou dvě věci: **Check health** prověří issuer a **test sign-in** ukáže, jaké claimy přesně dorazí.

* **Entra ID, Keycloak, Okta** — všechny tři se používají, ale návod pro jednotlivé poskytovatele zatím napsaný není — ozvěte se a dostanete přesné nastavení issueru, scopů a claimů pro ten váš. Poskytovatel ve vaší interní síti potřebuje nejdřív operátora — [níže](#private).
* **Mapování skupin na role** — se použije při každém přihlášení, takže odebrání skupiny v adresáři odebere přístup i tady.
* **Výchozí workspaces** — běžný člen organizace se dostane jen do workspaces, kde je výslovně členem, proto vyberte sdílené workspaces, do kterých má vstoupit každý, kdo se přes SSO přihlásí poprvé. Při prvním přihlášení tam dostane roli člena (v auditu jako `member.join`); roli, kterou už v některém z těchto workspaces má, si ponechá, nikdy se nesníží. Vlastníci a admini se dostanou do všech workspaces i bez toho a tato volba se jich netýká.

## Poskytovatel identity ve vaší síti [#private]

Ve výchozím stavu SSO klient dosáhne jen na poskytovatele identity na veřejných adresách: discovery, sada klíčů, výměna tokenu i **Check health** odmítnou loopback, privátní a link-local cíle, takže přes své připojení nemůže vaši síť prozkoumávat žádná organizace. Interní Keycloak nebo ADFS — a každý poskytovatel identity v air-gapped instalaci — vyžaduje dva kroky.

1. **Operátor uvede adresu poskytovatele** ve `VITRINKA_SSO_PRIVATE_NETWORKS` a restartuje: CIDR rozsahy oddělené čárkou, holá IP platí jako její `/32` nebo `/128`. Uveďte vlastní adresu poskytovatele, ne celou podsíť. Loopback je dosažitelný, jen když je uvedený. Link-local, nespecifikované, multicastové a broadcastové adresy nikdy — položka, která se s nimi překrývá, start odmítne — a známé adresy cloudových metadat zůstávají zavřené i uvnitř uvedeného rozsahu. `AIR_GAP=1` sám nic neotevře a veřejné adresy odebere: uvedené interní rozsahy jsou pak vše, kam SSO dosáhne, a položka mimo loopback, RFC 1918, ULA, CGNAT nebo třídu E start odmítne. Poskytovatel, jehož certifikát vydala vaše vlastní CA, potřebuje i `VITRINKA_SSO_CA`: cestu k PEM souboru nebo text PEM, načtený při startu a vedle systémových kořenů důvěryhodný jen pro SSO klienta.
2. **Připojení uloží držitel pravomoci nad nasazením.** Na uvedený rozsah dosáhne jen připojení spravované nasazením: takové, které v **Settings → Organization → SSO** uložil platform admin nebo admin organizace z `VITRINKA_OPS_ORG`, který je zároveň adminem organizace, jíž připojení patří ([první administrátor](/cs/operator/install#admin)). Každé uložení takovým adminem připojení označí, i když mění jen skupiny nebo role, a nápověda u pole issuer pak říká *deployment-managed*. Když běžný admin organizace uloží issuer, client ID nebo client secret, připojení je zase jen pro veřejné adresy, takže i rotace secretu interního poskytovatele vyžaduje pravomoc nad nasazením; smazání připojení označení zruší.

```bash
VITRINKA_SSO_PRIVATE_NETWORKS=10.20.30.40/32
VITRINKA_SSO_CA=/etc/vitrinka/sso-ca.pem
```

Dokud nejsou hotové oba kroky, **Check health** pojmenuje, co chybí a kdo musí jednat. V air-gapped instalaci připojení, které nikdo s pravomocí nad nasazením neuložil, nedosáhne nikam a veřejný issuer se odmítne — **Check health** pojmenuje `AIR_GAP` i opravu. Po upgradu zůstává připojení, které existovalo dřív, jen pro veřejné adresy, dokud ho držitel pravomoci nad nasazením jednou neuloží.

Dveře napříč organizacemi neexistují: platform admin označí připojení jen v organizacích, které spravuje, a `/admin` SSO připojení nevypisuje. Obvyklý tvar je jedna organizace, jejímiž adminy jsou operátoři — uveďte ji ve `VITRINKA_OPS_ORG`, nebo z operátorských účtů udělejte platform adminy.

<Callout type="warn">
  Označení ručí za uložený issuer a důvěra pak patří tomu, kdo ten issuer provozuje: jeho DNS vybírá adresu, jeho discovery dokument vybírá endpointy sady klíčů a tokenu a jeho přesměrování se následují — kamkoli uvnitř uvedených rozsahů. Ukládejte jen připojení k poskytovateli identity, kterého provozujete nebo kterému věříte, a seznam držte na jeho vlastní adrese. Odebrání platform admina nebo místa v organizaci z `VITRINKA_OPS_ORG` nezruší označení, která už dotyčný nastavil.
</Callout>

## Vynucené SSO [#forced]

Zapnutím ho vyžadujete po lidech ze své organizace. Koho přesně to váže, záleží na instalaci:

* **Členy vaší organizace** (výchozí stav, `VITRINKA_SSO_DOMAINS` vypnuté — hostovaná služba i každá vlastní instalace bez nárokovaných domén). Přihlašovací stránka nechává formulář s heslem všem; kontrola běží *až po* ověření přihlašovacího údaje, v dokončovacím kroku, kterým prochází každá lokální cesta (heslo, e-mailový kód, reset, passkey, GitHub). Člen vynucující organizace tam dostane odmítnutí se stránkou, která ho pošle na vaše SSO, a odmítnutí se zapíše do auditu. Kdo členem není — uživatel jiné organizace, úplně nová registrace — se přihlásí normálně. Rozhodovat až po ověření je záměr: sdílená stránka nikdy neprozradí, kdo do vaší organizace patří.
* **Vaše nárokované e-mailové domény** při `VITRINKA_SSO_DOMAINS=on` ([níže](#domains)): tyhle adresy jsou odmítnuté rovnou, na stránce i při každém lokálním POSTu.
* **Celou instalaci** při `VITRINKA_SSO_DOMAINS=on`, když je vaše připojení jediné zapnuté — podniková vlastní instalace, kde instalaci vlastníte. Zámek trvá, jen dokud jediné zůstane: jakmile kterákoli organizace zapne druhé připojení, zúží se na vaše nárokované domény, proto si je nárokujte také.

Při `VITRINKA_SSO_DOMAINS=on` váže zapnutí vynuceného SSO adresy na přihlašovací stránce, kterou sdílejí všechny organizace, takže jde o nastavení pro celé nasazení: potřebuje platform admina nebo admina organizace z `VITRINKA_OPS_ORG`, který je zároveň adminem této organizace. Admin organizace bez této pravomoci si ponechá vynucení, které už je zapnuté, a může ho vypnout; dokud je vypnuté, ukazuje mu přepínač *unavailable* i s důvodem.

Bez domén server odmítne uložit vynucené SSO, dokud je zapnuté připojení jiné organizace, a odmítne zapnout druhé připojení, dokud některá organizace SSO vynucuje — nastavení se nikdy nepřijme a pak potichu neignoruje.

Pro případ, že váš IdP nefunguje, existuje zdokumentovaná nouzová cesta na `/auth/login?local=1`; každé použití se zapisuje do auditu a `VITRINKA_BREAK_GLASS` určuje, kdo ji smí použít ([níže](#breakglass)).

## E-mailové domény [#domains]

Vlastní instalace může nastavit `VITRINKA_SSO_DOMAINS=on`, aby si každá organizace nárokovala e-mailové domény, které její poskytovatel identity vlastní. Nárok je přesná shoda a v rámci instalace výlučný, sdílené poštovní služby nárokovat nelze a přihlášení nárokované adresy míří rovnou na připojení dané organizace. Hostovaná služba to nechává vypnuté.

Protože nárok směruje adresy na přihlašovací stránce, kterou sdílejí všechny organizace, je přidání nároku nastavením pro celé nasazení: potřebuje platform admina nebo admina organizace z `VITRINKA_OPS_ORG`, který je zároveň adminem nárokující organizace. Admin organizace bez této pravomoci vidí místo nápovědy pole důvod a nároky, které organizace drží, může dál znovu uložit nebo uvolnit. Odmítnutí přichází dřív než jakákoli kontrola proti nárokům jiných organizací, takže je nikdy neprozradí. Nároky uložené před upgradem na toto pravidlo zůstávají, jak byly.

## MFA se ověřuje, nepředpokládá [#mfa]

MFA vynucuje váš IdP — conditional access v Entra, required actions v Keycloaku — a vitrinka ho **kontroluje**. Zapněte **Require MFA** a server odmítne každé přihlášení, jehož id\_token nenese vícefaktorový claim `amr`.

<Callout type="warn">
  Jde o to, aby potichu uvolněná politika na IdP selhala **hlasitě**, místo aby druhý faktor tiše vypadl. Tokeny Entra v2.0 potřebují `amr` nastavený jako volitelný claim; v1.0 ho posílá samo.
</Callout>

## Nouzový přístup jen pro vlastníky a přes passkey [#breakglass]

`/auth/login?local=1` aktivuje pětiminutové nouzové povolení lokálního přihlášení. Platí dvě pravidla, v tomhle pořadí:

1. **Kdo ho smí použít — `VITRINKA_BREAK_GLASS`** (výchozí `owners`): nouzové přihlášení dokončí jen **vlastník** vynucující organizace; pokus člena je odmítnutý jako vynucené SSO a nechá auditní záznam `auth.break_glass` označený jako zamítnutý (`reason: not an owner`). `off` nouzovou cestu úplně vypne — `?local=1` nic nepovolí a odmítnutí nemá obejití. `all` ji pustí každému, koho režim váže (chování před 2026-09). Stejně jako vynucené SSO se pravidlo rozhoduje až po ověření přihlašovacího údaje.
2. **Passkey má přednost**: účet s registrovaným passkey se musí přihlásit jím. Formulář s heslem funguje jen pro účty, které si passkey nikdy nezaložily, a tahle slabší cesta si píše vlastní auditní záznam.

<Callout type="warn">
  Založte passkey aspoň jednomu adminovi **dřív**, než nouzovou cestu budete potřebovat.
</Callout>

## Session a hlavičky [#posture]

Každá odpověď nese základní sadu hlaviček — nosniff, `frame-ancestors 'self'`, Referrer-Policy, Permissions-Policy — a HSTS se přidá automaticky, když je `BASE_URL` https.

| Nastavení                   | Výchozí                                        | Přepsat                 |
| --------------------------- | ---------------------------------------------- | ----------------------- |
| Absolutní životnost session | 720 hodin; enterprise balík nastavuje 12 hodin | `VITRINKA_SESSION_TTL`  |
| Timeout nečinnosti          | vypnutý; enterprise balík nastavuje 30 minut   | `VITRINKA_SESSION_IDLE` |

<Callout type="warn">
  Obojí se vynucuje na serveru. Zkombinujte to s vynuceným SSO, ať každé přihlášení projde politikou vašeho IdP.
</Callout>
