Přihlašování a správa uživatelů: SSO, dvoufaktor a role ve firemní aplikaci

Přihlašování je první obrazovka, kterou uživatel firemní aplikace uvidí, a zároveň poslední věc, na kterou si někdo vzpomene při psaní zadání. Ve většině projektů se objeví jako jedna odrážka — „přihlášení uživatelů" — a konkrétní rozhodnutí padnou někdy v prvním týdnu vývoje, aniž by je někdo vědomě dělal.

Problém je, že právě tato rozhodnutí se mění nejhůř. Dokud je aplikace prázdná, změnit způsob přihlašování je otázka dní. Když v ní sedí dvě stě účtů, historie jejich aktivity a tři integrace, které se na ty účty odkazují, je to samostatný projekt s migrací a výpadkem. Tento článek prochází tři věci, které dohromady tvoří správu uživatelů: jak se člověk přihlásí, jak prokáže, že je to opravdu on, a co smí po přihlášení dělat.

Single sign-on (SSO) znamená, že aplikace nemá vlastní hesla — ověření deleguje na identity providera, kterého firma už používá. V praxi to bývá Microsoft Entra ID (dřívější Azure AD) nebo Google Workspace, případně Keycloak či jiné vlastní řešení. Uživatel klikne na „Přihlásit se firemním účtem", ověří se tam, kde se ověřuje i do e-mailu, a vrátí se zpět.

Rozdíl není jen v pohodlí. U SSO firma řeší přístupy na jednom místě: když zaměstnanec odchází, vypnutím firemního účtu mu naráz zmizí přístup i do této aplikace. U vlastních hesel musí někdo vědět, že ta aplikace existuje, a účet v ní zvlášť deaktivovat — a přesně na tohle se při odchodech zapomíná.

Volba tedy nezávisí na tom, co je „modernější", ale na tom, kdo jsou uživatelé. Interní systém pro zaměstnance je typický kandidát na SSO. Zákaznický portál, kde se registrují lidé mimo firmu, SSO použít nemůže — ti firemní identitu nemají. Spousta aplikací proto potřebuje obojí naráz: SSO pro interní tým a klasickou registraci pro externí uživatele.

Dvoufaktorové ověření (2FA, MFA) přidává k heslu druhý důkaz totožnosti. Metody se ale liší v tom, proti čemu vlastně chrání.

• SMS kód — nejznámější a uživatelsky nejpřijatelnější. Chrání před útočníkem, který získal pouze heslo. Neochrání před převzetím telefonního čísla u operátora ani před phishingovou stránkou, která kód sbírá v reálném čase.
• Aplikační autentikátor (Microsoft Authenticator, Google Authenticator, 1Password) — kód se generuje v zařízení a nikam se neposílá. Odpadá riziko spojené s telefonním číslem.
• Passkey / hardwarový klíč — ověření je vázané na konkrétní doménu, takže phishingová stránka ho nedokáže zneužít, i kdyby ji uživatel otevřel. Zároveň je to jediná z metod, která je pro uživatele rychlejší než heslo.

U firemní aplikace je praktické pravidlo jednoduché: pokud už používáte SSO, dvoufaktor řešte na straně identity providera, ne v aplikaci. Firma tam má nastavené politiky, výjimky i obnovu přístupu — duplikovat to v jedné aplikaci znamená druhé místo, kde se dá zapomenout na změnu.

Přihlášení odpovídá na otázku „kdo jsi". Oprávnění odpovídají na „co smíš" — a to je ta část, kde vzniká většina reálných problémů. Ne proto, že by byla technicky těžká, ale proto, že se navrhuje podle špatného kritéria.

Nejčastější chyba je odvodit role od organizační struktury: „ředitel", „vedoucí oddělení", „referent". Zní to logicky, ale v aplikaci to nefunguje, protože pozice neříká nic o tom, s jakými daty člověk pracuje. Vedoucí dvou různých oddělení potřebují vidět úplně jiné věci, a když přijde nová pozice, nikdo neví, do které role patří.

Funkčnější přístup je odvodit role od činností: kdo smí záznam vidět, kdo ho smí měnit, kdo ho smí schvalovat a kdo smí měnit nastavení systému. Tyto čtyři úrovně pokryjí překvapivě hodně aplikací a hlavně přežijí reorganizaci.

Druhá věc, která se podceňuje, je rozsah dat. Role říká, co člověk smí dělat; rozsah říká, s čím to smí dělat. Obchodník smí měnit objednávky — ale které? Všechny, nebo jen svoje? Bez odpovědi na tuto otázku vznikne systém, kde má technicky správně nastavená role přístup k celé databázi.

Tyto otázky se vyplatí zodpovědět v zadání, ne během implementace:

1. Kdo jsou uživatelé — jen zaměstnanci, jen externí lidé, nebo obojí? Od toho se odvíjí SSO.
2. Má firma identity providera a kdo ho spravuje? Bez odpovědi se SSO nedá naplánovat.
3. Jaké činnosti existují nad hlavními daty — vidět, měnit, schvalovat, spravovat? To jsou kandidáti na role.
4. Jaký je rozsah pro každou roli — všechno, vlastní záznamy, záznamy týmu, konkrétní pobočka?
5. Jak se účet zakládá a ruší — kdo to dělá, jak se dozví, že má, a co se stane s daty po zrušení.
6. Co se musí dát dohledat — kdo se kdy přihlásil, kdo změnil co. Auditní stopa se doplňuje zpětně velmi těžko.

U interních systémů, které nahrazují tabulky a e-maily, se tyto otázky přehlížejí nejvíc — v Excelu přece oprávnění nikdo neřešil. Právě proto je dobré projít si je ještě před rozhodnutím o rozsahu, o čemž píšeme i v článku o vývoji interního firemního systému.

Správa uživatelů není izolovaný modul. Pokud aplikace komunikuje s dalšími systémy, ty potřebují vědět, jménem koho jednají — a to je jiná úloha než přihlášení člověka v prohlížeči. Tomu, jak navrhovat rozhraní mezi systémy, se věnujeme v článku o API-first architektuře.

Stejně tak platí, že cokoli, co pracuje s osobními údaji, má přímou vazbu na to, kdo k nim má přístup a jak se to dá doložit — praktickou stránku jsme rozebrali v textu o zpracování osobních údajů.

SSO volte podle toho, kdo jsou uživatelé, ne podle toho, co je moderní — a pokud ho nasadíte, řešte přes něj i dvoufaktor. Role navrhujte podle činností, ne podle pozic, a ke každé roli si doplňte rozsah dat. Oprávnění kontrolujte na serveru.

Rozsah této části se mezi projekty liší víc, než by se čekalo — závisí na počtu rolí, na tom, jestli firma identity providera už má, a na požadavcích na auditní stopu. Pokud řešíte novou firemní aplikaci nebo předěláváte přístupy ve stávající, projdeme si konkrétní požadavky na nezávazné konzultaci.