Usługa Azure Active Directory w aplikacjach multi-tenant

Zarządzanie dostępami do aplikacji jest zagadnieniem poruszanym w przypadku niemal każdego systemu. Dbając o odpowiednie uwierzytelnianie, nie tylko ograniczamy możliwości pozyskania czy modyfikowania wrażliwych danych, ale mamy również większą elastyczność w przypadku tzw. User Experience, poprzez definiowanie ról czy właściwości związanych z danym użytkownikiem. 

Budowanie systemu do zarządzania poświadczeniami od podstaw jest bardzo trudnym zadaniem i wymaga ogromnej wiedzy z zakresu bezpieczeństwa. Na szczęście na rynku dostępne są gotowe rozwiązania, takie jak np. Azure Active Directory (AAD). 

Czym jest usługa Azure Active Directory? 

Azure Active Directory (AAD) jest serwisem chmurowym firmy Microsoft pozwalającym na zarządzanie dostępami i tożsamościami. Korzystając z tego rozwiązania, możemy również rejestrować nasze aplikacje i określać zasady dostępności. Przy czym rozważamy tutaj zarówno dostępy użytkowników, jak i innych aplikacji. Do zarejestrowanego rozwiązania w danej dzierżawie (z ang. tenant ) dostęp mogą mieć wszystkie obiekty (użytkownicy, aplikacje) ją współdzielące. AAD pozwala również na „udostępnianie” aplikacji innym najemcom, dzięki czemu nie musimy martwić się o zarządzanie użytkownikami zewnętrznymi naszej aplikacji. Tak skonfigurowane rozwiązanie nazywamy multi-tenantowym. 

Czym jest aplikacja multi-tenant? 

Aplikacja typu multi-tenant pozwala obsługiwać wielu dzierżawców poprzez jedną instancję. Przy tego typu rozwiązaniach istotne jest, aby klient nie miał dostępu do danych należących do innych najemców. Jest to najczęściej rozwiązywane poprzez logikę biznesową lub rozdzielenie baz danych tak, aby każdy klient miał własną. 

Aplikacja wielodostępowa zarejestrowana w Azure Active Directory pozwala przenieść zarządzanie użytkownikami i określanie poziomu dostępu do rozwiązania na barki administratora danego dzierżawcy. Zmniejsza to koszty związane z utrzymywaniem użytkowników po stronie dostawcy usługi.  

Należy jednak pamiętać, że kwestia dostępu do poszczególnych elementów aplikacji jest dalej rozwiązywana przez programistów poprzez definiowanie odpowiednich polityk w kodzie. 

Rozpocznij pracę z usługą Azure AD

Firma Microsoft udostępnia administratorom materiały niezbędne do zarządzania usługami w Azure Portalu.  Dokumentacja zawiera też odpowiedzi na często zadawane pytania. Wszelkie informacje są dostępne na stronie Microsoft Azure Active Directory,  gdzie można się dowiedzieć wszystkiego na temat zarządzania tożsamością i dostępami w chmurze. Jeżeli jeszcze nie korzystasz z usług Microsoft Azure, warto zacząć właśnie w tym miejscu.   

Rejestrowanie aplikacji multi-tenant 

Podczas rejestracji nowej aplikacji jesteśmy zobligowani do wybrania, jakiego rodzaju konta chcemy wspierać. Wybierając opcję zaznaczoną poniżej, dajemy możliwość dostępu innym dzierżawcom. Jeżeli mamy wątpliwości, którą opcję wybrać, pod sekcją znajduje się link z krótkim opisem, na co zezwala każda z nich. 

Zarejestrowanie obiektu aplikacji powoduje utworzenie aplikacji biznesowej, a dokładniej jednostki usługi (z ang. Service Principal). To właśnie do jednostki usługi są podpinane dostępy użytkownika do aplikacji. Dokładnie ten sam mechanizm jest wykorzystywany w przypadku zewnętrznych klientów. 

Logowanie do aplikacji jako użytkownik zewnętrzny  

Przy pierwszej próbie logowania do aplikacji jesteśmy poproszeni o udzielenie zgody dla danej aplikacji. W zależności od ustawień dzierżawcy będziemy mogli sami jej udzielić lub będzie ona wymagała zatwierdzenia przez administratora.  

Warto nadmienić, że administrator udziela zgody dla wszystkich użytkowników, przez co tylko pierwsze logowanie do aplikacji jakimkolwiek użytkownikiem będzie wywoływać prośbę o udzielenie uprawnień.  

