gpe_mw_ansible.rh_sso_multi_realm

Przegląd Wersje Wgląd

= rh-sso-multi-realm

== Przegląd

Ten rola ma na celu zarządzanie stałą instalacją Red Hat Single Sign-On (RH-SSO) na platformie Red Hat OpenShift Container Platform (OCP).

Umożliwia również zarządzanie (tj. tworzenie i usuwanie) konfigurowalnej liczby realms SSO w tej instalacji RH-SSO.

Rola ta może być przydatna w następujących okoliczności:

. Szkolenia prowadzone przez instruktora, hackathony i warsztaty: + Biorąc pod uwagę X liczbę studentów w ILT wymagających RH-SSO, utwórz jedną centralną instancję multi-realm RH-SSO, gdzie każdy student ma przypisany swój własny realm. + Student otrzymuje dane administracyjne do przypisanego realm. + Podejście to może być bardziej pożądane niż alternatywa, w której każdy student zarządza własnym RH-SSO.

. Wdrażanie RH-SSO + Niektóre cele nauczania mogą obejmować:

.. Demonstrowanie konfiguracji RH-SSO na OCP. + W szczególności, wariant RH-SSO, który wykorzystuje link:[usługę obsługującą tajne klucze x509].

.. Integracja z zewnętrznym dostawcą smtp w celu wysyłania e-maili i ułatwienia procesu samodzielnej rejestracji użytkowników. .. Wywołanie REST Admin API RH-SSO przy użyciu tokenów dostępu i odświeżania OAuth2.

UWAGA: Ta rola Ansible nie korzysta jeszcze z link:[Keycloak-operator]. Głównie z powodu braku możliwości skonfigurowania kontroli zdrowia oraz limitów i żądań w bieżącej implementacji operatora, jak opisano link:[tutaj]. Lista otwartych jał zajmujących się operatorem znajduje się link:[tutaj].

=== Odnośniki

. link:[Najlepsza dokumentacja keycloak] . link:[RH-SSO dla OCP] . link:[OCP Usługi Tajne Klucze Klientów]

=== Założenia i Wymagania wstępne . Upewnij się, że ansible jest zainstalowany na lokalnej maszynie. + Najbardziej niedawno testowana wersja anabla tej roli to: 2.6.5-1 na Fedora 29.

. Rola ta zakłada istnienie zdalnego klastra OCP z minimum 6 GB RAM i 2 CPU. + Wersja OCP, na której ta rola Ansible była ostatnio testowana to: 3.11.43.

. Ta rola Ansible mocno korzysta z klienta oc, który działa na lokalnej maszynie. Upewnij się, że ten klient oc znajduje się w $PATH twojego lokalnego środowiska, a jego wersja odpowiada wersji twojego środowiska OCP.

. [blue]#Lokalny klient oc musi być już uwierzytelniony w zdalnym środowisku OCP jako użytkownik cluster-admin.#

==== Certyfikat Wildcard

Ta rola Ansible zakłada, że twój wcześniej skonfigurowany klaster OCP korzysta z certyfikatu podpisanego przez wiarygodną jednostkę certyfikującą (np. LetsEncrypt).

UWAGA: link:[Warsztaty klastrów OCP] pozyskane z Red Hat Partner Demo System (RHPDS) i Red Hat Open Partner Enablement Network (OPEN) są wyposażone w certyfikaty LetsEncrypt. Możesz pominąć tę sekcję.

Bardzo fajny poradnik dotyczący pozyskiwania certyfikatu wildcard LetsEncrypt i jego stosowania w klastrze OCP można znaleźć tutaj:

Alternatywą dla certyfikatu wildcard dla całego klastra OCP może być link:[zabezpieczenie trasy RH-SSO certyfikatem LetsEncrypt].

== Wdrożenie RH-SSO

=== Zmienne środowiskowe

Następujące zmienne środowiskowe powinny być ustawione w powłoce twojego lokalnego środowiska, z którego wykonasz ansible. Te zmienne środowiskowe będą używane w całej tej roli.

Zaktualizuj każdą z następujących i następnie wykonaj:

echo "export OCP_PROJECT_PREFIX=<twoje inicjały>" >> ~/.bashrc # Używane później w labie podczas tworzenia projektu OCP echo "export ocp_sso_admin_id=sso0" >> ~/.bashrc

Wykonaj następujące:

echo "export SSO_SITE_ADMIN_USERNAME=master" >> ~/.bashrc echo "export SSO_SITE_ADMIN_PASSWORD=master" >> ~/.bashrc echo "export rhsso_project=rhsso-$ocp_sso_admin_id" >> ~/.bashrc source ~/.bashrc

OCP wildcard DNS po "aplikacjach"; np: 2345.openshift.opentlc.com

Przykłady:

Code Ready Containers: SUBDOMAIN_BASE=crc.testing

maszyna ravello : SUBDOMAIN_BASE=oc whoami --show-server | cut -d'-' -f 2 | cut -d':' -f 1

warsztat ocp : SUBDOMAIN_BASE=oc whoami --show-server | cut -d'.' -f 2,3,4,5 | cut -d':' -f 1

echo "export SUBDOMAIN_BASE=oc whoami --show-server | cut -d'.' -f 2,3,4,5 | cut -d':' -f 1" >> ~/.bashrc source ~/.bashrc

=== Konfiguracja Ansible

. Zainstaluj tę rolę: +

$ ansible-galaxy install gpe_mw_ansible.rh_sso_multi_realm --force -p /etc/ansible/roles

  • Alternatywnie, możesz także zainstalować rolę lokalnie w ten sam sposób:

