Hej, nie miałem większej styczności z tym narzędziem stąd następujące pytanie ale wcześniej usecase:
Apka z bardzo niewielkim ruchem, integracja z googlem aby strzelać tam po niektóre zasoby, logowanie tylko przez SSO Google. Póki co tylko jeden klient webowy (może kiedyś mobilka ale to nie jest pewne). Kilka kont admina. Czy w takim wypadku keycloak to nie overkill? Po mojemu spring security by ograł ten usecase. Znacie może jakieś przykłady, gdzie keycloak faktycznie ma zastosowanie?
Keycloak - czy warto w tym wypadku
- Rejestracja: dni
- Ostatnio: dni
- Lokalizacja: Kraków
- Postów: 255
0
- Rejestracja: dni
- Ostatnio: dni
- Postów: 3303
0
Jeżeli chcesz logowania wyłącznie przez Google, to zrób to an poziomie jakiegoś tam API Gatewaya, albo nawet bezpośrednio w usłudze. Jedyna wątpliwość to jak chcesz ogarnąć autoryzację (masz mieć kilka typów użytkowników, musisz ich jakoś rozróżnić).
- Rejestracja: dni
- Ostatnio: dni
- Postów: 67
0
U ciebie role keycloaka pełni sso Googla z tego co rozumiem
- Rejestracja: dni
- Ostatnio: dni
- Lokalizacja: Kraków
- Postów: 255
0
piotrpo napisał(a):
Jeżeli chcesz logowania wyłącznie przez Google, to zrób to an poziomie jakiegoś tam API Gatewaya, albo nawet bezpośrednio w usłudze. Jedyna wątpliwość to jak chcesz ogarnąć autoryzację (masz mieć kilka typów użytkowników, musisz ich jakoś rozróżnić).
Może jakoś w konfig wbite id adminów (pewnie 2-3 konta) i w API serwisie check czy id principala == któryś z id z konfiga?
szprotki_w_oleju napisał(a):
U ciebie role keycloaka pełni sso Googla z tego co rozumiem
Ta, pytanie główne czy ten keycloak to nie overkill
- Rejestracja: dni
- Ostatnio: dni
- Postów: 3303
0
IMO - stawiany samodzielnie keycloak jest w tym przypadku dość sporym przekombinowaniem rozwiązania problemu. Trzymanie ról użytkowników w bazie, albo w kodzie to raczej taki sobie pomysł.
Mi dobrze się używało firebase - załatwi ci wszystko czego potrzebujesz (federację konta google i jak potrzebujesz to innych), wystawi gotowe do użycia JWT, pozwoli przypisywać role do kont użytkowników. Jak pisałem, mi się pracowało z tym bardzo dobrze, w projekcie trochę R&D, gdzie tempo było ważne, elegancja mniej. Trochę konfiguracji, obsłużenie w Spring Security potwierdzania tokenów, jak przestanie się podobać, to zawsze można dość łatwo przejść na jakieś własne rozwiązanie IAM.