PRZEJDŹ DO:
- 1. Czym jest usługa Azure Active Directory?
- 2. Czym jest aplikacja multi-tenant?
- 3. Rozpocznij pracę z usługą Azure AD
- 4. Rejestrowanie aplikacji multi-tenant
- 5. Logowanie do aplikacji jako użytkownik zewnętrzny
- 6. Aplikacja multi-tenant wywołująca wewnętrzne API
- 7. Zarządzanie tożsamościami – ograniczanie dostępu do aplikacji
- 8. Usługa Azure AD od Microsoft – podsumowanie
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.
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.
Przeczytaj także: Czym jest Azure IoT? Jakie daje możliwości? Jaki jest koszt usług i gdzie zdobyć niezbędną wiedzę?
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.
PRZEJDŹ DO:
- 1. Czym jest usługa Azure Active Directory?
- 2. Czym jest aplikacja multi-tenant?
- 3. Rozpocznij pracę z usługą Azure AD
- 4. Rejestrowanie aplikacji multi-tenant
- 5. Logowanie do aplikacji jako użytkownik zewnętrzny
- 6. Aplikacja multi-tenant wywołująca wewnętrzne API
- 7. Zarządzanie tożsamościami – ograniczanie dostępu do aplikacji
- 8. Usługa Azure AD od Microsoft – podsumowanie
Programista rozwiązań webowych, pracujący z nowoczesnymi stackami technologicznymi. Stawia na pierwszym miejscu rodzinę, ale znajduje też czas na sport i poszerzanie wiedzy o nowinki ze świata .NET. Uważa, że jeżeli można się podzielić wiedzą i doświadczeniem, to czemu tego nie robić?