$ ansible-galaxy install gpe_mw_ansible.rh_sso_multi_realm --force -p $HOME/.ansible/roles

. Utwórz Playbook: +

$ echo "

  • hosts: all become: false gather_facts: False vars_files: roles:
    • gpe_mw_ansible.rh_sso_multi_realm " > /tmp/rh_sso_multi_realm.yml

=== Provision RH-SSO

Przestrzeń nazw OCP dla aplikacji RH-SSO multi-realm będzie zarządzana przez następującego użytkownika: {{ocp_sso_admin_id}}. Użytkownik o nazwie {{ocp_sso_admin_id}} otrzyma przydział klastra, aby zarządzać limitami i żądaniami przypisanymi do 3scale

. Upewnij się, że ImageStream znajduje się w przestrzeni nazw openshift: .. redhat-sso73-openshift strumień obrazów. + Wykonaj następujące polecenie, jeśli ten strumień obrazów nie istnieje w przestrzeni nazw openshift: +

$ oc create -f https://raw.githubusercontent.com/jboss-container-images/redhat-sso-7-openshift-image/v7.4.0.GA/templates/sso74-image-stream.json -n openshift

. Wykonaj: +

$ ansible-playbook -i localhost, -c local /tmp/rh_sso_multi_realm.yml
-e"ocp_user_needs_quota=true"
-e"ACTION=create"
-e"SSO_SITE_ADMIN_USERNAME=$SSO_SITE_ADMIN_USERNAME"
-e"SSO_SITE_ADMIN_PASSWORD=$SSO_SITE_ADMIN_PASSWORD"
-e"admin_username=$ocp_sso_admin_id"
-e"subdomain_base=$SUBDOMAIN_BASE"

. Ustaw zmienną środowiskową, która odnosi się do adresu URL nowo utworzonego RH-SSO: +

echo "export rhsso_hostname=$(oc get route sso -n rhsso-$ocp_sso_admin_id --template "{{.spec.host}}" -n rhsso-$ocp_sso_admin_id)" >> ~/.bashrc

source ~/.bashrc

. Po zakończeniu provisioningu, zobacz certyfikat powiązany z nowym serwerem RH-SSO: +

$ echo '' | openssl s_client -connect oc get route sso -n $rhsso_project --template "{{.spec.host}}":443 | more

  • Zakładając, że klaster OCP został skonfigurowany z użyciem certyfikatu wildcard podpisanego przez jednostkę certyfikującą LetsEncrypt, odpowiedź powinna zawierać następujące informacje:

... subject=CN = master.3295.openshift.opentlc.com

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 ...

. Jeśli klaster OCP został skonfigurowany z użyciem LetsEncrypt (lub jakiejkolwiek innej wiarygodnej jednostki) i wydano mu certyfikat wildcard, możesz zobaczyć szczegóły w następujący sposób: +

$ curl -v -X GET "https://$rhsso_hostname/auth/realms/master/.well-known/openid-configuration" | python -m json.tool

...

  • subjectAltName: host "sso-rhsso-sso0.apps.3295.openshift.opentlc.com" matched cert's "*.apps.3295.openshift.opentlc.com"

=== Konsola administracyjna RH-SSO . Otwórz przeglądarkę internetową i przejdź do konsoli master realm : +

$ echo -en "\nhttps://$rhsso_hostname/auth/admin/master/console\n\n"

. Uwierzytelnij się przy użyciu wartości zmiennych środowiskowych $SSO_SITE_ADMIN_USERNAME i $SSO_SITE_ADMIN_PASSWORD, które zostały użyte podczas provisioningu instancji RH-SSO.

. Jako administrator strony RH-SSO masz pełny dostęp do wszystkich jego zasobów. + image::images/master_homepage.png[]

=== Usuń RH-SSO

$ ansible-playbook -i localhost, -c local /tmp/rh_sso_multi_realm.yml
-e"ACTION=remove"
-e"subdomain_base=$SUBDOMAIN_BASE"

[[realm_mgmt]] == Tworzenie / Usuwanie Realms

RH-SSO umożliwia tworzenie wielu realms. Każdy realm jest całkowicie autonomiczny od innych.

Ta część instalacji pomaga w automatyzacji tworzenia realmów dla różnych przypadków użycia.

==== Dostawcy SMTP Prawdopodobnie będziesz chciał, aby realm'y twojego RH-SSO miały możliwość wysyłania e-maili. Na przykład, generic realms skonfigurowane w ramach tej roli Ansible są dostosowane do procesu rejestracji użytkowników, który wymaga, aby nowy użytkownik zweryfikował rejestrację poprzez link przesłany w e-mailu.

W RH-SSO, ustawienia smtp są konfigurowane w zakresie realmu. Podczas provisioningu realmów możesz określić następujące zmienne ansible:

  • smtp_host
  • smtp_userid
  • smtp_passwd

Kilku dostawców SMTP z Darmowymi planami, z którymi przetestowano tę rolę Ansible, jest wymienionych poniżej:

. SocketLabs: Obecnie oferuje darmowy plan, który umożliwia link:[2000 e-maili miesięcznie]. . SendGrid: Obecnie oferuje darmowy plan, który umożliwia link:[100 e-maili dziennie].

=== Ogólne Realms

Za pomocą tej roli Ansible można stworzyć konfigurowalną liczbę SSO realms w oparciu o wartość następujących zmiennych: first_generic_realm i last_generic_realm.

Jeśli wartość last_generic_realm jest mniejsza od 1, generic realms nie zostaną utworzone.

