Zarządzanie tożsamością w chmurze i standardy SAML, OpenID, OAuth

W nowym odcinku z cyklu “Jak bezpiecznie przenieść się do chmury” omówimy model Federated Identity czyli po staropolsku federacyjnego zarządzania tożsamością oraz porównamy najczęściej wykorzystywane standardy.

Artykuł jest częścią zaplanowanego na cały rok cyklu artykułów oraz webinarów sponsorowanych przez firmę Aruba Cloud – dostawcę usług chmurowych z centrum przetwarzania w Polsce.

W poprzednich artykułach i webinarze opisałem:

• architekturę modelu cloud computingu wg NIST SP 800-145,
• ryzyka natury organizacyjno-prawnej i zarządzania zgodnością na przykładzie pojęcia GRC – Governance, Risk management and Compliance,
• standardy bezpieczeństwa jakie powinna spełniać usługa chmurowa i jak możemy sprawdzić, czy te standardy faktycznie spełnia.

W tym odcinku przedstawię jakie rozwiązania są wykorzystywane do zarządzania tożsamością w modelu chmury.

Zapraszamy na webinar

Skoro tu zajrzeliście, to zapraszamy na nasz webinar poświęcony kwestiom RODO/GDPR w chmurze. Już teraz możecie zapisać się na termin 23 kwietnia o godzinie 20 lub 24 kwietnia o godzinie 12 – staramy się dopasować do Waszych potrzeb. W obu terminach poruszane będą te same tematy – choć Wasze pytania mogą się różnić.

W programie między innymi omówienie kwestii zapewnienia zgodności z RODO w różnych rodzajach usług w chmurze oraz problemy związane z komunikacją i współpracą z dostawcą usług chmurowych.

Zarządzanie tożsamością w chmurze oraz porównanie standardów

Zarządzanie tożsamością nawet w wewnętrznej sieci LAN może być koszmarem. W przypadku korzystania z usług chmurowych wielu dostawców, zapamiętanie wszystkich danych potrzebnych do logowania może stać się koszmarem do kwadratu. W celu ułatwienia zarządzania tożsamością w wielu rozproszonych systemach informatycznych powstał model nazwany Federated Identity wykorzystujący wielu otwartych standardów i frameworków. Zanim omówimy go bardziej szczegółowo trzeba przedstawić kilka podstawowych definicji i pojęć.

Autoryzacja vs uwierzytelnienie

Uwierzytelnienie (z ang. authentication) jest procesem, w którym system weryfikuje tożsamość (identity) podmiotu, który próbuje uzyskać dostęp do zasobów. W uproszczeniu składa się z 4 podstawowych kroków:

1. Podmiot się przedstawia (np. nazwa użytkownika)
2. System prosi o potwierdzenie tożsamości
3. Podmiot potwierdza swoją tożsamość (np. hasło, klucz, token)
4. System weryfikuje zgodność przesłanego potwierdzenia tożsamości.

Autoryzacja (z ang. authorization) jest procesem, w którym podmiotowi nadawane są uprawnienia do realizacji operacji na zasobie np. odczyt, zapis, modyfikacja czy usunięcie danych.

Federated identity (FIM) vs Single Sign On (SSO)

Single Sign On polega na wykorzystaniu tych samych danych uwierzytelniających (np. nazwa użytkownika, hasło, klucz, token itd.) do uzyskania dostępu do różnych usług w ramach jednej organizacji, domeny, sieci np. do systemu kadrowego, intranetu, bazy wiedzy itp. Najczęściej stosowanym rozwiązaniem jest centralizacja serwera dostępowego przy wykorzystaniu mechanizmów jak LDAP czy Kerberos. Użytkownik jest potwierdzany przez ticket zawierający informacje dotyczące tożsamości i przynależności do grup.

Federated Identity Management – model, w którym podmiot może korzystać z wielu usług dostarczanych przez różnych dostawców przy użyciu tych samych danych uwierzytelniających. W tym podejściu tożsamość podmiotu jest potwierdzana przez zaufaną stronę (Identity provider), która może być wewnętrzna jak i zewnętrzna.

Uproszczony model Federated Identity Management

