Zarządzanie tożsamością i dostępem użytkownika, czyli o co chodzi z IDP?

Autor:
Zespół Innokrea

Data publikacji: 2024-12-11

Kategorie: Bezpieczeństwo

Hej w dzisiejszym wpisie jako Innokrea opowiemy Wam czym jest tożsamość użytkownika, z czego wynika potrzeba zarządzania dostępem w firmie i jak działa tzw IDP (ang. Identity provider). Jeśli nie czytaliście naszego artykułu odnośnie uwierzytelnienia i autoryzacji to zachęcamy do lektury, ze względu na to, że używane tam pojęcia pojawią się także w dzisiejszym tekście.

Czym jest zarządzanie tożsamością?

Zarządzanie tożsamością to kluczowy element wielu dzisiejszych systemów informatycznych oraz jeden z podstawowych procesów wspomagających działanie firmy polegający na zweryfikowaniu tożsamości użytkownika i zarządzaniu jego dostępem do odpowiednich zasobów firmy. Pod tym pojęciem kryje się wiele kluczowych procesów, takich jak uwierzytelnianie, autoryzacja, zarządzanie cyklem życia konta oraz zapewnienie łatwości i wygody korzystania z systemów z perspektywy użytkownika. Pojęcia te można wyjaśnić w następujący sposób:

Uwierzytelnianie – proces weryfikacji tożsamości użytkownika, który polega na potwierdzeniu, że użytkownik jest tym, za kogo się podaje np. poprzez hasło.
Autoryzacja – proces nadawania uprawnień i kontrolowania, do których zasobów użytkownik może uzyskać dostęp na podstawie wcześniej zweryfikowanej tożsamości (uwierzytelnienie).
Zarządzanie cyklem życia konta użytkownika obejmuje tworzenie konta, nadawanie i modyfikację uprawnień, automatyzację procesów takich jak zakładanie i usuwanie konta w systemie, a także audyt i monitorowanie działań użytkownika oraz uprawnień.
Łatwość użytkowania jest istotnym elementem współczesnych systemów zarządzania tożsamością, ponieważ wpływa na produktywność użytkowników i minimalizuje frustracje związane z procesami logowania (np. powtórnym przy każdej zmianie aplikacji) czy resetowania haseł.

elementy zarządzania tożsamością użytkownika

Rysunek 1 – elementy zarządzania tożsamością użytkownika, źródło: infosec.gov.hk

Problem z klasycznym zarządzaniem tożsamością

Każda współczesna firma posiada mnóstwo różnego rodzaju oprogramowania np. do księgowości, dla programistów czy dla działu finansowego. Stosując stare podejścia sprzed czasów SSO (ang. single sign on) i zarządzania tożsamością tworzymy bardzo dużo problemów przy zatrudnieniu pracownika. Mianowicie, użytkownik zmuszony jest do zapamiętywania kilku lub kilkunastu loginów i haseł do różnych aplikacji, a administrator do zarządzania nimi z wielu różnych punktów. Stanowi to problem zarówno z perspektywy skalowalności przedsiębiorstwa jak i bezpieczeństwa. Administrator, który musi ręcznie rejestrować i derejestrować użytkowników z systemu z wielu różnych miejsc może się pomylić i jest zmuszony do manualnej, żmudnej pracy. Tymczasem jego skupienie powinno być przekierowane na metody polepszenia bezpieczeństwa czy procesów informatycznych w firmie.

Jak rozwiązać problemy zarządzania tożsamością?

Aby rozwiązać powyższe problemy postanowiono stworzyć koncepcję IDP (ang. identity provider), czyli aplikacji, która będzie odpowiadać za centralne zarządzanie tożsamością do wielu aplikacji. Oznacza to, że IDP odpowiada za uwierzytelnienie i autoryzację użytkownika, a poświadczenie tożsamości uzyskane przy logowaniu do IDP jest wykorzystywane przy zweryfikowaniu dostępu do innych aplikacji. Można więc powiedzieć, że IDP działa jako tzw. TTP (ang. trusted third party), czyli zaufana trzecia strona pomiędzy użytkownikiem, a aplikacją do której próbuje się dostać. Jest to ułatwienie zarówno z perspektywy administratora, użytkownika jak i dewelopera aplikacji, ponieważ nie musi on zarządzać hasłami ani ich przechowywać. Przykładami aplikacji IDP mogą być Google, Azure AD czy Okta.

Działanie IDP

