Mechanizmy uwierzytelniania i SSO dostępne na platformie Red Hat OpenShift

OpenShift RedHatSSO External

Platformy PaaS zdobywają coraz większą popularność. Jednym z głównych pól ich wykorzystania staje się dostarczanie skalowalnych rozwiązań wykorzystywanych przez zespoły deweloperskie w procesie ciągłego dostarczania i integracji oprogramowania. Jednym z wyróżniających się na rynku platform tego typu jest otwarta platforma RedHat OpenShift Container Platform. W porównaniu do konkurencyjnych rozwiązań wyróżnia ją dostarczanie szeregu zintegrowanych rozwiązań lub opcjonalnych komponentów, które mogę mieć zasadniczy wpływ na uproszczenie procesu wdrażania i adaptacji platformy w ramach przedsiębiorstwa. Wśród nich wyróżniają się mechanizmy związane z uwierzytelnianiem.

Rozważając sposoby, w jakie możemy wykorzystywać platformę, należy wyróżnić dwa osobne scenariusze, w ramach których chcielibyśmy skorzystać ze zintegrowanych rozwiązań logowania. Pierwszy scenariusz to zapewnienie zintegrowanego logowania do samej platformy oraz utrzymywanych na niej usług dla osób zaangażowanych w proces szeroko pojętego tworzenia i dostarczania oprogramowania. De facto ten pierwszy scenariusz dotyczył będzie naszych pracowników lub bezpośrednich współpracowników. Drugi scenariusz to dostarczanie zintegrowanego uwierzytelniania dla podmiotów trzecich w tym użytkowników końcowych tworzonych i wdrażanych w środowiskach produkcyjnych platformy OpenShift aplikacji. Przy pierwszym scenariuszu możemy wykorzystać podstawowy system uwierzytelniania platformy OpenShift. Przy drugim powinniśmy w ramach platformy dostarczyć osobne rozwiązanie autoryzacyjne. Oba scenariusze opiszę osobno.

Zintegrowanie logowanie w ramach platformy OpenShift

Praca na platformie dla naszych współpracowników polegać będzie na wykorzystaniu samej platformy oraz dostarczanych przez nią narzędzi takich jak: systemy ciągłej integracji i dostarczania np.: Jenkins, systemów kontroli wersji np.: Gitlab czy też systemów zarządzania projektem, śledzenia błędów np.: Jira czy Redmine i innych, jakie uznamy za stosowne.

Zapewnienie zintegrowanego logowania na platformie staje się niezwykle proste dzięki wbudowanemu systemowi uwierzytelniania opartemu o serwer zgodny z Protokołem OAuth 2.0, który może stanowić dostawcę tożsamości dla samej platformy i pracujących na niej usług, a jednocześnie przeprowadzać procedurę uwierzytelnienia w oparciu o zewnętrznego dostawcę tożsamości.

OpenShift OAUTH Internal

System uwierzytelniania OAuth platformy OpenShift w wersji 3.9 zapewnia:

  • dostarczanie Tokenów zapewniających użytkownikom dostęp do API platformy, co ułatwia zaawansowaną obsługę mechanizmów nadawania uprawnień w ramach platformy;
  • obsługę przepływów authorization code grant oraz implicit grant specyfikacji OAuth 2.0, co umożliwia integrację z klienckimi systemami uwierzytelniania, posiadającymi implementację co najmniej jednego z tych przepływów;
  • udostępnienie informacji na temat własnej konfiguracji poprzez punkt końcowy o adresie: adres_serwera_master_api:port/.well-known/oauth-authorization-server – to umożliwia obsługę funkcji wykrywania i autorejestracji usług;
  • możliwość pełnej integracji lub odseparowania mechanizmów logowania przy użyciu interfejsów CLI i konsoli WEB – pozwala to np.: zapewnić osobny mechanizm dostawcy tożsamości dla administratorów pracujących z CLI platformy i deweloperów wykorzystujących interfejs WWW;
  • konfigurację co najmniej jednego lub wielu dostawców tożsamości;
  • rozdzielenie encji użytkownika i jego tożsamości – jeden użytkownik może się logować do platformy i jego usług na wiele sposobów, czyli może posiadać wiele tożsamości – zapewnia to rozdzielenie mechanizmów dostępu od uprawnień, które nadajemy użytkownikowi.