Nazwy tych generic realms można dostosować, nadpisując zmienną ansible: realm_base_name.

Każdy z tych SSO realms pozwala na zarejestrowanie jednego lub więcej użytkowników jako użytkowników tego realm. Domyślnym zachowaniem zarejestrowanych użytkowników realmów jest to, że są pełnymi administratorami realm. Oczywiście takie zachowanie jest odpowiednie tylko dla scenariuszy demonstracyjnych i edukacyjnych.

=== KIE Realm Jeśli podczas tworzenia realms wartość loadKieRealm jest ustawiona na true, to zostanie utworzony specjalny realm wspierający scenariusze Business i Decision Manager.

. Szczegóły utworzonego kieRealm są następujące:

.. realmId: kieRealm .. Login URL: https://$rhsso_hostname/auth/admin/kieRealm/console .. Realm Admin User Id: ssoRealmAdmin .. Realm Admin Passwd: pam .. KIE powiązane role: ... admin ... kie-server ... kiemgmt ... rest-all

. Szczegóły wszystkich użytkowników zarejestrowanych w tym realm można zidentyfikować w następujący sposób: +

$ cat templates/kie-realm.json | jq .users

=== CRW Realm Jeśli podczas tworzenia realms wartość loadCRWRealm jest ustawiona na true, to zostanie utworzony specjalny realm wspierający Code Ready Workspaces.

Szczegóły utworzonego crwRealm

. realmId: crwRealm . Login URL: https://$rhsso_hostname/auth/admin/crwRealm/console . Admin User Id: admin . Admin Passwd: admin

=== OCP Realm

Jeśli podczas tworzenia realms wartość loadOCPRealm jest ustawiona na true, to w RH-SSO zostanie utworzony realm o nazwie ocp-realm. Jego celem jest służyć jako link:[IdentityProvider dla autoryzacji do OCP].

Szczegóły utworzonego ocp-realm są następujące:

. realmId: ocp-realm . Login URL: https://$rhsso_hostname/auth/admin/ocp-realm/console . SSO Client: ocp-client . Admin User Id: gpte-mgr . Admin Passwd: r3dh4t1! . Użytkownicy SSO: Konfigurowalna liczba użytkowników powiązanych z tym realm jest tworzona zgodnie z zmiennymi: start_ocp_user i end_ocp_user. + Nazwa każdego użytkownika tego realm zaczyna się od wartości: {{ocp_realm_user_base_name}} (domyślnie = ocp)

. OCP powiązane role: + Brak. Role muszą być przypisane przez administratora klastra.

Po skonfigurowaniu ocp-realm w RH-SSO pozostają dodatkowe kroki do wykonania w węźle głównym OCP. Szczegóły dotyczące tych kroków są opisane w: {{new_app_output_dir}}/ocp-realm-suggestion.txt W sekcji IdentityProvider pliku master-config.xml pamiętaj, aby nadpisać sekcję htpasswd ustawieniami ocp-client.

=== Tworzenie Realms

. Ustaw następujące zmienne środowiskowe w powłoce, a następnie wykonaj poniższe polecenie ansible: +

smtp_host= # Szczegóły dostawcy SMTP pozwalają RH-SSO dostarczać e-maile w celu wsparcia takich funkcjonalności jak Rejestracja Użytkowników smtp_userid= smtp_passwd=

FIRST_GENERIC_REALM=1 # pierwszy realm, który ma być zainicjowany: realm$FIRST_GENERIC_REALM LAST_GENERIC_REALM=1 # ostatni realm, który ma być zainicjowany: realm$LAST_GENERIC_REALM; jeśli wartość jest mniejsza niż 1, generic realms nie zostaną utworzone realm_base_name=realm # podstawowa nazwa twoich generic realms. Domyślnie: realm.

loadKieRealm=false # domyślnie false. Jeśli true, to zainicjowany będzie realm wykorzystywany do wsparcia instalacji Red Hat Process Automation i Decision Manager

loadCRWRealm=false # domyślnie false. Jeśli true, to zainicjowany będzie realm, aby wspierać Red Hat Code Ready Workspaces

crw_redirect_url="" # Dotyczy tylko, jeśli loadCRWRealm=true. Ustaw na URL trasy CodeReadyWorkspace.

loadOCPRealm=true # domyślnie false. Jeśli true, będzie konfigurował realm zwany ocp-realm, który może być używany do konfigurowania OCP w celu korzystania z RH-SSO do autoryzacji end_ocp_user=1 # ostatni użytkownik, który zostanie utworzony w ocp-realm: user$end_ocp_user

$ ansible-playbook -i localhost, -c local /tmp/rh_sso_multi_realm.yml
-e"ACTION=realm_mgmt"
-e"create_realms=true"
-e"subdomain_base=$SUBDOMAIN_BASE"
-e"smtp_host=$smtp_host"
-e"smtp_passwd=$smtp_passwd"
-e"smtp_userid=$smtp_userid"
-e"SSO_SITE_ADMIN_USERNAME=$SSO_SITE_ADMIN_USERNAME"
-e"SSO_SITE_ADMIN_PASSWORD=$SSO_SITE_ADMIN_PASSWORD"
-e"admin_username=$ocp_sso_admin_id"
-e"first_generic_realm=$FIRST_GENERIC_REALM"
-e"last_generic_realm=$LAST_GENERIC_REALM"
-e"realm_base_name=$realm_base_name"
-e"loadKieRealm=$loadKieRealm"
-e"loadCRWRealm=$loadCRWRealm"
-e"crw_redirect_url=$crw_redirect_url"
-e"loadOCPRealm=$loadOCPRealm"
-e"end_ocp_user=$end_ocp_user"
-e"rhsso_hostname=$rhsso_hostname"