Przy samoakceptacji (self-consent) będzie ona wywoływana indywidualnie dla każdego użytkownika przy pierwszej próbie logowania. 

Tu u niektórych z was mogą pojawić się obawy: czy zezwalając na dostęp do danych użytkownika, przydzielamy go dostawcy, u którego aplikacja została zarejestrowana? Spokojnie, nie do końca tak jest. Podobnie jak w przypadku dzierżawcy pierwotnego tworzona jest jednostka usługi jako aplikacja biznesowa, i to w zależności od ustawionych dostępów względem niej nasze rozwiązanie pozyskuje informacje o aktualnie zalogowanym użytkowniku. 

Gdy DevOps lub inżynier rejestruje aplikację i chce, aby logowano się do niej przez Microsoft, docelowa aplikacja z docelowymi dostępami używanymi przy logowaniu utworzy się automatycznie podczas rejestracji. Nie ma wówczas potrzeby, by użytkownicy wyrażali zgodę dla aplikacji w tej dzierżawie. 

Czym jest Azure IoT? Jakie daje możliwości? Jaki jest koszt usług i gdzie zdobyć niezbędną wiedzę?

PRZECZYTAJ ARTYKUŁ

Aplikacja multi-tenant wywołująca wewnętrzne API 

Często, zwłaszcza w przypadku mikroserwisów, zdarza się, że nasza aplikacja komunikuje się z inną poprzez jej API. Kiedy dzieje się to w modelu serwis do serwisu, wystarczy, że zagwarantujemy dostęp w dzierżawie dostawcy. Sytuacja komplikuje się, kiedy chcemy aby aplikacja komunikowała się poprzez API w imieniu zalogowanego użytkownika. 

Dla rozwiązania multi-tenantowego musimy zagwarantować, że API ma swojego reprezentanta u najemcy w postaci jednostki usługi, co wymusza publiczną dostępność szablonu API. Wszystko za sprawą mechanizmu weryfikacji dostępów, który tak naprawdę ma miejsce ramach tenanta, tj. dzierżawcy użytkownika. Dlatego należy dokładnie przemyśleć model komunikacji między aplikacjami. 

Istotne jest, aby w zarejestrowanym obiekcie aplikacji API zdefiniować aplikację webową jako jedną ze zautoryzowanych – dzięki temu klient będzie mógł zezwolić na dostęp do API, a tym samym jednostka usługi zostanie zarejestrowana w jego dzierżawie. 

Zarządzanie tożsamościami – ograniczanie dostępu do aplikacji 

Jak już wspomniałem, w momencie pojawienia się aplikacji biznesowej u danego dzierżawcy każdy użytkownik ma do niej dostęp. Możemy jednak to ograniczyć.  

Jeżeli chcemy, aby tylko określeni użytkownicy czy też grupa użytkowników miała dostęp, musimy ustawić naszą jednostkę usługi w taki sposób, żeby wymagała przypisania. 

Wtedy, aby użytkownik bądź grupa miała dostęp, aplikacja musi widnieć w przypisanych do użytkownika lub grupy. 

Innym sposobem na modyfikowanie dostępów do aplikacji jest dostęp warunkowy, który pozwala wymuszać pewne zachowania bądź blokować dostęp w zależności od ustawionych scenariuszy. Opcja ta jest jednak dostępna w wersji Premium Azure Active Directory. Informacje o planach cenowych i dostępnych usługach znajdziesz na stronie Microsoft Azure. 

Usługa Azure AD od Microsoft – podsumowanie 

Aplikacja wielodostępowa pozwala zredukować koszty poprzez współdzielenie jednej instancji przez wielu klientów. Zastosowanie Azure Active Directory do zarejestrowania takiego rozwiązania ogranicza dodatkowo koszty związane z utrzymywaniem użytkowników, gdyż niejako korzystamy z tych należących do najemcy. To od administratora dzierżawcy, który chce mieć dostęp, zależy, komu i w jakim zakresie chce go przydzielić. 

Niestety ograniczamy się wtedy tylko do klientów Microsoft, przez co możemy być mniej konkurencyjni. Jeżeli chcielibyśmy mieć rozwiązanie dostępne dla klientów niezależnie od dostawcy poświadczeń którego używają, ciekawą opcją jest Azure Active Directory B2C z Single Sign-On.