Platforma w wersji 3.9 pozwala na konfigurację dostawców tożsamości w oparciu o:

  • htpasswd – plik użytkownik – zaszyfrowane hasło – mechanizm podstawowy przeznaczony dla środowisk testowych;
  • usługę KeyStone pozwalający na łatwą integrację z platformą IaaS OpenStack;
  • dowolną bazę LDAP;
  • Basic Authentication z wymuszeniem stosowania HTTPS;
  • nagłówki żądania pozwalające “schować ” OpenShifta za dowolnym ustawiającym nagłówki żądania HTTP systemem autoryzacji (typowym przykładem mogą być tu różne systemy mod_auth stanowiące moduły serwera Apache);
  • OpenID Connect ze wsparciem przepływu Authorization Code Flow;
  • Gitlab OAuth – przy czym dostawcą może tu być zarówno publicznie dostępny system Gitlab.com jak i “nasza” lokalna instalacja systemu Gitlab;
  • Github OAuth z ograniczeniem jedynie do obsługi logowania dla konsoli WEB;
  • Google OpenID Connect z ograniczeniem jedynie do obsługi logowania dla konsoli WEB.

Jak widać lista możliwości jest całkiem spora, a każda nowa wersja wprowadza nowe funkcje i możliwości. Należy się spodziewać, że obecna lista funkcji nie jest ostatnim słowem programistów platformy.

Konfiguracja mechanizmów uwierzytelniania na platformie OpenShift

Konfigurację mechanizmów uwierzytelniania platformy można przeprowadzić na etapie instalacji systemu poprzez dodanie do pliku ansible inventory w sekcji [OSEv3:vars] wpisu openshift_master_identity_providers=[{definicja dostawców tożsamości}] przy czym {definicja dostawców tożsamości} musi przyjąć postać parametrów konfiguracyjnych jednego bądź wielu dostawców tożsamości zapisanych w formacie JSON. Redefinicję można też przeprowadzić po zainstalowaniu platformy poprzez dodanie odpowiednich wpisów w pliku konfiguracyjnym /etc/origin/master/master-config.yaml.

Definiując dostawcę tożsamości, administrator platformy musi określić 4 podstawowe parametry tożsame dla każdego dostawcy oraz dodatkowe parametry typowe dla danego dostawcy.

Podstawowe parametry to:

  • name – określający nazwę dostawcy (UWAGA! nazwa wpływa na konstrukcję URL dla punktów końcowych wywołań zwrotnych (ang. callback) OAUTH 2.0 platformy, dlatego odradzam stosowanie w tym miejscu skomplikowanych wpisów);
  • challenge – określający czy dany dostawca będzie wykorzystywany do logowania poprzez CLI;
  • login – określający czy dany dostawca będzie obsługiwał logowanie przez panel WWW mappingMethod – metodę mapowania tożsamości do konta użytkownika – warunkującą czy w ramach danego konta użytkownika będzie można skonfigurować wiele tożsamości, czyli zapewnić wiele mechanizmów logowania.

Sam parametr mappingMethod może przyjmować wartości:

  • claim (wartość domyślna) – tworzy użytkownika z podaną nazwą, jeśli taki użytkownik posiada już inną tożsamość, zgłasza błąd – uniemożliwia wiele mechanizmów logowania;
  • lookup – wyszukuje istniejącego użytkownika (wymaga “ręcznego” zarządzania użytkownikami przez administratora);
  • generate – generuje nazwę nowego użytkownika, jeśli podana nazwa już istnieje – zapewnia rozdzielenie kont użytkownika w przypadku znalezienia duplikatu konta podczas pierwszego logowania, tym samym uniemożliwia wiele mechanizmów logowania;
  • add – dodaje istniejącemu użytkownikowi nową tożsamość, zapewniając dla danego konta możliwość obsługi wiele mechanizmów logowania.

Przykładowa definicja mechanizmów uwierzytelniania podawanych podczas instalacji platformy może wyglądać następująco:

openshift_master_identity_providers=[{"name": "Htpasswd Basic Auth",
"mappingMethod" : "add", "login": "false", "challenge": "true", "kind":
"HTPasswdPasswordIdentityProvider", "filename":
"/etc/openshift.realm/auth.basic.realm"},{"name": "google", "mappingMethod" :
"add", "challenge": "false","login": "false", "kind": "GoogleIdentityProvider", "clientID":
"my_secret_client_id", "clientSecret" : "my_super_secret_secret_value",
"hostedDomain": "linuxpolska.pl"}]

Jak widać, definicja ta wprowadza dwóch dostawców tożsamości:

  • Htpasswd Basic Auth zapewniającego logowanie jedynie poprzez CLI w oparciu o tożsamości zdefiniowane w lokalnym pliku /etc/openshift.realm/auth.basic.realm;
  • google zapewniającego logowanie jedynie przez WWW z wykorzystaniem Google OpenID Connect z ograniczeniem logowania jedynie dla użytkowników domeny linuxpolska.pl.