. Po zakończeniu wykonania ansible, powinny pojawić się komunikaty w konsoli, takie jak: +

rh-sso-multi-realm : Zrealizowanie realmów zakończone]

ok: [localhost] => { "msg": [ "create_realms: true", "new_app_output_dir: /home/jbride/provisioning_output/3295.openshift.opentlc.com", "start and end realms = 1 25" ] }

  • Reprezentacja json każdego utworzonego realm może być znaleziona w katalogu wymienionym jako: new_app_output_dir.

==== Usuń Realmy

$ ansible-playbook -i localhost, -c local /tmp/rh_sso_multi_realm.yml
-e"ACTION=realm_mgmt"
-e"first_generic_realm=$FIRST_GENERIC_REALM"
-e"last_generic_realm=$LAST_GENERIC_REALM"
-e"subdomain_base=$SUBDOMAIN_BASE"
-e"SSO_SITE_ADMIN_USERNAME=$SSO_SITE_ADMIN_USERNAME"
-e"SSO_SITE_ADMIN_PASSWORD=$SSO_SITE_ADMIN_PASSWORD"
-e"admin_username=$ocp_sso_admin_id"
-e"rhsso_hostname=$rhsso_hostname"
-e"create_realms=false"

== Ogólne Realms: Rejestracja Użytkownika Ta sekcja laboratorium zakłada, że już utworzono jeden lub więcej ogólnych SSO realms zgodnie z sekcją <> tego laboratorium.

Celem tej sekcji jest dostarczenie studentom instrukcji szczegółowych dotyczących rejestracji jako użytkownik wcześniej utworzonego ogólnego SSO realm. Całą tę sekcję można skopiować i wkleić do instrukcji laboratorium kursu, który wykorzystuje ten multi-realm RH-SSO.

. Ustaw zmienną środowiskową, która odpowiada określonemu realm (np. = realm1...realm20), który chcesz wykorzystać: +

$ echo "export rhsso_realm=" >> ~/.bashrc

$ source ~/.bashrc

. Otwórz przeglądarkę internetową i przejdź do konsoli swojego docelowego realm : +

$ echo -en "\nhttps://$rhsso_hostname/auth/admin/$rhsso_realm/console\n\n"

. Kliknij link Zarejestruj się: + image::images/register_link.png[]

. Wypełnij wszystkie pola formularza rejestracji. Upewnij się, że używasz ważnego e-maila. . Kliknij Zarejestruj. . Spodziewaj się, że przeglądarka przekieruje cię na stronę, wskazującą na konieczność weryfikacji twojego e-maila i konta: + image::images/email_verification.png[] . Sprawdź swoją skrzynkę e-mailową w poszukiwaniu prośby o weryfikację podobnej do następującej: + image::images/registration_email.png[]

. W e-mailu kliknij link do weryfikacji adresu e-mail. . Twoja przeglądarka powinna teraz być przekierowana na stronę główną twojego docelowego SSO realm + image::images/realm_homepage.png[] + UWAGA: Ten nowo zarejestrowany użytkownik realm ma dostęp administracyjny do wszystkich ustawień realm.

. W terminalu lokalnej maszyny ustaw zmienne środowiskowe specyficzne dla nowego użytkownika realm: +

$ realmUserId=<zmień mnie> $ realmPasswd=<zmień mnie>

. W swojej przeglądarki przejdź do sekcji Klienci swojego realm. + Zauważ obecność 5 domyślnych klientów SSO. Każdy z nich jest skonfigurowany do obsługi różnych protokołów OAuth2 i OIDC. + image::images/default_sso_clients.png[]

=== Ogólne Realms: Zbadaj Klientów

Klient, w kontekście terminologii OAuth2, jest aplikacją żądającą dostępu do zabezpieczonego zasobu w imieniu Właściciela Zasobów. Właściciel Zasobów jest zazwyczaj końcowym użytkownikiem (znanym również jako jednostka), a zabezpieczony zasób może być poufnymi atrybutami z jednej lub kilku tożsamości tego Właściciela/Zidentyfikowanej jednostki.

RH-SSO pozwala na tworzenie niestandardowych klientów. Jednak w celach tego laboratorium, wykorzystasz jednego z domyślnych klientów, który jest dostarczany z twoim realm.

==== Przegląd realm-management To jest klient bearer-only, który będzie powiązany z zabezpieczonym serwisem backendowym w późniejszej części tego laboratorium. Klient bearer-only jest używany do usług backendowych, które nie inicjują logowania z Red Hat SSO, ale wymagają ważnego tokenu ID. Token ID jest zazwyczaj używany przez usługę backendową do określenia dostępu do zasobów za pomocą kontroli dostępu opartej na rolach (RBAC).

==== Przegląd admin-cli

W tym laboratorium definiujesz również drugi klient o nazwie admin-cli. admin-cli jest klientem OAuth2. Używasz admin-cli w dalszej części tego laboratorium do wyłącznie celów testowych.

Zauważ, że admin-cli jest włączony w celu używania przepływu OAuth2, zwanego Resource Owner Password Credentials.

Za pomocą tego przepływu klient pozwala na wymianę identyfikatora użytkownika i poświadczeń hasła – w tym przypadku twojego użytkownika SSO – na token dostępu. Token ten można następnie wykorzystać do uzyskania dostępu do REST API twoich usług biznesowych.

