Mam 3 serwisy: A) Serwis autoryzacyjny - IdentityServer B) Serwis 1 C) Serwis 2 - Nowy serwis
Serwisy te mają osobne fronty, osobne backendy, osobne bazy i co kluczowe mają osobne role i uprawnienia. Chcemy teraz w konkretnych aplikacjach sprawdzać do czego użytkownik ma dostęp a do czego nie na podstawie ról i uprawnień które siedzą w bazach konkretnych serwisów.
Dotychczas gdy był tylko serwis autoryzacyjny i serwis 1 działało to tak że podczas tworzenia tokenu identity serwer strzelał do bazy serwisu 1 wyciągał z niej dane jakie potrzebował i z tego składał sobie token. Jednak gdy doszedł kolejny serwis no to rozwiązanie to stało się trochę słabe (mimo że już na początku było słabe, ale działało ( ͡°͜ʖ͡°)) bo trzeba dobijać się do kolejnej bazy kolejnego serwisu a jak dojdzie kolejny serwis to co ? znowu kolejny dostęp do kolejnej bazy?
Pytanie jak to zrobić dobrze, rozwiązania jakie widzę to: A) W sposób klasyczny, jeśli potrzebujemy jakieś dane dotyczące uprawnień to strzelamy do api odpowiedniego serwisu i uzyskujemy role/uprawnienia etc. Minusem tego rozwiązania jest to że dosyć mocno spamujemy bazę nawet po wprowadzeniu jakiegoś mechanizmu cache'owania to i tak tych odpytań może być sporo.
B) Wystawiamy 2 tokeny. Jeden od IdentityServer, drugi od konkretnego serwisu. W momencie wygaśnięcia tokenu z Identity odświeżamy również token z serwisu
C) ????
P.S W tokenie poza danymi nt. uprawnień siedzą też inne dane np. dotyczące organizacji w jakiej znajduje się użytkownik. Jednak ta organizacja ma znaczenie tylko w obrębie jednego serwisu. Inny serwis wgl. nie ma pojęcia o organizacjach i nie ma to dla niego żadnego znaczenia.
@Kirdian: Rozumiem że jeśli w nowym serwisie chciałbym zastosować, zamiast systemu ról, system uprawnień to tylko dokładam tabelkę w identity + wiele do wielu permissions <-> users i dokładam sobie jakiegoś claimsa w jwttokenie i ogień ?
Mam 3 serwisy:
A) Serwis autoryzacyjny - IdentityServer
B) Serwis 1
C) Serwis 2 - Nowy serwis
Serwisy te mają osobne fronty, osobne backendy, osobne bazy i co kluczowe mają osobne role i uprawnienia. Chcemy teraz w konkretnych aplikacjach sprawdzać do czego użytkownik ma dostęp a do czego nie na podstawie ról i uprawnień które siedzą w bazach konkretnych serwisów.
Dotychczas gdy był tylko serwis autoryzacyjny i serwis 1 działało to tak że podczas tworzenia tokenu identity serwer strzelał do bazy serwisu 1 wyciągał z niej dane jakie potrzebował i z tego składał sobie token. Jednak gdy doszedł kolejny serwis no to rozwiązanie to stało się trochę słabe (mimo że już na początku było słabe, ale działało ( ͡° ͜ʖ ͡°)) bo trzeba dobijać się do kolejnej bazy kolejnego serwisu a jak dojdzie kolejny serwis to co ? znowu kolejny dostęp do kolejnej bazy?
Pytanie jak to zrobić dobrze, rozwiązania jakie widzę to:
A) W sposób klasyczny, jeśli potrzebujemy jakieś dane dotyczące uprawnień to strzelamy do api odpowiedniego serwisu i uzyskujemy role/uprawnienia etc. Minusem tego rozwiązania jest to że dosyć mocno spamujemy bazę nawet po wprowadzeniu jakiegoś mechanizmu cache'owania to i tak tych odpytań może być sporo.
B) Wystawiamy 2 tokeny. Jeden od IdentityServer, drugi od konkretnego serwisu. W momencie wygaśnięcia tokenu z Identity odświeżamy również token z serwisu
C) ????
P.S W tokenie poza danymi nt. uprawnień siedzą też inne dane np. dotyczące organizacji w jakiej znajduje się użytkownik. Jednak ta organizacja ma znaczenie tylko w obrębie jednego serwisu. Inny serwis wgl. nie ma pojęcia o organizacjach i nie ma to dla niego żadnego znaczenia.
#programowanie #webdev #dotnet #angular #mikroserwisy
Opcja A) z Cachem jest chyba okej a jeśli live span cache'a będzie dłuższy niż czas życia accestokenu to jest to nawet bardziej optymalna opcja
Opcja B) Nie ma sensu co wyjaśnie pod spodem
Opcja C) Zaproponowana przez mireczków, czyli role i permissiony w IdentityServer ma jak najbardziej sens i racje bytu
Dlaczego mój genialny pomysł z generowaniem drugiego