Prihlasovanie je prvá obrazovka, ktorú používateľ firemnej aplikácie uvidí, a zároveň posledná vec, na ktorú si niekto spomenie pri písaní zadania. Vo väčšine projektov sa objaví ako jedna odrážka — „prihlásenie používateľov" — a konkrétne rozhodnutia padnú niekedy v prvom týždni vývoja, bez toho, aby ich niekto vedome robil.
Problém je, že práve tieto rozhodnutia sa menia najťažšie. Kým je aplikácia prázdna, prehodiť spôsob prihlasovania je otázka dní. Keď v nej sedí dvesto účtov, história ich aktivity a tri integrácie, ktoré sa na tie účty odkazujú, je to samostatný projekt s migráciou a výpadkom. Tento článok prechádza tri veci, ktoré spolu tvoria správu používateľov: ako sa človek prihlási, ako dokáže, že je to naozaj on, a čo smie po prihlásení robiť.
Vlastné heslá alebo SSO?
Single sign-on (SSO) znamená, že aplikácia nemá vlastné heslá — overenie deleguje na identity providera, ktorého firma už používa. V praxi to býva Microsoft Entra ID (bývalé Azure AD) alebo Google Workspace, prípadne Keycloak či iné vlastné riešenie. Používateľ klikne na „Prihlásiť sa cez firemný účet", overí sa tam, kde sa overuje aj do e-mailu, a vráti sa späť.
Rozdiel nie je len v pohodlí. Pri SSO firma rieši prístupy na jednom mieste: keď zamestnanec odchádza, vypnutím firemného účtu mu naraz zmizne prístup aj do tejto aplikácie. Pri vlastných heslách musí niekto vedieť, že tá aplikácia existuje, a účet v nej zvlášť deaktivovať — a presne toto sa pri odchodoch zabúda.
| Vlastné heslá | SSO | |
|---|---|---|
| Kto spravuje účty | vaša aplikácia | firemný identity provider |
| Odchod zamestnanca | treba deaktivovať zvlášť | rieši sa centrálne |
| Vhodné pre | externých používateľov, zákazníkov | zamestnancov a interné tímy |
| Náročnosť vývoja | nižšia na začiatku | vyššia na začiatku, nižšia neskôr |
| Čo musí firma mať | nič | funkčný identity provider |
Voľba teda nezávisí od toho, čo je „modernejšie", ale od toho, kto sú používatelia. Interný systém pre zamestnancov je typický kandidát na SSO. Zákaznícky portál, kde sa registrujú ľudia mimo firmy, SSO použiť nemôže — tí firemnú identitu nemajú. Veľa aplikácií preto potrebuje oboje naraz: SSO pre interný tím a klasickú registráciu pre externých používateľov.
Dvojfaktorové overenie: nie každý faktor je rovnaký
Dvojfaktorové overenie (2FA, MFA) pridáva k heslu druhý dôkaz totožnosti. Metódy sa však líšia v tom, proti čomu vlastne chránia.
- SMS kód — najznámejší a používateľsky najprijateľnejší. Chráni pred útočníkom, ktorý získal iba heslo. Neochráni pred prevzatím telefónneho čísla u operátora ani pred phishingovou stránkou, ktorá kód zbiera v reálnom čase.
- Aplikačný autentifikátor (Microsoft Authenticator, Google Authenticator, 1Password) — kód sa generuje v zariadení a nikam sa neposiela. Odpadá riziko spojené s telefónnym číslom.
- Passkey / hardvérový kľúč — overenie je viazané na konkrétnu doménu, takže phishingová stránka ho nedokáže zneužiť, aj keby ju používateľ otvoril. Zároveň je to jediná z metód, ktorá je pre používateľa rýchlejšia než heslo.
Pri firemnej aplikácii je praktické pravidlo jednoduché: ak už používate SSO, dvojfaktor riešte na strane identity providera, nie v aplikácii. Firma tam má nastavené politiky, výnimky aj obnovu prístupu — duplikovať to v jednej aplikácii znamená druhé miesto, kde sa dá zabudnúť na zmenu.
Role a oprávnenia: tu sa to pokazí najčastejšie
Prihlásenie odpovedá na otázku „kto si". Oprávnenia odpovedajú na „čo smieš" — a to je tá časť, kde vzniká väčšina reálnych problémov. Nie preto, že by bola technicky ťažká, ale preto, že sa navrhuje podľa zlého kritéria.
Najčastejšia chyba je odvodiť role od organizačnej štruktúry: „riaditeľ", „vedúci oddelenia", „referent". Znie to logicky, ale v aplikácii to nefunguje, lebo pozícia nehovorí nič o tom, s akými dátami človek pracuje. Vedúci dvoch rôznych oddelení potrebuje vidieť úplne iné veci, a keď príde nová pozícia, nikto nevie, do ktorej role patrí.
Funkčnejší prístup je odvodiť role od činností: kto smie záznam vidieť, kto ho smie meniť, kto ho smie schvaľovať a kto smie meniť nastavenia systému. Tieto štyri úrovne pokryjú prekvapivo veľa aplikácií a hlavne prežijú reorganizáciu.
Druhá vec, ktorá sa podceňuje, je rozsah dát. Rola hovorí, čo človek smie robiť; rozsah hovorí, s čím to smie robiť. Obchodník smie meniť objednávky — ale ktoré? Všetky, alebo len svoje? Bez odpovede na túto otázku vznikne systém, kde má technicky správne nastavená rola prístup k celej databáze.
Čo si ujasniť pred vývojom
Tieto otázky sa oplatí zodpovedať v zadaní, nie počas implementácie:
- Kto sú používatelia — iba zamestnanci, iba externí ľudia, alebo oboje? Od toho sa odvíja SSO.
- Má firma identity providera a kto ho spravuje? Bez odpovede sa SSO nedá naplánovať.
- Aké činnosti existujú nad hlavnými dátami — vidieť, meniť, schvaľovať, spravovať? To sú kandidáti na role.
- Aký je rozsah pre každú rolu — všetko, vlastné záznamy, záznamy tímu, konkrétna pobočka?
- Ako sa účet zakladá a ruší — kto to robí, ako sa dozvie, že má, a čo sa stane s dátami po zrušení.
- Čo sa musí dať dohľadať — kto sa kedy prihlásil, kto zmenil čo. Auditná stopa sa dopĺňa spätne veľmi ťažko.
Pri interných systémoch, ktoré nahrádzajú tabuľky a e-maily, sa tieto otázky prehliadajú najviac — v Exceli predsa oprávnenia nikto neriešil. Práve preto je dobré prejsť si ich ešte pred rozhodnutím o rozsahu, o čom píšeme aj v článku o vývoji interného firemného systému.
Kde to súvisí so zvyškom architektúry
Správa používateľov nie je izolovaný modul. Ak aplikácia komunikuje s ďalšími systémami, tie potrebujú vedieť, v mene koho konajú — a to je iná úloha než prihlásenie človeka v prehliadači. Tomu, ako navrhovať rozhrania medzi systémami, sa venujeme v článku o API-first architektúre.
Rovnako platí, že čokoľvek, čo pracuje s osobnými údajmi, má priamu väzbu na to, kto k nim má prístup a ako sa to dá doložiť — praktickú stránku sme rozobrali v texte o spracovaní osobných údajov.
Zhrnutie
SSO voľte podľa toho, kto sú používatelia, nie podľa toho, čo je moderné — a ak ho nasadíte, riešte cez neho aj dvojfaktor. Role navrhujte podľa činností, nie podľa pozícií, a ku každej role si doplňte rozsah dát. Oprávnenia kontrolujte na serveri.
Rozsah tejto časti sa medzi projektmi líši viac, než by sa čakalo — závisí od počtu rolí, od toho, či firma identity providera už má, a od požiadaviek na auditnú stopu. Ak riešite novú firemnú aplikáciu alebo prerábate prístupy v existujúcej, prejdeme si konkrétne požiadavky na nezáväznej konzultácii.