Planujemy przekształcić system naszej firmy w system oparty na mikrousługach. Z tych mikro-usług będą korzystać nasze własne wewnętrzne aplikacje firmy oraz w razie potrzeby partnerzy zewnętrzni. Jeden do rezerwacji, drugi do produktów itp.
Nie jesteśmy pewni, jak radzić sobie z rolami i zakresami. Chodzi o to, aby utworzyć 3 podstawowe role użytkowników, takie jak administratorzy, agenci i użytkownicy końcowi, i pozwolić aplikacjom konsumenckim na dostosowanie zakresów w razie potrzeby.
- Administratorzy mogą domyślnie tworzyć, aktualizować, czytać i usuwać wszystkie zasoby (dla swojej firmy).
- Agenci mogą tworzyć, aktualizować i odczytywać dane swojej firmy.
- Użytkownicy końcowi mogą tworzyć, aktualizować, usuwać i odczytywać dane, ale nie mają dostępu do tych samych punktów końcowych co agenci lub administratorzy. Będą także mogli tworzyć lub modyfikować dane, ale nie na tym samym poziomie co agenci lub administratorzy. Na przykład użytkownicy końcowi mogą aktualizować lub czytać informacje o swoim koncie, tak samo jak agent będzie mógł to dla nich zrobić, ale nie widzą ani nie aktualizują notatek administratora.
Powiedzmy, że agenci domyślnie mogą tworzyć, odczytywać i aktualizować każdy zasób dla swojej firmy i to jest ich maksymalny zakres, którego można żądać dla tokena / sesji, ale programiści aplikacji klienckiej (API-konsument) zdecydowali, że jeden z ich agentów może czytaj i twórz tylko niektóre zasoby.
Czy lepiej jest radzić sobie z tym w naszym wewnętrznym bezpieczeństwie i pozwolić im zapisywać te dane w naszej bazie danych, czy pozwolić klientom obsługiwać to wewnętrznie, żądając tokena o mniejszym zakresie, i pozwól im napisać, który agent będzie miał zakres w swojej bazie danych ? W ten sposób musielibyśmy śledzić tylko zakresy tokena.
Wadą tego jest to, że nasz zespół musiałby również stworzyć mechanizmy dostępu dostosowane do naszych wewnętrznych aplikacji.
Przy takim sposobie myślenia, mikrousługom i ich systemowi autoryzacji nie należy przejmować się potrzebami klientów, ponieważ są oni tylko konsumentami, a nie częścią systemu (nawet jeśli niektórzy z tych konsumentów są naszymi wewnętrznymi aplikacjami)?
Czy ta delegacja jest dobrym podejściem?
payment:[read]
, sprzedawca mapayment: [create]
. Czy agregujesz uprawnienia w tym przypadku?(resource/action)
, musisz je połączyć. Jeśli uprawnienia się pokrywają, należy je agregować. Chodzi o to, aby zdefiniować tylko zasoby i działania dozwolone w tokenie, pozostawiając role jako abstrakcję używaną, aby dać klientom mniej skomplikowany sposób radzenia sobie z autoryzacją.user
właściwość w swoim ładunku. Sposób, w jaki blokuję zasób będący własnością użytkownika, polega na mapowaniuuser
roszczenia na adres URL. Na przykład:/users/coyote/back-account
byłby dostępny tylko przez token zuser
roszczeniem równymcoyote
. Mam nadzieję, że ta pomoc.Myślę, że bez względu na wszystko, chcesz, aby twoje usługi akceptowały token uwierzytelniania, który jest zapewniany przez usługę uwierzytelniania, którą piszesz w celu weryfikacji użytkowników. Jest to najprostszy / bezpieczny sposób, aby zapobiec niewłaściwemu użyciu mikrousług. Ponadto, ogólnie rzecz biorąc, jeśli chcesz, aby klient miał dobre doświadczenia, powinieneś samodzielnie wdrożyć najważniejsze funkcje i dokładnie przetestować, aby upewnić się, że oferowane funkcje są dobrze wdrożone.
Ponieważ wszyscy dzwoniący muszą przedstawić mikrousługom dowód, że zostali uwierzytelnieni, równie dobrze możesz powiązać uprawnienia z tym uwierzytelnieniem. Jeśli zapewnisz możliwość powiązania użytkownika z dowolną grupą dostępu (lub grupami, jeśli chcesz się podoba, chociaż trudniej jest tutaj poradzić sobie z dodawaniem i odejmowaniem uprawnień). Od twoich klientów będzie mniej pytań o to, dlaczego użytkownik x był w stanie wykonać niepożądaną operację. W każdym razie ktoś musi sprawdzić listę dostępu dla każdej usługi, więc równie dobrze może to być Ty. Jest to coś, co bardzo łatwo byłoby zakodować na początku wszystkich usług (
if ( !TokenAuthorized(this.ServiceName, this.token) { Raise error }
) Abyś mógł to zrobić i samemu śledzić grupy użytkowników. To prawda, że będziesz musiał mieć menedżera grupy uprawnień i pracować z nim w interfejsie zarządzania użytkownikami (użyj istniejącej / utwórz nową grupę dla uprawnień użytkowników) Zdecydowanie wyświetl listę użytkowników powiązanych z grupą podczas edycji definicji, aby uniknąć nieporozumień . Ale to nie jest trudna praca. Wystarczy mieć metadane dla wszystkich usług i powiązać wyszukiwanie mapowania między grupą a usługą w obsłudze tokenu uwierzytelniającego.Ok, więc jest kilka szczegółów, ale każdy z klientów, którzy chcą tej funkcji, musiałby ją w każdym razie zakodować, a jeśli popierasz trzypoziomowe uprawnienia użytkownika, możesz po prostu rozszerzyć ją na dostęp dla poszczególnych użytkowników grupy. Prawdopodobnie logicznym skrzyżowaniem między uprawnieniami grupy podstawowej a uprawnieniami specyficznymi dla użytkownika byłaby właściwa agregacja, ale jeśli chcesz mieć możliwość dodawania i odbierania podstawowych uprawnień administratora, agenta, podstawowych uprawnień użytkownika, musisz to zrobić użytkowa trójstanowa flaga w grupach uprawnień: Dodaj zezwolenie, Odmów zezwolenia, Domyślne zezwolenie i odpowiednio łącz uprawnienia.
(Uwaga: to wszystko powinno się zdarzyć w przypadku czegoś takiego jak SSL lub nawet dwukierunkowy SSL, jeśli obawiasz się o bezpieczeństwo obu końców rozmowy. Jeśli „wyciekniesz” te tokeny do atakującego, jest on jakby „ d złamał hasło).
źródło
Moim zdaniem masz tutaj dwie możliwości.
Jeśli potrzebujesz tylko konfigurowalnego dostępu do zasadniczo tej samej aplikacji, to masz uprawnienia do sprawdzania usług i daj swoim klientom interfejs, który pozwala im zmieniać uprawnienia nadawane każdej roli. Dzięki temu większość użytkowników może korzystać z domyślnej konfiguracji ról, którą „problematyczni” klienci mogą modyfikować role lub tworzyć nowe w zależności od potrzeb.
Jeśli Twoi klienci opracowują własne aplikacje, powinni wprowadzić własne pośrednie API. Która łączy się z Twoją administracją, ale sprawdza połączenia przychodzące z własnymi niestandardowymi wymaganiami uwierzytelniania przed wywołaniem twoich usług
źródło
Względy bezpieczeństwa
Jeśli dobrze rozumiem twój projekt, zamierzasz przekazać niektóre mechanizmy kontroli dostępu do zasobów po stronie klienta, tj. Aplikacja konsumująca zmniejsza liczbę elementów, które użytkownik może zobaczyć. Twoje założenie jest następujące:
Widzę tutaj dwa poważne problemy dla poważnego biznesu:
Dlatego radzę przewidywać takie zdarzenia i zajmować się wnioskami o autoryzację. Jesteś na wczesnym etapie przebudowy i o wiele łatwiej będzie je uwzględnić w swojej architekturze (nawet jeśli nie zaimplementujesz ich wszystkich) niż później.
Jeśli kontynuujesz swoje obecne stanowisko, skonsultuj się przynajmniej z inspektorem bezpieczeństwa informacji.
Jak to wdrożyć
Masz sztuczkę:
Ok, zamierzasz użyć niektórych ogólnych tokenów wybranych przez klienta. Znów słabość w moim oku, ponieważ niektórzy klienci mogą wymknąć się spod kontroli.
Nie wiem, czy już używasz JWT, czy używasz innych technik. Ale jeśli używasz JWT, możesz mieć token tożsamości, który przenosi tożsamość użytkownika (a nawet drugi token, który bezpiecznie identyfikuje aplikację źródłową, co może pozwolić ci na rozróżnienie poziomu zaufania między klientami wewnętrznymi a klientami zewnętrznymi ).
Jeśli zamierzasz wybrać architekturę mikrousług, chciałbym zasugerować różnicę między zarządzaniem użytkownikami i procesem uwierzytelniania (który powinien działać jako usługa dedykowana) a kontrolą dostępu (która jest specyficzna dla każdej mikrousługi i powinna być obsługiwany lokalnie przez każdego z nich). Oczywiście, aby ułatwić obsługę, niektóre klienty administracyjne powinny dać kompleksowy przegląd kilku usług).
źródło
Tutaj też jest krótka odpowiedź. Powinieneś sam wdrożyć wszystkie podstawowe funkcje, które chcesz zaoferować swoim „klientom”. Problematyczne wydaje się, aby klienci dodawali takie podstawowe zachowania, jak same uprawnienia użytkownika, ponieważ już wykonujesz uwierzytelnianie użytkownika; jeśli zostawisz to klientowi, aby go zaimplementować, może skończyć się „wspieraniem” wielu implementacji tego samego kodu uprawnień. Nawet jeśli nie jesteś „właścicielem”, w kodzie pojawią się błędy i chcesz, aby Twoi klienci mieli funkcjonalność, której oczekiwali, z uzasadnionego powodu, więc wspierasz rozwiązywanie problemów, które ma klient. Obsługa wielu baz kodu nie jest przyjemnością.
źródło