1. Użytkownik Marcin chce uzyskać dostęp do serwisu (np. Pinterest). Użytkownik może się zalogować używając danych z zaufanego serwisu pełniącego rolę Identity Provider (IdP) np. Facebook lub Google.

   

2. Użytkownik Marcin wybiera logowanie przy użyciu danych Google. Service Provider (SP) generuje żądanie potwierdzenia tożsamości do Identity Provider (IdP).
3. Usługa przekierowuje użytkownika do IdP, w tym przypadku do serwisu Google.

   

4. IdP uwierzytelnia użytkownika (na podstawie wprowadzonych danych uwierzytelniających lub session cookies).
5. IdP wysyła poświadczenie tożsamości do przeglądarki użytkownika, które jest przekierowane do usługi.
6. SP (Pinterest) weryfikuje potwierdzenie tożsamości.
7. Użytkownik Marcin uzyskuje dostęp do serwisu.

Tak w uproszczonym schemacie działa model Federated Identity Management. Jego głównymi założeniami jest brak dostępu zewnętrznych aplikacji do danych uwierzytelniających użytkownika, możliwość wykorzystania jednego serwera autoryzującego do chronienia wielu różnych zasobów, ograniczenie ilości kont w różnych aplikacjach poprzez wykorzystanie jednego serwera autoryzacji. Wykorzystuje on SSO znosząc jednocześnie jego ograniczenia dotyczące działanie w obrębie jednej sieci czy domeny poprzez dodanie zewnętrznej, zaufanej strony potwierdzającej tożsamość. Dzięki temu podejściu jest powszechnie stosowany przez firmy przy korzystaniu z usług chmurowych wielu dostawców. Przyjrzyjmy się najczęściej wykorzystywanym standardom i frameworkom (w jaki sposób i w jakim celu działają) oraz związanymi z nimi aspektom bezpieczeństwa.

SAML – Security Assertion Markup Language

Specyfikacja Security Assertion Markup Language (SAML) została opracowana przez OASIS Security Services Technical Committee dla realizacji uwierzytelnienia i przekazywania tożsamości oraz atrybutów tożsamości pomiędzy systemami komputerowymi.

Jego obecna wersja SAML 2.0 jest kombinacją trzech standardów: SAML 1.1, ID-FF (Identity Federation Framework) 1.2, and Shibboleth. SAML jest otwartym standardem opartym o XML umożliwiającym wymianę danych potrzebnych do uwierzytelnienia i autoryzacji w sposób bardzo elastyczny, z wykorzystaniem standardowych metod technologii webowych (m.in. GET, POST). Partnerzy mogą wybrać dowolne atrybuty w komunikatach potwierdzającym tożsamość (assertion payload), które są obsługiwane przez XML. To sprawia, ze standard oznacza się pełną interoperacyjnością czyli jest wolny od ograniczeń architektury czy rozwiązań dostawców. Specyfikacja została zaimplementowana w wielu znanych i dostępnych bibliotekach, w większości udostępnionych na bazie licencji otwartej:

• OpenSAML – biblioteka dla języków C++ i Java – dostępna na licencji otwartej i dystrybuowana wraz z oprogramowaniem Apache 2.0,
• OpenSSO – rozwiązanie J2EE dla aplikacji i serwerów Web,
• PingFederate,
• Sun Federated Access Manager,
• Symlabs Federated Identity Suite realizuje wsparcie dla wielu rozwiązań, realizuje wszystkie profile SAML 2.0,
• ZXID.org Identity Management – implementuje SAML 2.0. w C, umożliwia wykorzystanie mechanizmów PHP, Perl i Java,
• Shibboleth – biblioteka dla języków Java I C++ – dostępna na licencji otwartej.

Zasada działania jest bardzo podobna do przedstawionego powyżej uproszczonego schematu FIM.

1. Użytkownik chce uzyskać dostęp do serwisu.
2. Service Provider (SP) weryfikuje czy Użytkownik posiada token SAML.
3. Usługa przekierowuje użytkownika do IdP.
4. IdP przesyła formularz logowania (opcjonalnie, jeśli nie ma sesji).
5. Użytkownik uwierzytelnia się (opcjonalnie, jeśli nie ma sesji).
6. IdP uwierzytelnia użytkownika i tworzy token SAML.
7. IdP wysyła token SAML i użytkownik jest przekierowany do SP.
8. SP weryfikuje token SAML.
9. Użytkownik uzyskuje dostęp do serwisu.