Rysunek 2 – Działanie IDP, źródło: infosecwriteups.com

Z perspektywy użytkownika działa to więc następujący sposób:

Logowanie do aplikacji – użytkownik próbuje zalogować się do wybranej przez siebie aplikacji w ramach systemu firmowego. Ponieważ nie jest uwierzytelniony, jego żądanie jest przekierowywane do IDP.
Uwierzytelnienie w IDP – aplikacja będąca IDP uwierzytelnia użytkownika np. poprzez login i hasło czy z użyciem MFA (ang. multi-factor authentication), a także sprawdza czy ma on dostęp do aplikacji, do której chce się dostać.
Dostęp do aplikacji – IDP generuje token, jeśli uda mu się uwierzytelnić użytkownika. Następnie token może zostać przez niego wykorzystany do uzyskania dostępu do pierwotnej aplikacji do której powinien się dostać.

Powyższa koncepcja znana jest jako SSO (ang. Single Sign On). Dzięki niej, użytkownik loguje się tylko raz w systemie IDP, a uzyskany token pozwala mu na dostęp do wybranych aplikacji w ramach organizacji. Zwiększa to zarówno wygodę jak i bezpieczeństwo użytkownika.

Techniczne aspekty IDP

Przedstawiliśmy już podstawowe założenia IDP oraz SSO oraz wyjaśniliśmy dlaczego ich implementacja ułatwia pracę firmy. Aby zrozumieć techniczne aspekty musimy wprowadzić kilka dodatkowych pojęć:

Strona (ang. party) – strona uczestnicząca w procesie zarządzania tożsamością , IDP to zaufana trzecia strona (TTP). Innymi stronami mogą być aplikacja kliencka (ta do której użytkownik próbuje się dostać) czy inny zasób. Aplikacja kliencka bywa nazywana SP (ang. Service Provider).
Domena bezpieczeństwa (ang. security domain/realm) – Izolowany od innych obszar zaufania w którym zarządza się tożsamością użytkownika. Mogą to być dwie organizacje z dwoma niezależnymi IDP.
Zaufanie (ang. trust) – relacja ustanowiona pomiędzy aplikacją, a IDP pozwalająca na uwierzytelnienie w IDP i uzyskanie dostępu do aplikacji. Aplikacja ufa tokenowi, który dostarczyło IDP, więc pozwala użytkownikowi na dostęp. Zaufanie może być także ustanowione pomiędzy dwoma różnymi domenami bezpieczeństwa (federacja) np. pomiędzy dwoma firmami z różnymi systemami zarządzania tożsamością. W momencie prawnego połączenia różnych podmiotów można ustanowić zaufanie pomiędzy organizacjami dzięki temu użytkownicy z jednej z nich będą mogli korzystać z zasobów drugiej.
Federacja (ang. federation) – relacja zaufania pomiędzy dwoma lub więcej domenami bezpieczeństwa. Wymaga użycia protokołu uwierzytelnienia.
Metadane (ang. metadata) – dane o danych, w tym przypadku dotyczy to danych wymienianych w ramach ustanowienia zaufania pomiędzy organizacjami lub pomiędzy aplikacją a IDP poprzez protokół uwierzytelnienia. Są kluczowe dla procesu negocjacji i weryfikacji trust w federacji.
Poziom zaufania (ang. Level of assurance) – Miara określająca poziom zaufania co do uwierzytelnienia użytkownika. Jest to ważne szczególnie w federacjach, gdzie jedna z organizacji może według drugiej dokonywać niewystarczającego uwierzytelnienia np. tylko w oparciu o hasło bez drugiego składnika (MFA).
Żądanie (ang. claim) – informacja dostarczana przez IDP do SP w trakcie procesu uwierzytelnienia użytkownika. Żądanie zawiera dane pozwalające na identyfikację użytkownika, jego rolę oraz podpis IDP, który jest weryfikowany przez aplikację SP.
Transformacja żądania (ang. claim transformation) – proces przekształcania żądań pomiędzy systemami ze względu na różnice między zfederowanymi organizacjami (w definicji obiektów jak i ze względu na użyty protokół uwierzytelnienia).
Dzierżawca (ang. tenant) – odrębna encja (jednostka) w systemie wielodostępowym (ang. multi-tenant) np. każda osoba korzystająca z Azure Active Directory. Często osobna organizacja w zfederowanych organizacjach to osobny tenant.
Odkrywanie dzierżawcy (ang. tenant discovery) – podczas logowania do IDP aplikacja ustala do którego tenanta ma się zwrócić po uwierzytelnienie np. na podstawie domeny użytkownika. W przypadku federacji z wieloma IDP żądanie jest kierowane do IDP w osobnej organizacji.
Provisioning – Proces tworzenia pewnych zasobów w ramach infrastruktury. W przypadku zarządzania tożsamością pada w znaczeniu, tworzenia i kasowania (deprovisioningu) kont użytkownika. Provisioning jest często związany z innymi systemami do zarządzania kontami takimi jak SailPoint czy nawet z systemami do których dostęp mają działy zatrudniające ludzi.
Protokół uwierzytelnienia (ang. authentication protocol) – protokół stosowany między aplikacją a IDP lub między dwoma IDP do zbudowania zaufania. Może to być np. SAML czy OIDC z OAuth.