Należy zaznaczyć, że w tej przykładowej konfiguracji następuje separacja metod dostępu do CLI i konsoli WWW, choć określenie dla obu dostawców parametru „mappingMethod” : „add” nie wyklucza sytuacji, w której jeden użytkownik będzie się logował do platformy na dwa sposoby.

Powyższa konfiguracja wymagałaby oczywiście zarejestrowania naszej platformy OpenShift w API Google OpenID Connect, gdzie w wyniku procesu rejestracji otrzymalibyśmy wartości parametrów clientID oraz clientSecret. Przeprowadzając proces rejestracji z naszej strony, musielibyśmy podać adres wywołania zwrotnego naszej platformy, który przyjąłby postać zgodną ze wzorcem: master_api_server:port/oauth2callback/google – ostatni element “google” jest tożsamy z nazwą, jaką podajemy, definiując dostawcę tożsamości. Rejestracji można dokonać pod tym adresem. Przykładowy formularz rejestracji widoczny jest poniżej.

OpenShift OAUTH Google Registration

Więcej na temat konfiguracji pozostałych dostawców tożsamości na platformie OpenShift możecie dowiedzieć się z oficjalnej dokumentacji platformy.

Wiedząc jak skonfigurować dostawców tożsamości, możemy przejść do integracji naszych aplikacji i usług z systemem uwierzytelniania platformy.

Integracja aplikacji i usług z systemem uwierzytelniania platformy Red Hat OpenShift

Zgodnie z informacją, jaką podałem powyżej integracja będzie możliwa dla tych aplikacji, które zapewniają klienta protokołu OAuth 2.0 z obsługą przepływów authorization code grant lub implicit grant.

Zintegrowanie aplikacji jest możliwe na dwa sposoby:

  • poprzez wykorzystanie konta serwisowego jako klienta OAuth – tego typu definicja powinna zapewniać możliwość integracji aplikacji uruchamianej w ramach platformy OpenShift;
  • poprzez definicję klienta OAuth po stronie platformy – stosując tę metodę, możemy autoryzować nie tylko aplikacje uruchamiane wewnątrz RedHat OpenShift, ale także te zainstalowane poza naszym systemem PaaS.

W przypadku pierwszej metody należy pamiętać, aby po stronie zespalanej aplikacji konfiguracja zawierała informacje dotyczące:

  • identyfikatora klienta (and. ClientID, może być różnie nazywany w zależności od implementacji klienta OAuth) zbieżnej ze wzorcem: system:serviceaccount:<nazwa_przestrzeni(projektu)>:;
  • hasła dostępu klienta (ang. ClientSecret tutaj podobnie w zależności od implementacji klienta nazwa może się różnić) musi być dowolnym Tokenem API, jaki możemy uzyskać wydając polecenie: oc sa get-token ;
  • Parametr URI przekierowania (ang. RedirectURI podobnie jak powyżej nazwa w zależności od implementacji klienta może być różna) po stronie aplikacji klienckiej musi odpowiadać adnotacji w koncie serwisowym przyjmującym wzorzec: serviceaccounts.openshift.io/oauth-redirecturi.nazwa: adres url lub definicja przekierowania wskazującą na route do aplikacji.

Jeśli zdecydujemy się na drugą metodę integracji, musimy przygotować definicję klienta OAuth w postaci zgodnej z poniższym wzorcem w formacie yaml:

kind: OAuthClient
apiVersion: oauth.openshift.io/v1
metadata:
 name: nazwa-aplikacji
secret: "supertajnehaslodostepudomojejaplikacjiviaOAUTH"
redirectURIs:
 - "http://adres_wywołania_zwrotengo_klienta_oauth_naszej_aplikacji"
grantMethod: prompt

Oczywiście możliwy jest też zapis powyższych parametrów w formacie json.

Importu tak przygotowanej definicji możemy dokonać, wydając na platformie OpenShift polecenie:

oc create -f nazwa_pliku.yaml

Jak widać w powyższej definicji, sami określamy tutaj nazwę: parametr name (stanowiący identyfikator klienta) oraz hasło klienta parametr: secret, które będziemy musieli wprowadzić w konfiguracji klienta OAuth po stronie naszej aplikacji. Parametr redirectURIs zależny jest bezpośrednio od konfiguracji naszej aplikacji, – informacje na temat jego odpowiedniej wartości znajdziemy na pewno w dokumentacji wdrażanego systemu.