== Ogólne Realms: Punkty końcowe

=== Przegląd

Twój serwer Red Hat SSO implementuje punkt końcowy o nazwie well-known, który wylistowuje inne punkty końcowe i opcje konfiguracyjne związane z implementacją OAuth2/OpenID Connect Red Hat Single Sign-On.

Celem tej sekcji jest zaznajomienie użytkownika (tj. studenta) z niektórymi punktami końcowymi well-known specyfikacji OIDC. Te punkty końcowe well-known są specyficzne dla SSO realm użytkownika.

Red Hat SSO udostępnia również punkty końcowe administracyjne realm. Kilka z tych punktów końcowych administracyjnych realm również wprowadzono w tej sekcji.

Całą tę sekcję można skopiować i wkleić do instrukcji laboratorium twojego kursu.

Następujące narzędzia muszą być zainstalowane na twojej lokalnej maszynie:

. openssl . keytool: (z Java Development Kit)

=== Punkty końcowe OIDC well-known

. Upewnij się, że narzędzie link:[jq] jest zainstalowane na twoim komputerze.

. Wykonaj poniższe polecenie i zapoznaj się z odpowiedzią: +

$ curl -X GET "https://$rhsso_hostname/auth/realms/$rhsso_realm/.well-known/openid-configuration" | python -m json.tool

  • Różne klienci OpenID Connect Relying Party wywołują te punkty końcowe Red Hat SSO w całym reszcie tego laboratorium.
  • Dwa punkty końcowe są szczególnie interesujące: ** link:[Punkt końcowy autoryzacji] ** link:[Punkt końcowy tokena]

. Zobacz listę typów grant_types_supported: +

$ curl -X GET "https://$rhsso_hostname/auth/realms/$rhsso_realm/.well-known/openid-configuration" | jq -r '.grant_types_supported'

  • Przykładowe wyjście

[ "authorization_code", "implicit", "refresh_token", "password", "client_credentials" ]

  • Lista typów grant_type_supported odpowiada różnym przepływom OAuth2/OpenID Connect, które są obsługiwane przez serwer Red Hat SSO.

=== Token dostępu OAuth2

. Upewnij się, że wartości zmiennych środowiskowych $rhsso_realm, $realmUserId i $realmPasswd są ustawione w twojej powłoce.

. Pobierz token dostępu OIDC z realm: +

$ retrieve_token_url="https://$rhsso_hostname/auth/realms/$rhsso_realm/protocol/openid-connect/token"

$ TKN=$(curl -X POST "$retrieve_token_url"
-H "Content-Type: application/x-www-form-urlencoded"
-d "username=$SSO_SITE_ADMIN_USERNAME"
-d "password=$SSO_SITE_ADMIN_PASSWORD"
-d "grant_type=password"
-d "client_id=admin-cli"
| sed 's/.access_token":"//g' | sed 's/".//g')

  • UWAGA: Ta odpowiedź z punktu końcowego tokenu OAuth2 może również zawierać token refresh_token. Token refresh_token może być opcjonalnie używany do odświeżania tokenu dostępu, gdy ten ostatni wygasa.

=== Klucz publiczny Realm W tej sekcji pobierzesz klucz publiczny swojego realm. Później ten klucz publiczny można załączyć do adaptera keycloak, który jest wstrzykiwany do usługi biznesowej backendowej. Usługa backendowa będzie mogła uczestniczyć w przepływie OpenID Connect.

. Gdy został utworzony realm, automatycznie generowana jest para kluczy i certyfikat samopodpisany. + Keycloak obecnie obsługuje tylko podpisy RSA, więc istnieje tylko jeden aktywny zestaw kluczy. . Ustaw wartość zmiennej środowiskowej $retrieve_key_url: +

$ retrieve_key_url="https://$rhsso_hostname/auth/admin/realms/$rhsso_realm/keys"

. Pobierz wartość klucza RSA: +

$ RSA_PUB_KEY=$(curl -k -X GET "$retrieve_key_url"
-H "Authorization: Bearer $TKN"
| jq -r '.keys[] | select(.type=="RSA") | .publicKey' )

$ echo $RSA_PUB_KEY MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAktETcy8xI/rxit6DH9LW1kAB/0XKiV5eujQL9rL+9WD9ZruC2hMFKhme+kyNjNVCf2cqiY0IChmSqTrfm7OcL3k+Rfq91zDgMI19pszoMGyG2Ek2UZYWNBhydBIPBr70njec7Vq8a/bn88evEROetlUHWWcSuwqsiooHD3RNzuDgRB+2ztim8KttusbZxGPGjIjCNlFEBVetfxpHbTBCeN8dAdOiYRjmW6QVxEUH9m0Hcvcw8XwEyVRvd1HpkzMK0BVBnN73d/G743pvyc2huv/Cj+zoBipxNwKJ8rnPGupBVK/17WmyFgi+CDhZww8EwRiSSwrow+Qv1hUP9bnoFwIDAQAB

=== Opcjonalnie: Zobacz certyfikat RSA Realm

. Pobierz wartość certyfikatu RSA realm: +

$ RSA_CERT=$(curl -k -X GET "$retrieve_key_url"
-H "Authorization: Bearer $TKN"
| jq -r '.keys[] | select(.type=="RSA") | .certificate' )

