JWT - řešení přístupu v mikroslužbách

[szdcf1sd561cas5c]

Ahojte,
s JWT mam uz skusenosti ale aktualne riesim to ze mam velku aplikaciu ktora sa sklada z mnozstva mikrosluzieb a rozmyslam ako sa riesi pristup ku jednotlivym objektom. Cize autorizacia, nie autentifikacia.

Konkretne ak ide o jwt tak bude obsahovat id usera ale napriklad uz nebude obsahovat informacie ohladom pristupu - cize ak mam nejaku mikroslubu kde tento user vytvoril 200 clankov tak mu nemozem do jwt nahadzat idcka vsetkych clankov aby som vedel ze k nim ma pristup, pripadne ze moze editovat clanky nejakeho ineho usera(na to su sice role). A ked sa sluzby vetvia a napriklad prva sluzba vie sparovat nejaky objekt s userom ale nejaka tretia sluzba uz ma len id nejakej entity a nie usera ktory ju vytvoril tak stracam informaciu pouzitelnu na autorizaciu nejakej akcie pre takehoto usera.

Tak by ma zuajimalo ako sa to normalne riesi?

[Reklama]

[Filip Jirsák]

Buď máte pár typů oprávnění (rolí), pak může být jejich seznam přímo součástí JWT. Nebo je rozhodování o oprávněních košatější, pak musí být konkrétní služba schopná podle ID uživatele, které dostane, určit, jaká oprávnění ten uživatel má. Uvádíte jako příklad seznam článků, které uživatel vlastní – pak toho vlastníka článku asi máte uloženého někde v databázi a příslušná služba si to musí umět načíst.

Teoreticky by ta služba mohla volat jinou službu na zjištění oprávnění, ale to by mi připadalo jako řešení „přes ruku“ – pokud ta služba potřebuje kvůli oprávněním znát vztah uživatel–článek, stejně nejspíš pracuje s databází, kde je tenhle vztah uložen. Ale tahle třetí možnost je spíš teoretická, neslyšel jsem o případu, kde by se to tak řešilo – v praxi se používá první nebo druhé řešení.

[Martin Sivák]

V jednom svém celkem jednoduchém projektu to řeším kombinací toho co popsal p. Jirsák.

- ID entity obsahuje ID vlastníka (protože ten se v mém případě nemění) a tudíž je jednoduché ověřit práva pro správu té entity.
- Pokud k objektu přistupuje jiný uživatel, tak se zkoumá jeho role a případně se pošle dotaz do separátní databáze se seznamem oprávnění.

[szdcf1sd561cas5c]

Tak som trochu pokrocil a dospel som k podobnemu modelu ako pouziva google cloud.
Mam ucet(uzivatel/sluzba), skupina, rola, opravnenie.

• ucet moze patrit do jednej alebo viacerych skupin
• skupina moze mat jednu alebo viacero roli
• ucet moze mat jednu alebo viacero roli
• rola moze mat jedno alebo viacero opravneni

Skupiny je mozne definovat cez administraciu, taktiez role a prava k nim. Prava nie, tie su definovane v kode. S tym ze existuje nejaky dopredu vytvoreny set roli a ich opravneni aby admini nemuseli pre kazdu novu organizaciu definovat vsetko od zakladu.

V systeme mam hierarchiu objektov(resource), cize napriklad clanok spada pod magazin ktory spada pod aplikacia ktora spada pod organizacia. Alebo organizacia->inventar->produkt->sklad->fyzicka polozka a tak podobne proste.

Kazdy objekt(resource) moze mat vytvorenu politiku pristupu a tato politika sa dedi pre potomkov daneho objektu(resource). Kazda politika linkuje 1 resource, 1 rolu a 1+ clenov(ucet alebo skupina).

Cize ked klient urobi nejaky dopyt tak dana routa si vytiahne ake opravneia potrebuje - moze to byt jednoduchy foo:create alebo request moze obsahovat nejakych rodicov(napr. vytvor clanok pre magazin 66) tak sa prava rozsiria na foo:create a magazine.66:write. Ak ma magazin nastavenu politiku tak sa porovna ci obsahuje rolu ktora ma vyzadovane opravnenia, ak nie tak traversuje nahor az kym sa nedostane do organizacie(co je resource/objekt sam o sebe). Kazda politika sa vyhodnocuje az kym sa nedospeje k true/false vysledku povolenia pristupu na danu routu. Tot oma vyhodu v tom ze 1+ politika moze pokryt aj stovky/vsetky objekty v organizacii.

Z hladiska vykonu ratam ze na proxyne sa len v JWT skontroluje scope alebo podobny zakladny zoznam, ziadna komplikovana logika, request sa pusti dalej na cielovu mikrosluzbu a ta bude mat lokalneho authZ agenta ktoremu mikrosluzba len doda pozadovane prava pre prichodzi dopyt a tento authZ klient uz riesi sam komunikaciu s hlavnym serverom, synchronizovanie zmien a td.

To je zaktualny plan. Co som prehladaval net tak to vyzera tak ze authZ je stale nevyrieseny problem a vzdy to konci na rieseni sitom na mieru. Riesenie od google sa mi paci, akurat treba sledovat hierarchiu objektov - ale to by som musel riesit aj bez toho. Nasiel som projekt Open Policy Agent, ktoreho vyhoda je ze umoznuje tvorbu naozaj dynamickych politik cez vlastne konfiguracne subory so specifickou syntaxou a vie si riesit synchronizaciu zmien. Zaujimalo by ma ci je to dobra cesta alebo riesenie na mieru bude pre moj pripad vhodnejsie? Pripadne ako to riesite vy vo svojich projektoch?