Ostatnim elementem, jaki należy wymienić, są wywołania dla punktów końcowych, jakie zwykle należy określić, konfigurując uwierzytelnienie w aplikacji klienckiej OAUTH:

  • master_api_serwer_adres:port/oauth/authorize – punkt końcowy (ang. end point) autoryzacji;
  • master_api_serwer_adres:port/oauth/token – punkt końćowy (ang. end point) tokenu;
  • master_api_serwer_adres:port/oapi/v1/users/~ – punkt końcowy (ang. end point) zwracający informacje na temat danego użytkownika.

Omawiając tę kwestię, warto wspomnieć o fakcie, że dostępne w ramach platformy RedHat OpenShift narzędzia mogą posiadać wbudowaną integrację z systemem OAuth OpenShift. Typowym przykładem są tutaj wzorce instalacji systemu ciągłego dostarczania i integracji Jenkins. Decydując się na instalację systemu w ramach platformy OpenShift, możemy określić dodatkowy parametr ENABLE_OAUTH, który jeśli zostanie ustawiony na wartość true, zapewni nam widok okna logowania do systemu w postaci pokazanej na poniższym obrazku.

OpenShift Jenkinks OAUTH

Jak widać powyżej, system Jenkins zostanie dla nas automatycznie zintegrowany z uwierzytelnianiem platformy RedHat OpenShift. Dzieje się tak w dzięki temu, że wzorzec instalacji aplikacji Jenkins dostarczany wraz z platformą, instaluje w kontenerze systemu Jenkins wtyczkę autoryzacyjną, której kod możemy przeanalizować tutaj, dodatkowo tworzy także na platformie w naszym projekcie specjalnie konto serwisowe zapewniające autoryzację klienta OAUTH platformy Jenkins. Samo konto możemy łatwo sprawdzić, wydając w naszym projekcie polecenie:

oc describe sa jenkins

Zapewni to wyświetlenie informacji zgodnych z poniższymi wpisami:

Name:                 jenkins
Namespace:            jenkins
Labels:               app=jenkins-persistent
                      template=jenkins-persistent-template
Annotations:        
serviceaccounts.openshift.io/oauth-redirectreference.jenkins={"kind":"OAuthRedirectReference","apiVersion":"v1","reference":{"kind":"Route","name":"jenkins"}}
Image pull secrets:   jenkins-dockercfg-ntjjn
Mountable secrets:    jenkins-token-csm58
                      jenkins-dockercfg-ntjjn
Tokens:               jenkins-token-csm58
                      jenkins-token-mdmcp

Analizując wyświetlone informacje, należy zwrócić uwagę na parametr Annotations, w którym określono uri przekierowania zgodne ze wzorcem, jaki opisałem powyżej, który wskazuje na zewnętrzny route to serwisu aplikacji Jenkins.

Jak widać, możliwości uwierzytelniania aplikacji w oparciu o system OpenShift są naprawdę nie małe, nie oznacza to jednak, że nie posiadają one pewnych ograniczeń. Większość z tych ograniczeń wynika tak naprawdę z pewnych ograniczeń specyfikacji OAuth 2.0. Protokół ten w swoich zasadniczych założeniach definiuje jedynie mechanizmy przekazywania tokenów autoryzacyjnych. Co zrobić, jeśli np. aplikacja wymaga pobierania rozszerzonych informacji dotyczących podmiotu logowania czy też nasz dział bezpieczeństwa oczekuje funkcjonalności automatycznego wylogowywania ze wszystkich modułów, czy aplikacji, do których zalogował się nasz użytkownik/deweloper. Okazuje się, że RedHat OpenShift Container Platform dostarcza gotowe rozwiązanie. Są nim przygotowane na platformie wzorce instalacji systemu RedHat SSO.

System RedHat SSO w ramach platformy OpenShift

Wdrożenie systemu w ramach platformy nie stanowi problemu. W zasadzie wszystko, co musi zrobić administrator to wybrać odpowiedni wzorzec instalacji, decydując się na docelowy system RDBMS, wypełnić podstawowe informacje dotyczące pożądanej adresacji, certyfikatów, kluczy dostępu oraz kont administracyjnych i po kilku minutach nasza platforma wyposażona jest w pełnoprawne rozwiązanie autoryzacyjne, o ogromnych możliwościach. Zanim przejdziemy do opisu tych możliwości, warto nadmienić, że posiadając subskrypcję RedHat OpenShift Container Platform, nasz system RedHat SSO może uwierzytelniać nie tylko dowolny system czy aplikację pracującą w ramach naszej platformy PaaS, ale także dowolny system zainstalowany poza naszą platformą.

OpenShift RedHatSSO External

Odpowiedzmy teraz na pytanie, czym jest system RedHat SSO.