Rysunek 3 – Relacja 'trust’ pomiędzy dwoma organizacjami w ramach dwóch security realms, źródło: microsoft.com

Przykład

Ponieważ same definicje są trudne do przyswojenia wyobraźmy sobie przykład. Załóżmy, że istnieje firmaA i firmaB, które obie mają swoich IDP i osobne organizacje, które pod wpływem wykupienia jednej firmy przez drugą połączyły się. Między organizacjami (domenami bezpieczeństwa), a właściwie ich IDP został skonfigurowany ‘Trust’ na odpowiednim poziomie zaufania. Scenariusz logowania użytkownika do Microsoft 365 należącego do firmy A przez użytkownika z firmy B mógłby wyglądać następująco:

Użytkownik inicjuje logowanie – Użytkownik z firmy B (np. użytkownik@firmaB.pl) otwiera aplikację Microsoft 365, której właścicielem jest firma A, i próbuje się zalogować. Na ekranie logowania wprowadza swój adres e-mail.
Tenant discovery – Microsoft IDP, obsługujący aplikację Microsoft 365, analizuje podaną domenę (firmaB.pl). Na tej podstawie ustala, że użytkownik należy do dzierżawcy FirmaB. Jednak FirmaB nie jest bezpośrednim dostawcą tożsamości dla tej aplikacji – zamiast tego istnieje federacja z FirmaA, która zarządza dostępem do Microsoft 365.
Przekierowanie żądania – Microsoft IDP kieruje żądanie uwierzytelnienia do IDP FirmaA, z którym ma skonfigurowaną relację zaufania. IDP FirmaA wie, że użytkownik użytkownik@firmaB.pl pochodzi z firmy B, dlatego korzysta z federacyjnego zaufania, aby zweryfikować dane użytkownika za pośrednictwem IDP FirmaB.
Uwierzytelnienie w FirmaB – IDP FirmaB weryfikuje tożsamość użytkownika (np. na podstawie loginu i hasła oraz uwierzytelniania wieloskładnikowego, jeśli jest wymagane). Po pomyślnym uwierzytelnieniu IDP FirmaB generuje token zawierający claimy, takie jak: email: użytkownik@firmaB.pl. role: Employee. organization: FirmaB.
Transformacja claimów w Firma – Token z FirmaB jest przesyłany do IDP FirmaA, który przeprowadza transformację claimów. Na przykład: Claim email może być przekształcony w userPrincipalName, ponieważ taki format oczekuje Microsoft IDP. Claim role może zostać przemapowany na rolę zrozumiałą dla systemów firmy A, np. User. Można dodać claim tenantId, który jednoznacznie wskazuje FirmaB jako dzierżawcę.
Przekazanie claimów do Microsoft IDP – IDP FirmaA generuje nowy token zawierający odpowiednie claimy i podpisuje go cyfrowo. Token ten zostaje przesłany do Microsoft IDP, który weryfikuje podpis oraz zgodność claimów z wymaganiami aplikacji Microsoft 365.
Dostęp do aplikacji – Microsoft IDP akceptuje token, a aplikacja Microsoft 365 na podstawie zawartych w nim claimów loguje użytkownika i nadaje mu odpowiednie uprawnienia (np. jako pracownika z firmy B).

Podsumowanie

Mamy nadzieję, że udało nam się przybliżyć Wam techniczne aspekty zarządzania tożsamością. Jeśli jesteście ciekawi, to zachęcamy do zajrzenia do źródeł, a także do czytania kolejnych artykułów, gdzie pokażemy jak działa OIDC oraz SAML.