$ echo $RSA_CERT MIICuTCCAaECBgFcJ85oAjANBgkqhkiG9w0BAQsFADAgMR4wHAYDVQQDDBVyaHRfZ3B0ZV8zc2NhbGVfcmVhbG0wHhcNMTcwNTIwMjEzOTE3WhcNMjcwNTIwMjE0MDU3WjAgMR4wHAYDVQQDDBVyaHRfZ3B0ZV8zc2NhbGVfcmVhbG0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCS0RNzLzEj+vGK3oMf0tbWQAH/RcqJXl66NAv2sv71YP1mu4LaEwUqGZ76TI2M1UJ/ZyqJjQgKGZKoGt+bs5wveT5F+r3XMOAwjX2mzOgwbIbYSTZRlhY0GHJ0Eg8GvvSeN5ztWrxr9ufzx68RE562VQdZZxK7CqyKigcPdE3O4OBEH7bO2Kbwq226xtnEY8aMiMI2UUQFV61/GkdtMEJ43x0B06JhGOZbpBXERQf2bQdy9zDxfATJVG93UemTMwrQFUGc3vd38bvjem/JzaG6/8KP7OgGKnE3Aonyuc8a6kFUr/XtabIWCL4IOFnDDwTBGJJLCujD5C/WFQ/1uegXAgMBAAEwDQYJKoZIhvcNAQELBQADggEBABM81ImbVgN5VoD7b7RCH0jYW9pUzIwjUUWU3P1E+RGMwyyhgCwMK/wDpzty5jno7XyE1oePgZg8OmXY2FGlWi0JzCF8WGsHVEZWiKPkSs9miz5+x5VqKUEM4nrmF3OgEFPH/gJPhx8/GNutSpf0AIHcVDeWL7nayyjMZWSdXm82crd5gZXDSmNgjjeqhTCPFCrMv3nQq9wsL3jDEc7pOAkblsu83GCyD0WmdHqAY/EdT/Jz1b2lJw/Oda6b9Hg93MvnnaJMam7Q7q4K0oRFaYD0ZtYm926YQg5f1iLzoocuouuOeHrMfZQOqb96iaGYeQF+GghpfNXwKMLOhQh3tJM=

. Utwórz plik PEM z certyfikatem: .. Ustaw zmienną środowiskową definiującą ścieżkę do docelowego certyfikatu x.509 w formacie PEM: +

$ realm_cert=/tmp/$rhsso_realm.pem

.. Utwórz certyfikat x.509 w formacie PEM: +

$ echo "-----BEGIN CERTIFICATE-----" > $realm_cert; echo $RSA_CERT >> $realm_cert; echo "-----END CERTIFICATE-----" >> $realm_cert

. Zobacz szczegóły certyfikatu SSO Realm: +

$ openssl x509 -in $realm_cert -text -noout

== Ogólne Realms: Test dymny zabezpieczeń OAuth2 i RBAC

=== Przegląd zabezpieczonej usługi biznesowej

Często usługi potrzebują informacji o tożsamości końcowego użytkownika wywołującego jej funkcjonalność. Jednym z popularnych przypadków użycia jest potrzeba kontroli dostępu opartej na rolach (RBAC). Na podstawie roli końcowego użytkownika, usługa biznesowa decyduje o przyznaniu dostępu do zasobu, do którego ma dostęp.

UWAGA: RBAC obsługiwane przez usługę backendową jest różne od polityki oraz limitów wydajności, które są obsługiwane przez Menedżera API.

W tej sekcji laboratorium będziesz testować bezpieczeństwo OAuth2/OIDC za pomocą prostej usługi backendowej, napisanej przy użyciu technologii link:[Thorntail Java Microprofile].

Kod źródłowy tej prostej usługi można znaleźć link:[tutaj].

Aby twoja usługa backendowa Microprofile mogła wdrożyć RBAC, należy:

  • Wpleść zasady RBAC w twoją usługę biznesową: W celach tego laboratorium, ten krok już został wykonany dla ciebie. W szczególności, zwróć uwagę na następujący nowy fragment kodu w pliku konfiguracyjnym src/main/resources/project-defaults.yml:

swarm: deployment: wf-swarm-oauth.war: web: login-config: auth-method: KEYCLOAK security-constraints: - url-pattern: / methods: [GET] roles: [admin]

  • Dodaj adapter Keycloak: Twoja usługa backendowa musi być wstrzyknięta w funkcjonalność, która pozwala jej komunikować się z serwerem RH SSO. W szczególności, musi pobrać klucz publiczny realm serwera RH SSO.

  • Rozpakuj JWT za pomocą klucza publicznego realm RH SSO: W czasie działania, usługa biznesowa backendowa otrzymuje token JWT z informacjami tożsamości o końcowym użytkowniku. Te informacje tożsamości obejmują rolę końcowego użytkownika. Gdy token JWT zostanie odebrany, wbudowany adapter Keycloak weryfikuje autentyczność tokenu JWT (za pomocą klucza publicznego realm RH SSO). Gdy JWT zostanie potwierdzony jako pochodzący z serwera RH SSO, usługa biznesowa wykorzystuje te informacje tożsamości do określenia, czy końcowy użytkownik ma odpowiednie poświadczenia do uzyskania dostępu do pożądanego zasobu.

=== Wdrożenie W tej sekcji zdefiniujesz DeploymentConfig dla prostej usługi biznesowej RESTful, która ma być zabezpieczona za pomocą protokołu OIDC.

. Utwórz nowy projekt dla twoich symulowanych aplikacji serwisów RESTful: +

$ oc new-project $OCP_PROJECT_PREFIX-bservices
--display-name="$OCP_PROJECT_PREFIX-bservices"
--description="Usługi Biznesowe, które mają być zabezpieczone przy użyciu OIDC"

. Jeśli nie jesteś już tam, przełącz się na ten nowy projekt: +