Podstawowe wymagania w celu zabezpieczenia przepływu:

• Stosowanie TLS 1.2 jest mocno rekomendowane w celu zapewnienia poufności i integralności komunikatów,
• Wartość atrybutu powinna być weryfikowana przez IdP,
• Zaimplementowane odpowiednie procesy i mechanizmy zarządzania kluczami i weryfikacji podpisów zarówno u SP jak IdP,\
• SP powinien zaimplementować mechanizm zapobiegający SAMLResponse relay,
• Następujące elementy danych powinny być wymagane:
  • AuthnRequest(ID, SP) musi zawierać ID (unikalny identyfikator żądania) i SP (identyfikator dostawcy usługi inicjującego żądanie). Ponadto identyfikator żądania powinien być zwrócony w odpowiedzi (InResponseTo=””). InResponseTo pomaga zagwarantować autentyczność odpowiedzi od zaufanego IdP.
  • Response (ID, SP, IdP, {AA} K -1/IdP) musi zawierać ID (unikalny identyfikator żądania), SP (identyfikator dostawcy usługi będący odbiorcą odpowiedzi), IdP (Identyfikator serwera autoryzującego odpowiedź), {AA} K -1/IdP (asercja podpisana cyfrowo kluczem prywatnym IdP ).
  • AuthAssert(ID, C, IdP, SP); Asercja uwierzytelnienia musi występować w odpowiedzi i zawierać ID, C (client) , IdP i SP.

Oauth 2.0

Oauth jest standardem opracowanym przez IETF w celu autoryzacji, a w szczególności delegacji autoryzacji do zasobów za pomocą przekazywania access tokenu. Obecnie występuje w wersji 2.0, która nie jest kompatybilna z wersją 1.0. Najczęściej spotykany scenariusz pozyskania tokena to metoda Authorization Code Flow zakładająca udział kilku stron: użytkownik, klient, serwer autoryzacyjny, właściciel zasobu oraz serwer zasobu.

1. Użytkownik chce uzyskać dostęp do danych z Serwera zasobu (Resource server).
2. Klient przekierowuje użytkownika serwera autoryzacyjnego (IdP) udzielającego w imieniu właściciela zasobu poświadczenia, na podstawie którego klient może uzyskać dostęp do chronionych danych na serwerze zasobu (Resource Server).
3. IdP przesyła formularz logowania i/lub tzw. consent screen (opcjonalnie, jeśli nie ma sesji). Formularz Consent screen pokazuje właścicielowi chronionego zasobu jakie informacje i uprawnienia chce uzyskać klient (RP).
4. Użytkownik uwierzytelnia się i potwierdza delegowanie uprawnień (opcjonalnie, jeśli nie ma sesji).
5. IdP dokonuje weryfikacji i przekierowuje do klienta z przesłanym kodem autoryzacyjnym.
6. Klient prezentuje otrzymany kod autoryzacyjny.
7. Serwer autoryzacyjny zwraca access token do klienta.
8. Wysyłane jest zgłoszenie dostępu do danych z access tokenem.
9. Udzielony jest dostęp klientowi do chronionego zasobu.
10. Użytkownik uzyskuje dostęp do chronionych danych.

Podstawowe wymagania w celu zabezpieczenia przepływu:

• Podstawowym założeniem Oauth jest brak dostępu zewnętrznych aplikacji do danych uwierzytelniających użytkowników. Proces pozyskiwania tokenu rozpoczyna się od zarejestrowania klienta w serwerze autoryzacyjnym. Polega on na podaniu identyfikatora klienta (ang. client id), adresu zwrotnego (ang. redirect URL) oraz wygenerowaniu tzw. sekretu (ang. client secret). Sekret otrzymany w procesie rejestracji aplikacji musi być niedostępny dla użytkownika. Udostępniony publicznie spowoduje, że dowolna osoba może podszywać się pod naszą aplikację.
• Access tokeny powinny zawsze być przesyłane za pomocą TLS.
• Krok 2 musi obejmować parametr stanu (state) powiązany z sesją końcowego użytkownika by zapobiegać atakom typu CSRF (Cross-site request forgery). Wartość parametru powinna być weryfikowana w kroku 5.
• IdP musi realizować weryfikację redirect_url_validation, żeby zapewnić, że URL w żądaniu pasuje do zarejestrowanych URL dla aplikacji.
• Zgoda właściciela zasobu powinna być wymagana na cały zakres żądanego dostępu w kroku 3.

