Authenticator (Github, viz odkazy >> Wiki)¶

• JWT SECRET KEY >> application.properties (secret.key=) >> nutné vyplnit. Používá se pro ověřování tokenů.

Popis autentikační aplikace¶

• Autentikační aplikace je obecně samostatná spring boot aplikace, z čehož plyne, že musí být spuštěna ihned se SPADe aplikací, jinak SPADe sám o sobě nebude funkční, jelikož se mu nebudou dostávat hodnoty 200 pro autentizaci uživatele a uživatel tak nebude moct s aplikací pracovat, protože mu budou vráceny hodnoty 4XX s patřičnými chybovými hláškami.

• Předchozí bod musí být brán s rezervou... ReactJS (webová aplikace) bude samozřejmě plně funkční včetně konkrétních funkcionalit, které nemusí být autentizovány (nejsou závislé na přihlášení a uživatelské roli). Nicméně v jiných případech bude server SPADe automaticky vracet webové aplikaci 4XX hodnoty, jelikož nebude schopný autentizovat jednotlivé requesty.

• Aplikace není viditelná uživateli. Je situovaná tak, že veřejně vystrčené aplikace jsou pouze SPAWn (webová aplikace) a SPADe (hlavní backend s REST API endpointy). Autentikační aplikace by měla běžet samostatně v interní síti a měla by být viditelná pouze SPADe aplikaci, nikoli SPAWn aplikaci, což by mělo zajistit bezpečné odstínění implementací a nemožnosti XSS útoků a jiným útokům, které by byly snadno dosažitelné v jiných případech, kdy by celá aplikace byla vystrčena veřejnosti ven.

Komunikace SPADe -> Autentikátor¶

Implementace komunikace na straně SPADe aplikace¶

• Všechny konkrétní implementace spravující komunikaci (filtrování requestů a autentizaci) jsou umístěny v package v2/security

• Ve SPADe aplikaci byla implementována (dle patřičných návodů) speciální konfigurační třída, u které se pomocí anotace zapnula autentikace veškerých requestů přicházejících na SPADe aplikace z webové aplikace SPAWn.

• První kritický bod: implementována třída WebSecurityConfig, která dědí od Spring Boot třídy WebSecurityConfigurerAdapter, jenž nutí implementaci config metody, ve které se zapíná základní nastavení autentizačních praktik.

• Druhý kritický bod: Při definování config metody z předchozího bodu bylo nutné vytvořit třídu, která dělá samotný "router" z předchozího nakonfigurování adapteru. Tato třída dělající samotný router se jmenuje JwtAuthenticationFilter.java a dědí od třídy OncePerRequest, což má za úkol zajistit idempotentnost, jinými slovy: pokud by se stalo, že by více vláken zaslalo jeden a ten samý request ze strany SPAWn, tak se vykoná pouze jednou. Zde je implementována metoda doInternalFilter, ve kterém odchytáváme všechny requesty. U těchto requestů kontrolujeme autentizaci (zda na to má uživatel právo) zasláním requestu s JWT tokenem extrahovaným z hlavičky od uživatele na autentikační aplikaci. Více informací je v další kapitole u Autentikační aplikace.

• SPADe pro kontrolování autentizace zasílá s každým (autentizovaným) requestem žádost na REST API endpoind auth aplikace localhost:<PORT>/authenticate s přiloženým JWT tokenem.

Šifrování headers ze strany SPADe -> Auth.¶

// TODO v následujících iteracích.

Implementace komunikace na straně Autentikační aplikace¶

• Z předchozího bodu byl popsán způsob komunikace na auth aplikaci.

• Auth aplikaci přijde request na přihlášení uživatele na endpoind /login, který si poté provolá vlastní službu pro vytvoření JWT tokenu s patřičnými údaji, které mu přišly v body requestu. Tento JWT token je poté zaslán zpět na SPADe aplikaci a ze SPADe aplikace ke klientovi na webovou aplikaci (SPAWn), kde je konkrétní implementace pro uložení JWT tokenu bezpečným způsobem, aby nebylo možné jej jednoduše ukrást pomocí XSS útoku. Tento token je poté zasílán s requesty, které je nutné autentikovat, což zařizuje router ve SPADe aplikaci.

• Autentikace (validace) JWT tokenu se provádí zasláním SPADe requestem na Auth aplikaci na endpoint /authenticate, kde je očekáván JWT token. Authentikační aplikace má samozřejmě JWT_Secret key, který je pro šifrování / dešifrování tokenu, což umožňuje ověření platnosti tokenu. Zasílá buď 200 v případě, že je token validní a neexpiroval. 400 v jiných případech.

• Auth aplikace má připraven i endpoint na obnovení tokenu. Tento token nesmí být expirovaný v aktuální verzi. Nicméně funguje tak, že mu přijde žádost na /refresh, ten daný token zvaliduje, odstraní ho z mapy vygenerovaných tokenů a zašle zpět uživateli nový. Tento token je samozřejmě uložen v mapě místo stávajícího starého klíče.