RedHat SSO to system:

  • oparty na systemie KeyCloak stworzonym jako projekt JBOSS Comunity – który stanowi jeden z najaktywniejszych projektów tej społeczności;
  • implementujący dwa najbardziej uznane standardy w zakresie obsługi SSO:
    • OpenID Connect,
    • SAML 2.0;
  • dostępny z szerokim zakresem bibliotek klienckich (adaptery m.in. do technologii RedHat JBOSS) co znacząco ułatwia i przyśpiesza proces integracji systemu z aplikacjami klienckimi;
  • będącym zintegrowanym rozwiązaniem, którego zarządzanie odbywa się poprzez intuicyjny interfejs WWW, a skalowanie w tym dynamiczne możliwe jest w oparciu o funkcje wbudowane w naszą platformę PaaS;
  • zapewniający funkcje pobierania danych z bazy użytkowników (podmiotów logowania) w oparciu o usługi katalogowe LDAP w tym AD oraz źródła Kerberos;
  • zapewniający możliwość kopiowania kont i ustawienia polityki synchronizacji danych pomiędzy RedHat SSO a serwerem usługi katalogowej;
  • pozwalający na podpięcie wielu źródeł danych (LDAP, Kerberos) z określeniem priorytetów każdego z nich;
  • pozwalający na przekazywanie żądań uwierzytelnienia do systemów trzecich obsługujących protokoły SAML, OpenIDC z dodatkowo dostępnymi szablonami ułatwiającymi konfigurację przekazywania uwierzytelniania do popularnych usług społecznościowych min: Facebook, Github, Twiiter, LinkedIn, Microsoft, OpenShift i innych; z każdym wydaniem systemu lista tych usług się zwiększa;
  • udostępniający wbudowaną aplikację do zarządzania kontami użytkownika, ze wsparciem dla funkcji, resetowania haseł, edycji profilu – konfiguracji ustawień wielokrotnego uwierzytelniania w oparciu o Google Authenticator lub FreeOTP;
  • posiadający wbudowany podsystem wykrywanie prób ataków BruteForce, które administrator może łatwo uaktywnić;
  • posiadający rozbudowane mechanizmy logowania zdarzeń – wraz z intuicyjnym interfejsem do ich przeglądania, wyszukiwania;
  • posiadający łatwy w obsłudze interfejs zarządzanie otwartymi sesjami SSO;
  • wyposażony w funkcje eksportu i importu danych wraz z możliwościami zdefiniowania własnych szablonów konfiguracyjnych (np. dla typowych konfiguracji aplikacji klienckich);
  • posiadający rozbudowany i w pełni konfigurowalny system uprawnień i ról, jakie może przydzielać podmiotom logowania;
  • prezentujący model wielu domen bezpieczeństwa, co pozwala rozdzielić w ramach jednej skalowalnej instalacji nasze aplikacje na grupy i zapewnić dla poszczególnych grup inny mechanizm uwierzytelniania i autoryzacji.

Czytając powyższe możliwości, chciałoby się rzec z RedHat SSO Sky is the limit. Wszystkich zainteresowanych większym zgłębianiem tematu zachęcam do odwiedzenia poniższych witryn:

Źródła i materiały dodatkowe:

Specyfikacja RFC6479 Protokołu OAuth 2.0: https://tools.ietf.org/html/rfc6749
Specyfikacja RFC7591 protokołu dynamicznej rejestracji klienta dla OAuth 2.0: https://tools.ietf.org/html/rfc7591
Specyfikacja RFC5785 dobrze znanych identyfikatorów (.well_known) URI: https://tools.ietf.org/html/rfc5785
Zestaw specyfikacji protokołu OpenID Connect: http://openid.net/developers/specs/
Dokumentacja uwierzytelniania dla platformy OpenShift 3.9:
https://docs.openshift.com/container-platform/3.9/install_config/configuring_authentication.html
https://docs.openshift.com/container-platform/3.9/architecture/additional_concepts/authentication.html
Dokumentacja punktów końcowych (ang. endpointów) z informacjami dotyczącymi użytkowników:
/apis/user.openshift.io/v1/users/:
https://docs.openshift.com/container-platform/3.9/rest_api/apis-user.openshift.io/v1.User.html
/oapi/v1/users/:
https://docs.openshift.com/container-platform/3.9/rest_api/oapi/v1.User.html
Dokumentacja RedHat SSO:
https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.2/html/getting_started_guide/
https://access.redhat.com/documentation/en-us/red_hat_jboss_middleware_for_openshift/3/html-single/red_hat_single_sign-on_for_openshift/index

Tags

top