$ oc project $OCP_PROJECT_PREFIX-bservices

. Utwórz nową aplikację opartą na prostej usłudze RESTful, zaimplementowanej przy użyciu Wildfly Swarm: +

$ oc create -f https://raw.githubusercontent.com/gpe-mw-training/3scale_onpremise_implementation_labs/secure/services/wfswarm-date-service/wf-swarm-oauth.yaml

$ oc new-app
--template=wf-swarm-oauth
--param=JAVA_OPTIONS="-Djavax.net.debug=ssl -Dswarm.keycloak.json.path=/app/rhsso-config/keycloak.json"

  • To polecenie tworzy konfigurację wdrożenia z wstrzymanym pod. Pod obejmuje kontener oparty na Javie. --XmX JVM w kontenerze jest ustawione na 80% z 1Gi; więc około 800 MB

=== adapter keycloak.json

. Zdefiniuj adapter keycloak specyficzny dla istniejącego klienta bearer-only o nazwie: realm-management: +

$ echo " { "realm": "$rhsso_realm", "bearer-only": "true", "auth-server-url": "http://$rhsso_hostname/auth", "ssl-required": "external", "realm-public-key": "$RSA_PUB_KEY", "resource": "realm-management", "use-resource-role-mappings": "true" }" > /tmp/keycloak.json

. Utwórz ConfigMap z pliku keycloak.json. + Następnie zamontuj go jako wolumen i wskaż WildFly Swarm na zamontowany keycloak.json.

.. Utwórz ConfigMap o nazwie date-service-rhsso w projekcie bservices na OpenShift z pliku keycloak.json: +

$ oc create configmap keycloak-resource-cm --from-file=/tmp/keycloak.json

.. Zamontuj configmap jako wolumen w DC Swarm: +

$ oc set volume dc/wf-swarm-oauth --add --overwrite
--name=keycloak-resource-volume
-m /app/rhsso-config
--type=configmap
--configmap-name=keycloak-resource-cm

. Wznowienie wstrzymanej konfiguracji wdrożenia: +

$ oc rollout resume dc/wf-swarm-oauth

. Sprawdź plik dziennika zabezpieczonej usługi wildfly swarm. W podobny sposób powinny pojawić się komunikaty logów: +

DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) KeycloakServletException initialization DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) użycie /WEB-INF/keycloak.json DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) Użycie dostawcy 'secret' do autoryzacji klienta 'realm-management' DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) Załadowany sekret clientCredentialsProvider DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) Załadowany JWT clientCredentialsProvider DEBUG [org.keycloak.adapters.KeycloakDeployment] (ServerService Thread Pool -- 11) resolveUrls DEBUG [org.keycloak.adapters.KeycloakDeploymentBuilder] (ServerService Thread Pool -- 11) Użycie authServerUrl: https://sso-rhsso-sso0.apps.3295.openshift.opentlc.com/auth, tokenUrl: https://sso-rhsso-sso0.apps.3295.openshift.opentlc.com/auth/realms/realm1/protocol/openid-connect/token, relativeUrls: NEVER DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) Keycloak używa konfiguracji na poziomie wdrożenia. DEBUG [org.keycloak.adapters.wildfly.WildflyKeycloakServletExtension] (ServerService Thread Pool -- 11) tworzenie WildflyAuthenticationMechanism DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) Ustawienie ścieżki cookie jsession na: /

... INFO [org.wildfly.swarm] (main) WFSWARM99999: WildFly Swarm jest gotowy

=== Test zabezpieczonej usługi biznesowej OIDC:

. Wykonaj następujące polecenie, aby uzyskać nowy token dostępu (ponieważ pierwotny token dostępu najprawdopodobniej wygasł do tej pory): +

$ TKN=$(curl -k -X POST "$retrieve_token_url"
-H "Content-Type: application/x-www-form-urlencoded"
-d "username=$realmUserId"
-d "password=$realmPasswd"
-d "grant_type=password"
-d "client_id=admin-cli"
| sed 's/.access_token":"//g' | sed 's/".//g')

  • Technicznie rzecz biorąc, lepszym podejściem byłoby użycie funkcji refresh_token OAuth2 zamiast ponownego generowania nowego tokenu dostępu. W tej metodzie parametry grant_type=refresh_token&refresh_token=$REFRESH_TOKEN są określone w treści żądania. Wartość $REFRESH_TOKEN mogłaby być pozyskana przez jej analizę z odpowiedzi pierwotnego żądania o tokeny OAuth2.

. Wykonaj następujące polecenie, aby wywołać zabezpieczoną usługę RESTful przy użyciu tokena OAUTH2 dostępu: +

$ curl -k -v -X GET
-H "Authorization: Bearer $TKN"
https://oc get route/wf-swarm-oauth --template "{{.spec.host}}"/time/now

. Odpowiedź powinna zawierać nagłówki i treści podobne do następujących: +

