# Identita a přístup (https://docs.vitrinka.ai/cs/security/identity)



## Role [#roles]

Čtyři stupně na workspace, přísně seřazené: **viewer** \< **member** \< **admin** \< **owner**. Nad workspace stojí organizace s rolemi owner, admin a member: vlastníci a admini organizace spravují každý týmový workspace organizace, kdežto běžný člen organizace dosáhne jen do workspace, do kterých byl přidán, takže jedno místo nikdy neotevře celou firmu. Osobní workspace patří jen svému vlastníkovi. Spodní hranice routeru pro jakýkoli zápis je člen; nastavení workspace — vazba zrcadla a jeho synchronizace, automatizační pravidla, přepsání AI backendu, redakční politika záznamů, nastavení vzhledu — jsou admin a výš, záměrně přísněji než jejich čtení. Aktérem v ledgeru u zápisů enginu je ověřená identita za požadavkem, nikdy označení, které poslal klient.

## Přihlašovací údaje [#credentials]

* **Hesla** se ukládají jako hashe Argon2id. U neznámé adresy server také provede výpočet hashe, aby omezil rozdíl v době odezvy mezi existujícím a neexistujícím účtem.
* **Passkeys** používají kryptografii veřejného klíče. Účet s registrovaným passkey ho používá k místnímu přihlášení. Jak passkey přidat a používat popisuje [sekce níže](#passkeys).
* **API tokeny, tokeny konektorů, session cookies a tajemství sdílecích odkazů** se ukládají jako SHA-256 hashe. Klíče poskytovatelů a tajemství sdílecích odkazů, které musí jít obnovit, jsou zapečetěné master klíčem a vázané na záznam, ke kterému patří.
* **Veřejně vkládané klíče** — klíč hlášení chyb a token rekordéru žijí uvnitř aplikací a na zařízeních testerů, mimo stroje organizace. Každý je omezený na vlastní cesty pro příjem dat a z jiného originu dostane odpověď jen z originů, které povoluje ([přístup z jiných originů](/cs/security/headers#cors)); uniklý token rekordéru umí zakládat sessions a jedná jen s těmi, které sám založil: nahrává do nich a zpátky přečte jen jejich stavový záznam — nikdy jejich události, board ani úkol — a session, kterou založil jakýkoli jiný přístup, člen nebo jiný rekordér, ani ten propojený stejnou osobou, přečíst, zavřít ani do ní zapisovat nemůže. Token rekordéru vzniká buď propojením zařízení schválením kódu — vázaný na osobu, s klouzavou platností 30 dní — nebo ho vydá admin pro jeden projekt.
* Nová a změněná hesla se ověřují proti známým únikům dat k-anonymním dotazem na rozsah: server opustí jen prvních pět hexadecimálních znaků SHA-1 hesla. Pod `AIR_GAP=1` je kontrola vypnutá.
* Každé tajemství se razí z `crypto/rand`; pokusy o přihlášení, registraci, ověření, reset, passkey a autorizaci konektoru jsou omezené rychlostí a zamítnuté pokusy se auditují.

## Passkeys [#passkeys]

Passkey je WebAuthn přihlašovací údaj — Touch ID nebo Face ID, Windows Hello, odemknutí telefonu s Androidem nebo iPhonem, nebo hardwarový bezpečnostní klíč — který přihlásí jedním klepnutím a bez hesla. Vitrinka provádí celý obřad sama proti hostiteli aplikace (`app.vitrinka.ai` na SaaS, vaše `BASE_URL` při vlastním hostování), takže nic neopouští instalaci; passkeys vyžadují absolutní `BASE_URL` a server, který nastartuje bez ní, zapíše do logu `passkeys disabled` a tlačítko na přihlašovací stránce skryje.

* **Přidání** v **Nastavení → Zabezpečení → passkeys → add a passkey**, nebo přímo na `/auth/passkeys`: klíč pojmenujte („MacBook Touch ID“, „YubiKey“), stiskněte **Add a passkey** a potvrďte na zařízení. Klíč může registrovat jen přihlášený prohlížeč; každá registrace zapíše auditní řádek `auth.passkey.add`. Klíče jsou rezidentní (discoverable), takže přihlašovací stránka se nejdřív neptá na e-mail.
* **Přihlášení** tlačítkem **Sign in with a passkey** na `/auth/login`. Tlačítko se zobrazí jen v prohlížečích, které WebAuthn podporují. Přihlášení passkey razí stejnou session jako přihlášení heslem — stejný auditní řádek (`auth.login`, metoda `passkey`), stejné upozornění na nové zařízení, stejné pravidlo přistání — a podléhá stejné politice vynuceného SSO: účet, jehož organizace SSO vynucuje, je odmítnut při dokončení stejně jako heslo.
* **Odebrání** ve stejném ostrůvku Nastavení nebo na stránce správy; odebrání se audituje jako `auth.passkey.remove`. Klíč zůstává na zařízení, dokud ho tam nesmažete, ale přihlásit už nedokáže.
* **Jen prohlížeče.** Desktopová aplikace zůstává u hesla, protože její vestavěný webový pohled WebAuthn obřad spustit nedokáže. Snap i CLI se přihlašují schválením kódu ve vašem prohlížeči, kde passkey funguje.
* **Vztah k nouzovému přístupu:** při výpadku vynuceného SSO nouzové dveře upřednostňují passkey — účet, který ho má, ho musí použít (viz [Nouzový přístup](#breakglass)).

## Jednotné přihlášení a MFA [#sso]

OIDC proti vašemu adresáři — hostovanému poskytovateli identity nebo tomu ve vaší vlastní síti — nastavené v produktu a v plném rozsahu popsané v [Jednotném přihlášení](/cs/operator/sso): vynucené SSO pro členy organizace, pro její nárokované e-mailové domény (`VITRINKA_SSO_DOMAINS=on`) nebo pro celou instalaci; mapování skupin na role se použije při každém přihlášení. Nárokovat doménu a při zapnutých nárocích zapnout vynucené SSO vyžaduje [pravomoc nad instalací](#deployment).

MFA zajišťuje poskytovatel identity. Při zapnutém **Require MFA** vitrinka ověřuje údaj `amr` v `id_token`; chybějící nebo nedostatečný údaj znamená odmítnutí přihlášení.

### Poskytovatel identity ve vaší síti [#sso-network]

Každé volání klienta SSO — načtení konfigurace, sady klíčů, výměna tokenu i health check na stránce nastavení — jde přes jednoho hlídaného klienta, který při navazování spojení kontroluje každou rozloženou adresu, včetně přesměrování. Ve výchozím stavu dosáhne jen na veřejné adresy. Poskytovatel identity ve vaší vlastní síti, třeba interní Keycloak nebo ADFS a u každé air-gapped instalace, je dosažitelný, když platí obojí:

* provozovatel uvede jeho rozsah ve `VITRINKA_SSO_PRIVATE_NETWORKS` a restartuje — seznam držte na vlastní adrese poskytovatele, `/32` nebo `/128`;
* připojení je **spravované instalací**: jeho issuer, client ID a client secret naposledy uložil někdo s pravomocí nad instalací, kdo je zároveň adminem té organizace. Admin organizace, který kteroukoli z těch tří hodnot změní, ho vrátí jen na veřejné adresy; skupiny, role, MFA a výchozí workspace dál upravuje sám. Nastavení spravované připojení označí u jeho issueru a auditní řádek `org.sso` každého uložení stav zaznamená.

Pod `AIR_GAP=1` klient přijde i o veřejné adresy: dosáhne jen na uvedený rozsah uvnitř interní sítě (loopback, privátní, CGNAT, třída E), položka sahající za tyto rozsahy start odmítne a připojení, které neuložila pravomoc nad instalací, nedosáhne nikam ([Air-gapped nasazení](/cs/security/airgap#stays)). Adresy link-local a známé adresy cloudových metadat nejsou dosažitelné nikdy, ať jsou v seznamu, nebo ne, a položka seznamu, která se překrývá s rozsahy link-local, start odmítne. `VITRINKA_SSO_CA` přidá privátní certifikační autoritu jen pro tohoto klienta, vedle systémových kořenů. Spravované připojení ručí za toho, kdo provozuje jeho issuer: DNS, konfigurační dokument a přesměrování té strany rozhodují, kam klient uvnitř uvedených rozsahů půjde. Každé uložení s pravomocí nad instalací připojení označí, i takové, které mění jen skupiny, proto ukládejte jen připojení k poskytovateli identity, kterého provozujete nebo kterému věříte. Odebrání pravomoci nad instalací neruší označení, která dotyčný uložil: připojení zůstane spravované, dokud admin organizace neuloží jeho issuer, client ID nebo client secret, nebo ho nesmaže.

## Nouzový přístup [#breakglass]

`/auth/login?local=1` aktivuje pětiminutové nouzové povolení, když poskytovatel identity nefunguje. `VITRINKA_BREAK_GLASS` rozhoduje, kdo ho smí dokončit — ve výchozím stavu `owners` vynucující organizace, `all`, nebo `off` — a rozhoduje se až po ověření přihlašovacího údaje, aby přihlašovací stránka nikdy neprozradila členství. Passkey má přednost: účet s passkey ho musí použít. Každé použití i každé zamítnutí zapíše auditní řádek `auth.break_glass`.

## Pravomoc nad instalací [#deployment]

Každý účet vlastní organizaci od svého prvního přihlášení, a proto správa organizace nikdy nedává moc nad instalací. Nastavení, která působí na každého, kdo se přihlašuje, patří pravomoci nad instalací:

* mailer instalace, který posílá každý reset hesla i přihlašovací kód ([mailer instalace](/cs/operator/mail));
* nárokování e-mailové domény pro SSO a zapnutí vynuceného SSO při zapnutých nárocích na domény;
* označení připojení SSO jako spravovaného instalací ([výše](#sso-network));
* povolení, aby tracker, AI backend workspace nebo AI endpoint organizace dosáhl na privátní, loopback nebo interní adresu ([Odchozí cíle](/cs/operator/connectors#outbound)).

Pravomoc nad instalací mají **platformní admini** a — když `VITRINKA_OPS_ORG` jmenuje organizaci, která instalaci provozuje — také admini této organizace; bez něj jen platformní admini. K datům žádný přístup nedává. Změnu od kohokoli jiného server odmítne s `403`, které jmenuje, kdo ji provést smí. Admin organizace si ponechá zbytek vlastního připojení SSO, smí uvolnit vlastní nároky na domény a smí vynucené SSO vypnout. Platformní admin jedná přes organizaci, kterou spravuje — dveře napříč organizacemi neexistují — takže na instalaci s více organizacemi ho do té organizace nejdřív přidejte.

Roli platformního admina uděluje serverová binárka uvnitř svého kontejneru; změna platí od dalšího požadavku účtu a audituje se jako `platform.admin.grant`:

```bash
docker compose exec vitrinka /vitrinka platform-admin grant you@example.com
```

`VITRINKA_OPS_ORG` musí jmenovat organizaci, která už existuje; registrace tento slug nikdy nedostane, takže organizaci, která ještě neexistuje, si nikdo nepřivlastní ([reference konfigurace](/cs/reference/env#core)). Po upgradu zůstanou nároky na domény a vynucená připojení uložená podle starých pravidel, jak byla — zkontrolujte je — a připojení k poskytovateli identity ve vaší síti zůstane jen na veřejných adresách, dokud ho pravomoc nad instalací jednou neuloží. Stejné jednorázové uložení vrátí do provozu i tracker, AI backend nebo AI endpoint ve vaší síti ([po upgradu](/cs/operator/connectors#outbound)).

## Sessions [#sessions]

`VITRINKA_SESSION_TTL` (výchozí 720h) je absolutní životnost; `VITRINKA_SESSION_IDLE` (výchozí vypnuto, po nastavení aspoň `5m` a kratší než životnost) přidává klouzavý timeout nečinnosti. Obojí se vynucuje na serveru. Compose v enterprise balíku nastavuje 12h a 30m.

## Agenti a připojené aplikace [#agents]

AI asistenti, kteří se připojují jako OAuth klient, používají OAuth 2.1 s povinným PKCE (S256), jen veřejní klienti — není žádné client secret, které by uniklo. Metadata jsou na `/.well-known/oauth-authorization-server` a `/.well-known/oauth-protected-resource`; klienti se registrují dokumentem metadat client ID, nebo záložně na `POST /oauth/register` — pod `AIR_GAP=1` jen tak, protože žádný dokument metadat se nestahuje; zdrojem je `/mcp`. Oprávnění mají rozsah čtení nebo čtení a zápis a jsou vázaná na jednu aplikaci a jednoho uživatele. Připojení dosáhne jen na workspace, které uživatel zaškrtl při souhlasu nebo později v Nastavení — celé organizace (včetně workspace v nich později vytvořených) nebo jednotlivé workspace, a pokud chce, i napříč organizacemi, přičemž se každá organizace audituje zvlášť; workspace Personal jen po výslovném zaškrtnutí. Každé volání se nejdřív ověří proti aktuálnímu členství uživatele ve workspace, kterému je určené, pak proti dosahu připojení, a jedná s oprávněním člena — proto viewer aplikaci připojit nemůže; workspace mimo dosah je odmítnutý odpovědí `403 workspace_not_connected`, nikdy výzvou k přihlášení. Správce workspace může připojení ze svého workspace odebrat a uživatel ho tam zpět přidat nemůže. Ztráta členství workspace okamžitě odebere ze všech připojení a připojení, kterému nic nezbude, se odvolá. Připojení nemůže spravovat účet: sezení, osobní přístupové tokeny, odhlášení všude a e-mailové nastavení organizace vyžadují prohlížeč nebo token CLI. Klienti připojení vyřadí na `POST /oauth/revoke` (RFC 7009). Přístupové tokeny žijí hodinu, obnovovací tokeny rotují při každém použití a rotovaný token předložený znovu víc než 30 sekund po své rotaci odvolá celé připojení — uvnitř toho okna, kde relace sdílející jedno přihlášení souběžně obnovují token, vydá nový pár a zapíše se do auditu. Endpointy registrace, autorizace a tokenů jsou omezené rychlostí per adresa.

CLI se ověřuje osobním bearer tokenem, přepsaným na rozsah každého workspace, kterému je volání určené, a stropovaným na roli člena. CLI ho ve výchozím nastavení ukládá do systémové klíčenky. Na počítači bez použitelné klíčenky dovoluje `vitrinka auth login --insecure-storage` výslovně zvolenou záložní variantu: uložení v prostém textu do místního konfiguračního souboru ([MCP klienti](/cs/dev/mcp/clients)).

## Sdílené odkazy [#share]

Sdílený odkaz je oprávnění k jedné nástěnce: kdo ho má, otevře celou tu nástěnku bez účtu, jen ke čtení nebo s právem anotovat, dokud nevyprší nebo není zrušený — [sdílení s lidmi zvenčí](/cs/use/sharing).

* **Tajemství** se razí z `crypto/rand`, ukládá se jako SHA-256 hash pro vyhledání a je zapečetěné master klíčem, aby ho nabídka sdílení mohla znovu zkopírovat. Volitelná přístupová fráze se drží jako hash Argon2id. Odkaz vyprší po 24 hodinách, 7 dnech, 30 dnech (výchozí) nebo nikdy a jeho zrušení ho ukončí okamžitě. Vytvoření i zrušení odkazu se audituje jako `share.create` a `share.revoke`.
* **Jeho dosah** — odkazy vytvářejí členové, admini a vlastníci workspace, viewer ne, a osobní nástěnku sdílet nejde nikdy. Odkaz otevře svou jedinou nástěnku a nic dalšího ve workspace; hosté nejsou členové a nezabírají místa. Na vyhrazeném [originu pro sdílení](/cs/security/headers#share) se nepřijímá vůbec žádná session ani token.
* **Hosté** zadají jméno při prvním zápisu, což se audituje jako `share.guest`. Jméno jejich práci označuje a nic neopravňuje: kterému hostovi anotace patří, rozhoduje server podle vlastní cookie toho hosta, držené pro každý odkaz 30 dní.
* **Odložené do uvolnění** — nic, co host napíše, se nedostane do fronty agenta, dokud to člen neuvolní, položku po položce. Člen může důvěřovat hostovi s ověřeným e-mailem: připomínky a žádosti o issue takového hosta pak proběhnou bez uvolnění, nejvýš 20 denně na odkaz, zbytek zůstane návrhy. Zrušení důvěry na odkazu vrátí všechny jeho hosty naráz k návrhům.