OpenID Connect

OpenID Connect jest zestawem specyfikacji tworzących framework, umożliwiający żądanie i odbiór informacji o tożsamości i sesjach dla klientów wszystkich typów włączając przeglądarki, urządzenia mobilne, javascripts. Opiera się na elementach Oauth 2.0 dodając mechanizm id token umożliwiający proces uwierzytelnienia.

Wykorzystuje semantykę Restful i JSON. Umożliwia wsparcie szyfrowania danych o tożsamości i zarządzanie sesjami. OpenId Connect Clients wykorzystują zakres wartości zdefiniowanych jak we frameworku OAuth 2.0 do określenia jakie uprawnienia są żądane.

1. Użytkownik chce uzyskać dostęp do danych z Serwera zasobu (Resource server).
2. Relying Party (RP), przekierowuje użytkownika do IdP (zwanego też Open Provider), serwera autoryzacyjnego udzielającego w imieniu właściciela zasobu poświadczenia, na podstawie którego klient (RP) może uzyskać dostęp do chronionych danych na serwerze zasobu (Resource Server).
3. IdP przesyła formularz logowania i/lub tzw. consent screen (opcjonalnie, jeśli nie ma sesji). Formularz Consent screen pokazuje właścicielowi chronionego zasobu jakie informacje i uprawnienia chce uzyskać klient (RP).
4. Użytkownik uwierzytelnia się i potwierdza delegowanie uprawnień (opcjonalnie, jeśli nie ma sesji).
5. IdP przekierowuje do RP zapytanie z kodem autoryzacyjnym.
6. RP wysyła zapytanie o access token wraz z kodem autoryzacyjnym oraz identyfikatorem i sekretem identyfikującym klienta.
7. Kod autoryzacyjny jest zamieniony na access token i id token podpisany przez JWT (JSON Web Token z wykorzystaniem algorytmu HMAC lub pary kluczy RSA ) i wysyłany do klienta.
8. Wysyłane jest zgłoszenie dostępu do danych z access tokenem.
9. Idp wysyła odpowiedź o pomyślnej weryfikacji tożsamości klienta oraz wartości kodu autoryzacyjnego.
10. Udzielony jest dostęp do chronionego zasobu.
11. Chronione dane są przesyłane do RP.
12. Użytkownik uzyskuje dostęp do chronionych danych.

Podstawowe wymagania w celu zabezpieczenia przepływu:

OpenID Connect jest zbudowany w oparciu o Oauth i z tego powodu „dziedziczy” zagrożenia z nim związane przed, którymi możemy się zabezpieczyć stosując te same mechanizmy.

• Krok 2 musi obejmować parametr stanu (state) powiązany z sesją końcowego użytkownika by zapobiegać atakom typu CSRF (Cross-site request forgery). Wartość parametru powinna być weryfikowana w kroku 5.
• IdP musi realizować weryfikację redirect_url_validation, żeby zapewnić, że URL w żądaniu pasuje do zarejestrowanych URL dla aplikacji.
• Access tokeny powinny zawsze być przesyłane za pomocą TLS.
• Zgoda właściciela zasobu powinna być wymagana na cały zakres żądanego dostępu w kroku 3.

Podsumowanie

• SAML i OpenID Connect wykorzystują podpisane tokeny, które wspierają szyfrowanie.
• SAML jest oparty o XML, więc związany jest ze wszystkimi zagrożeniami typowymi dla XML.
• Oauth nie służy do uwierzytelnienia, jest zaprojektowany w celu delegowania autoryzacji.
• OpenID Connect dostarcza warstwę uwierzytelnienia dla Oauth.
• OpenID Connect jest oparty o JSON i elementy Oauth 2.0 I jest związany ze wszystkimi zagrożeniami typowymi dla OAuth 2.0.

Dla zachowania pełnej przejrzystości: za opublikowanie tego artykułu pobieramy wynagrodzenie.