...

  • TLSv1.2 (IN), TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
  • ALPN, server did not agree to a protocol
  • Server certificate:
  • subject: CN=master.3295.openshift.opentlc.com
  • start date: Nov 13 20:48:38 2018 GMT
  • expire date: Feb 11 20:48:38 2019 GMT
  • issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
  • SSL certificate verify ok.

    GET /time/now HTTP/1.1 Host: wf-swarm-oauth-jb-bservices.apps.3295.openshift.opentlc.com User-Agent: curl/7.61.1 Accept: / Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJIbm5ZV1NMM1pqSTh0T0VHZVlWZHpIbXVVSFpYSDdJbHM1dEJkSVU0VHMwIn0.eyJqdGkiOiIwOWQyZDZhMC1kZmRjLTRjNTctOWZjOC1mMDVjZGU0MjFjMjAiLCJleHAiOjE1NDIyMTQwMzYsIm5iZiI6MCwiaWF0IjoxNTQyMjEzNzM2LCJpc3MiOiJodHRwczovL3Nzby1yaHNzby1zc28wLmFwcHMuMzI5NS5vcGVuc2hpZnQub3BlbnRsYy5jb20vYXV0aC9yZWFsbXMvcmVhbG0xIiwiYXVkIjoiYWRtaW4tY2xpIiwic3ViIjoiNDc2Y2ZlOTAtMTQwMC00ODUwLTg5M2YtNjNlNWM5MjFmMjYxIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoiYWRtaW4tY2xpIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiNmQ2ODcyZjgtMjQwZC00MWVjLWE4NmQtM2FiOGEyZTVmZWE5IiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6W10sInJlc291cmNlX2FjY2VzcyI6e30sIm5hbWUiOiJKZWZmIEJyaWRlIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiamJyaWRlIiwiZ2l2ZW5fbmFtZSI6IkplZmYiLCJmYW1pbHlfbmFtZSI6IkJyaWRlIiwiZW1haWwiOiJqYnJpZGUrMUByZWRoYXQuY29tIn0.PoqUaPncOt9GFpCdHTQE1zuVK3FHTrgkBhmthww9geM-pbV84UTLXr1ggD-v7s9DGYAaVTe7ZUcda0DT5ioADpPuik6qADPf0ZkkWGQiQ6aieBxuTikM0NeeM58Vwhcr5lDphD0VY70SK_aaevUKkZFkmKxUxeUj-8TZob0n5Jip376D8NvDtfoZEhiWngBW58H1J4-sg27qzaUgVqaEoM7zUEvZocgD6j6rUqnThNREJVMi3sUYli6y_LzzqrMwZrWTlxAIYcR6OQ7GK-WTtN_F18_5O28Zaojq1QRHjhotcHPXCTrJaf4XqNEZFGML8yVh5lgzd-HVMt3Lrd_15Q

    < HTTP/1.1 200 OK

...

{"value" : "The time is 2018-11-14T16:44:57.576Z"}

. Sprawdź plik dziennika zabezpieczonej usługi wildfly swarm. Powinny pojawić się komunikaty logów podobne do następujących: +

DEBUG [org.keycloak.adapters.PreAuthActionsHandler] (default task-1) adminRequest http://wf-swarm-oauth-jb-bservices.apps.3295.openshift.opentlc.com/time/now DEBUG [org.keycloak.adapters.wildfly.WildflyRequestAuthenticator] (default task-1) propagate security context to wildfly DEBUG [org.keycloak.adapters.RequestAuthenticator] (default task-1) Użytkownik '476cfe90-1400-4850-893f-63e5c921f261' wywołuje 'http://wf-swarm-oauth-jb-bservices.apps.3295.openshift.opentlc.com/time/now' na kliencie 'realm-management' DEBUG [org.keycloak.adapters.RequestAuthenticator] (default task-1) Bearer AUTORYZOWANY DEBUG [org.keycloak.adapters.AuthenticatedActionsHandler] (default task-1) AuthenticatedActionsValve.invoke http://wf-swarm-oauth-jb-bservices.apps.3295.openshift.opentlc.com/time/now DEBUG [org.keycloak.adapters.AuthenticatedActionsHandler] (default task-1) Wymuszenie polityki jest wyłączone. INFO [stdout] (default task-1) userId = 476cfe90-1400-4850-893f-63e5c921f261

== Dodatek

=== Ustawienie logowania RH-SSO na DEBUG (Opcjonalnie)

Czasami możesz chcieć zwiększyć poziom logowania pakietu java org.keycloak twojego serwera RH-SSO z INFO na DEBUG. Można to zrobić, gdy próbujesz rozwiązać problemy z protokołami bezpieczeństwa i RH-SSO.

. Otwórz zdalną sesję powłokową do swojego podu RH-SSO: +

$ oc rsh -n $rhsso_project
$(oc get pod -n $rhsso_project | egrep "sso-[1-9]" | awk '{print $1}')

. Edytuj plik konfiguracyjny główny dla serwera RH-SSO: .. Otwórz plik konfiguracyjny w edytorze: +

$ vi /opt/eap/standalone/configuration/standalone-openshift.xml

.. Wyszukaj pole org.jboss.as.config: +

        <logger category="org.jboss.as.config">
            <level name="DEBUG"/>
        </logger>

.. Tuż poniżej tego bloku XML, dodaj podobny blok, jak poniżej: +

        <logger category="org.keycloak">
            <level name="DEBUG"/>
        </logger>

.. Zapisz zmiany i wyjdź.

. Restartuj JVM keycloak w tym samym podzie RH-SSO: .. Przejdź do następującego katalogu: +

cd /opt/eap/bin/

.. Wykonaj tę komendę: +

./jboss-cli.sh --connect ':reload'

O projekcie

Red Hat Single Sign-On Multi-Realm Automated Provisioning

role identityprovider oauth2 oidc rhsso
Zainstaluj
ansible-galaxy install gpe_mw_ansible.rh_sso_multi_realm
GitHub repozytorium
0 gwiazdki
2 forki
8 otwarte zgłoszenia
Licencja
Unknown
Pobrania
89
Właściciel
gpe-mw-ansible-org
Ansible roles to support RHT middleware labs