gpe_mw_ansible.rh_sso_multi_realm

Überblick Versionen Einblicke

Here is the translated text into German:

:scrollbar: :data-uri: :toc2: :linkattrs:

= rh-sso-multi-realm

:numbered:

== Übersicht

Diese Rolle dient dazu, eine dauerhafte Red Hat Single Sign-On (RH-SSO) Installation auf der OpenShift Container Platform (OCP) von Red Hat bereitzustellen.

Sie ermöglicht auch die Verwaltung (z.B. Erstellung und Löschung) einer konfigurierbaren Anzahl von SSO Bereichen innerhalb dieser RH-SSO Installation.

Diese Rolle könnte in folgenden Situationen nützlich sein:

. Instructor Led Training (ILTs), Hackathons und Workshops: + Bei einer bestimmten Anzahl von Studenten in einem ILT, die RH-SSO benötigen, wird ein zentraler multi-realm RH-SSO bereitgestellt, wobei jedem Studenten ihr eigener Bereich zugewiesen wird. + Der Student erhält administrative Zugangsdaten für seinen zugewiesenen Bereich. + Dieser Ansatz könnte wünschenswerter sein als die Alternative, bei der jeder Student seine eigene RH-SSO bereitstellt.

. RH-SSO Implementierung + Einige Lernziele könnten sein:

.. Demonstration der Bereitstellung von RH-SSO auf OCP. + Insbesondere die RH-SSO Variante, die die https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.2/html-single/red_hat_single_sign-on_for_openshift/index#what_is_red_hat_single_sign_on[Service zur Bereitstellung von x509-Zertifikatsgeheimnissen] nutzt.

.. Integration eines externen SMTP-Anbieters um E-Mails zu versenden und einen Workflow zur Selbstregistrierung von Benutzern zu ermöglichen. .. Aufruf der REST-Admin-API von RH-SSO unter Verwendung von OAuth2 Access und Refresh Tokens.

HINWEIS: Diese Ansible-Rolle verwendet derzeit nicht den https://github.com/keycloak/keycloak-operator[Keycloak-Operator]. Immer wegen der Unmöglichkeit, Gesundheitsprüfungen sowie Limits und Anforderungen in der aktuellen Implementierung des Operators, wie hier beschrieben, zu konfigurieren. Die Liste der derzeit offenen Jiras, die mit dem Operator in Verbindung stehen, finden Sie https://issues.redhat.com/browse/KEYCLOAK-13065?jql=project%20%3D%20KEYCLOAK%20AND%20component%20%3D%20%22Containers%20-%20Operator%22[hier].

=== Referenz

. https://www.keycloak.org/documentation.html[Neueste Keycloak-Dokumentation] . https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.2/html-single/red_hat_single_sign-on_for_openshift[RH-SSO für OCP] . https://docs.openshift.com/container-platform/3.10/dev_guide/secrets.html#service-serving-certificate-secrets[OCP Servicedienstzertifikat Geheimnisse]

=== Annahmen und Anforderungen . Stellen Sie sicher, dass Ansible auf Ihrem lokalen Rechner installiert ist. + Die Version von Ansible, auf der diese Ansible-Rolle zuletzt getestet wurde, ist: 2.6.5-1 auf Fedora 29.

. Diese Ansible-Rolle geht von der Existenz eines Remote-OCP-Clusters mit mindestens 6 GB RAM und 2 CPUs aus. + Die Version von OCP, auf der diese Ansible-Rolle zuletzt getestet wurde, ist: 3.11.43.

. Diese Ansible-Rolle verwendet stark einen oc-Client, der auf Ihrem lokalen Rechner läuft. Stellen Sie sicher, dass dieser oc-Client im $PATH Ihrer lokalen Umgebung ist und seine Version mit der Ihrer OCP-Umgebung übereinstimmt.

. [blue]#Der lokale oc-Client muss bereits als cluster-admin Benutzer im Remote-OCP-Umfeld authentifiziert sein.#

==== Wildcard-Zertifikat

Diese Ansible-Rolle geht davon aus, dass Ihr bereits vorhandener OCP-Cluster mit einem von einer legitimen Zertifizierungsstelle (wie LetsEncrypt) signierten Zertifikat konfiguriert ist.

HINWEIS: https://github.com/redhat-gpe/mw_docs/blob/master/ocp_cluster_workshop.adoc[OCP-Cluster-Workshops] aus dem Red Hat Partner-Demo-System (RHPDS) und dem Red Hat Open Partner Enablement Network (OPEN) sind bereits mit LetsEncrypt-Zertifikaten ausgestattet. Sie können diesen Abschnitt überspringen.

Einen sehr schönen Lehrgang zum Erwerb eines LetsEncrypt-Wildcard-Zertifikats und dessen Anwendung auf Ihren OCP-Cluster finden Sie hier:

Eine Alternative zu einem Wildcard-Zertifikat für Ihren gesamten OCP-Cluster könnte einfach das sichere https://developers.redhat.com/blog/2019/02/06/using-a-public-certificate-with-red-hat-single-sign-on-keycloak/[Sichern der RH-SSO-Route mit einem LetsEncrypt] Zertifikat sein.

== RH-SSO Bereitstellung

=== Umgebungsvariablen

Die folgenden Umgebungsvariablen müssen in der Shell Ihrer lokalen Umgebung festgelegt werden, von der Sie Ansible ausführen werden. Diese Umgebungsvariablen werden während dieser Rolle verwendet.

Aktualisieren Sie jede der folgenden Variablen und führen Sie sie dann aus:

echo "export OCP_PROJECT_PREFIX=" >> ~/.bashrc # Wird später im Labor verwendet, wenn ein OCP-Projekt erstellt wird echo "export ocp_sso_admin_id=sso0" >> ~/.bashrc

Führen Sie Folgendes aus:

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 nach "apps"; z.B.: 2345.openshift.opentlc.com

Beispiele:

Code Ready Containers: SUBDOMAIN_BASE=crc.testing

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

ocp workshop : 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

=== Ansible-Setup

. Installieren Sie diese Rolle: +

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

  • Alternativ können Sie die Rolle auch lokal wie folgt installieren:

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

. Erstellen Sie ein 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

=== RH-SSO bereitstellen

Der OCP-Namespace für die RH-SSO-Multi-Realm-Anwendung wird von folgendem Benutzer verwaltet: {{ocp_sso_admin_id}}. Ein Benutzer mit der Bezeichnung {{ocp_sso_admin_id}} erhält ein Clusterquote, um die Limits und Anforderungen von 3scale zu verwalten.

. Stellen Sie sicher, dass der ImageStream im openshift-Namespace vorhanden ist: .. redhat-sso73-openshift Image-Stream. + Führen Sie Folgendes aus, wenn dieser Image-Stream nicht im openshift-Namespace vorhanden ist: +

$ 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

. Führen Sie Folgendes aus: +

$ 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"

. Setzen Sie eine Umgebungsvariable, die auf die URL der neu bereitgestellten RH-SSO verweist: +

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

. Nachdem die Bereitstellung abgeschlossen ist, zeigen Sie das Zertifikat, das mit dem neuen RH-SSO-Server verknüpft ist: +

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

  • Vorausgesetzt, Ihr OCP-Cluster wurde mit einem Wildcard-Zertifikat bereitgestellt, das von der LetsEncrypt-Zertifizierungsstelle unterzeichnet wurde, sollte die Antwort Folgendes enthalten:

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

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

. Wenn der OCP-Cluster mit LetsEncrypt (oder einer anderen legitimen) Zertifizierungsstelle und einem Wildcard-Zertifikat bereitgestellt wurde, können Sie die Details wie folgt anzeigen: +

$ 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" entspricht dem Zertifikat "*.apps.3295.openshift.opentlc.com"

=== RH-SSO Admin-Konsole . Öffnen Sie einen Webbrowser und navigieren Sie zur Konsole des master-Bereichs: +

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

. Melden Sie sich mit den Werten der Umgebungsvariablen $SSO_SITE_ADMIN_USERNAME und $SSO_SITE_ADMIN_PASSWORD an, die bei der Bereitstellung der RH-SSO-Instanz verwendet wurden.

. Als RH-SSO-Site-Admin haben Sie vollen Zugriff auf alle Ressourcen. + image::images/master_homepage.png[]

=== RH-SSO löschen

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

[[realm_mgmt]] == Bereich Erstellung / Löschung

RH-SSO ermöglicht die Erstellung mehrerer Bereiche. Jeder Bereich ist unabhängig von allen anderen Bereichen autonom.

Dieser Abschnitt der Installation unterstützt die automatisierte Erstellung von Bereichen für verschiedene Anwendungsfälle.

==== SMTP-Anbieter Es ist wahrscheinlich, dass Sie möchten, dass die Bereiche Ihres RH-SSO die Fähigkeit haben, E-Mails zu versenden. Als Beispiel sind die in dieser Ansible-Rolle konfigurierten generischen Bereiche für einen Benutzerregistrierungsfluss konfiguriert, der erfordert, dass der neue Benutzer die Registrierung über einen in einer E-Mail bereitgestellten Link verifiziert.

In RH-SSO werden die SMTP-Einstellungen im Rahmen eines Bereichs konfiguriert. Bei der Bereitstellung von Bereichen können Sie die folgenden Ansible-Variablen angeben:

  • smtp_host
  • smtp_userid
  • smtp_passwd

Einige SMTP-Anbieter mit kostenlosen Plänen, mit denen diese Ansible-Rolle getestet wurde, sind nachfolgend aufgeführt:

. SocketLabs: Bietet derzeit einen kostenlosen Plan an, der link:https://www.socketlabs.com/signup/[2000 E-Mails pro Monat] erlaubt. . SendGrid: Bietet derzeit einen kostenlosen Plan an, der link:https://sendgrid.com/pricing/[100 E-Mails pro Tag] erlaubt.

=== Generische Bereiche

Über dieses Ansible können eine konfigurierbare Anzahl von SSO-Bereichen basierend auf dem Wert der folgenden Variablen erstellt werden: first_generic_realm und last_generic_realm.

Wenn der Wert von last_generic_realm weniger als 1 ist, werden keine generischen Bereiche erstellt.

Der Name dieser generischen Bereiche kann angepasst werden, indem die Ansible-Variable realm_base_name überschrieben wird.

Jeder dieser SSO-Bereiche ist so eingerichtet, dass ein oder mehrere Benutzer sich als Benutzer dieses Bereichs registrieren können. Das Standardverhalten der registrierten Benutzer im Bereich besteht darin, dass sie volle Administratoren des Bereichs sind. Offensichtlich ist dieses Verhalten nur für Demos und Lernsz Szenarien angemessen.

=== KIE-Bereich Wenn beim Erstellen von Bereichen die Variable loadKieRealm auf true gesetzt wird, wird ein spezieller Bereich erstellt, der für Business- und Decision-Manager-Szenarien unterstützt wird.

. Einzelheiten zu diesem bereitgestellten kieRealm sind wie folgt:

.. realmId: kieRealm .. Login-URL: https://$rhsso_hostname/auth/admin/kieRealm/console .. Realm-Admin-Benutzer-ID: ssoRealmAdmin .. Realm-Admin-Passwort: pam .. KIE-bezogene Rollen: ... admin ... kie-server ... kiemgmt ... rest-all

. Die Einzelheiten aller Benutzer, die in diesem Bereich registriert sind, können wie folgt identifiziert werden: +

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

=== CRW-Bereich Wenn beim Erstellen von Bereichen die Variable loadCRWRealm auf true gesetzt wird, wird ein spezieller Bereich erstellt, der für Code Ready Workspaces unterstützt wird.

Einzelheiten zu diesem bereitgestellten crwRealm:

. realmId: crwRealm . Login-URL: https://$rhsso_hostname/auth/admin/crwRealm/console . Admin-Benutzer-ID: admin . Admin-Passwort: admin

=== OpenShift-Bereich

Wenn beim Erstellen von Bereichen die Variable loadOCPRealm auf true gesetzt wird, wird ein Bereich namens ocp-realm in Ihrer RH-SSO erstellt. Seine Aufgabe ist es, als link:https://access.redhat.com/documentation/en-us/red_hat_jboss_middleware_for_openshift/3/html/red_hat_single_sign-on_for_openshift/tutorials#OSE-SSO-AUTH-TUTE[Identitätsanbieter zur Authentifizierung bei OCP] zu dienen.

Die Einzelheiten dieses bereitgestellten ocp-realm sind wie folgt:

. realmId: ocp-realm . Login-URL: https://$rhsso_hostname/auth/admin/ocp-realm/console . SSO-Client: ocp-client . Admin-Benutzer-ID: gpte-mgr . Admin-Passwort: r3dh4t1! . SSO-Benutzer: Eine konfigurierbare Anzahl von Benutzern, die mit diesem Bereich verbunden sind, wird wie in den Variablen start_ocp_user und end_ocp_user erstellt. + Der Name jedes Benutzers dieses Bereichs beginnt mit dem Wert: {{ocp_realm_user_base_name}} (Standard = ocp)

. OCP-bezogene Rollen: + Keine. Rollen müssen von einem Cluster-Administrator zugewiesen werden.

Nach der Bereitstellung des ocp-realm in RH-SSO sind einige zusätzliche Schritte im Master-Knoten von OCP auszuführen. Einzelheiten zu diesen Schritten sind in: {{new_app_output_dir}}/ocp-realm-suggestion.txt aufgeführt. Im Abschnitt IdentityProvider der master-config.xml-Datei sollten Sie sicherstellen, dass der Abschnitt htpasswd mit den Einstellungen ocp-client überschrieben wird.

=== Bereiche erstellen

. Setzen Sie die folgenden Umgebungsvariablen in Ihrer Shell und führen Sie dann den Ansible-Befehl wie unten dargestellt aus: +

smtp_host= # SMTP-Anbieterdetails ermöglichen es RH-SSO, E-Mails zur Unterstützung von Funktionen wie Benutzerregistrierung zu liefern smtp_userid= smtp_passwd=

FIRST_GENERIC_REALM=1 # Der erste zu initialisierende Bereich ist: realm$FIRST_GENERIC_REALM LAST_GENERIC_REALM=1 # Der letzte zu initialisierende Bereich ist: realm$LAST_GENERIC_REALM ; wenn der Wert kleiner als 1 ist, werden keine generischen Bereiche erstellt realm_base_name=realm # Basename Ihrer generischen Bereiche. Standardmäßig: realm.

loadKieRealm=false # Standardwert ist false. Wenn true, wird ein Bereich initialisiert, der für die Unterstützung von Red Hat Process Automation und Decision Manager-Installationen verwendet wird

loadCRWRealm=false # Standardwert ist false. Wenn true, wird ein Bereich eingerichtet, der zur Unterstützung von Red Hat Code Ready Workspaces verwendet wird

crw_redirect_url="" # Nur relevant, wenn loadCRWRealm=true. Setzen Sie die URL der CodeReadyWorkspace-Route.

loadOCPRealm=true # Standardwert ist false. Wenn true, wird ein Bereich namens ocp-realm konfiguriert, der verwendet werden kann, um OCP zu konfigurieren, um RH-SSO für die Authentifizierung zu nutzen end_ocp_user=1 # Der letzte Benutzer, der im ocp-realm erstellt wird, ist: 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"

. Am Ende der Ausführung von Ansible sollten Konsolennachrichten wie die folgenden angezeigt werden: +

rh-sso-multi-realm : Bereitstellung der Bereiche abgeschlossen]

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

  • Die JSON-Darstellung jedes erstellten Bereichs finden Sie im zuvor erwähnten Verzeichnis: new_app_output_dir.

==== Bereiche löschen

$ 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"

== Generische Bereiche: Benutzerregistrierung Dieser Abschnitt des Labors geht davon aus, dass Sie bereits einen oder mehrere generische SSO-Bereiche gemäß dem Abschnitt <> dieses Labors bereitgestellt haben.

Ziel dieses Abschnitts ist es, den Studenten Anleitungen zu geben, die detailliert beschreiben, wie sie sich als Benutzer eines zuvor bereitgestellten generischen SSO-Bereichs registrieren können. Dieser gesamte Abschnitt kann in die Laboranweisungen eines Kurses eingefügt werden, der dieses multi-realm RH-SSO verwendet.

. Setzen Sie eine Umgebungsvariable, die einem bestimmten Bereich entspricht (z.B. = realm1...realm20), den Sie nutzen möchten: +

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

$ source ~/.bashrc

. Öffnen Sie einen Webbrowser und navigieren Sie zur Konsole Ihres Zielbereichs : +

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

. Klicken Sie auf den Link Registrieren: + image::images/register_link.png[]

. Füllen Sie alle Felder des Registrierungsformulars aus. Stellen Sie sicher, dass Sie eine gültige E-Mail-Adresse verwenden. . Klicken Sie auf Registrieren. . Erwarten Sie, dass Ihr Browser auf eine Seite umgeleitet wird, die darauf hinweist, dass Sie Ihre E-Mail und Ihr Konto verifizieren müssen: + image::images/email_verification.png[] . Überprüfen Sie Ihre E-Mail auf eine Bestätigungsanfrage, die ähnlich aussieht wie die folgende: + image::images/registration_email.png[]

. Klicken Sie im E-Mail auf den Link zur E-Mail-Adressverifizierung. . Ihr Browser sollte jetzt auf die Homepage Ihres Ziel-SSO-Bereichs umgeleitet werden + image::images/realm_homepage.png[] + HINWEIS: Dieser neu registrierte Bereichsbenutzer hat administrativen Zugriff auf alle Einstellungen eines Bereichs.

. In einem Terminalfenster Ihres lokalen Rechners setzen Sie Umgebungsvariablen, die spezifisch für diesen neuen Bereichsbenutzer sind: +

$ realmUserId=<ändern Sie mich> $ realmPasswd=<ändern Sie mich>

. In Ihrem Browser navigieren Sie zu den Klienten Ihres Bereichs. + Beachten Sie die Anwesenheit von 5 Standard-SSO-Klienten. Jeder von ihnen ist konfiguriert, um verschiedene OAuth2- und OIDC-Protokolle zuzulassen. + image::images/default_sso_clients.png[]

=== Generische Bereiche: Klienten erkunden

Ein Klient, im Kontext der OAuth2-Terminologie, ist eine Anwendung, die den Zugriff auf eine geschützte Ressource im Namen eines Ressourcenbesitzers anfordert. Der Ressourcenbesitzer ist typischerweise ein Endbenutzer (auch als Entität bekannt) und die geschützte Ressource könnte vertrauliche Attribute von einer oder mehreren Identitäten dieses Ressourcenbesitzers/der Entität sein.

RH-SSO ermöglicht die Erstellung benutzerdefinierter Klienten. Für die Zwecke dieses Labors verwenden Sie jedoch einen der Standard-Klienten, die mit Ihrem Bereich ausgeliefert werden.

==== Überprüfen Sie realm-management Dies ist ein Bearer-Only Klient, der später in diesem Labor mit einem gesicherten Backend-Dienst verbunden wird. Ein Bearer-Only-Klient wird für Back-End-Dienste verwendet, die sich nicht mit Red Hat SSO anmelden, aber ein gültiges ID-Token benötigen. Das ID-Token wird normalerweise von dem Backend-Dienst verwendet, um den Zugriff auf Ressourcen über rollenbasierte Zugriffskontrolle (RBAC) zu bestimmen.

==== Überprüfen Sie admin-cli

In diesem Labor definieren Sie auch einen zweiten Klienten namens admin-cli. admin-cli ist ein OAuth2-Klient. Sie verwenden admin-cli später in diesem Labor nur zu Testzwecken.

Beachten Sie, dass admin-cli aktiviert ist, um den OAuth2-Fluss namens Ressourcenbesitzer-Passwort-Anmeldedaten zu verwenden.

Über diesen Fluss ermöglicht der Klient den Austausch von Benutzer-ID- und Passwortanmeldedaten – in diesem Fall Ihren SSO-Benutzer – gegen ein Zugriffstoken. Dieses Token kann dann verwendet werden, um auf die REST-APIs Ihrer Geschäftsdienste zuzugreifen.

== Generische Bereiche: Endpunkte

=== Überblick

Ihr Red Hat SSO-Server implementiert einen Endpunkt namens well-known, der andere Endpunkte und Konfigurationsoptionen auflistet, die für die OAuth2/OpenID-Connect-Implementierung von Red Hat Single Sign-On relevant sind.

Ziel dieses Abschnitts ist es, einen Benutzer (d.h. einen Studenten) mit einigen der well-known Endpunkte der OIDC-Spezifikation vertraut zu machen. Diese well-known Endpunkte sind spezifisch für den SSO-Bereich des Benutzers.

Red Hat SSO stellt auch Endpunkte zur Verwaltungsbereichverwaltung zur Verfügung. Einige dieser Endpunkte zur Bereichsverwaltung werden in diesem Abschnitt ebenfalls eingeführt.

Dieser gesamte Abschnitt kann in die Laboranweisungen Ihres Kurses eingefügt werden.

Die folgenden Dienstprogramme müssen auf Ihrem lokalen Rechner installiert sein:

. openssl . keytool : (aus dem Java Development Kit)

=== OIDC well-known Endpunkte

. Stellen Sie sicher, dass das link:https://stedolan.github.io/jq/[jq] Dienstprogramm auf Ihrem Rechner installiert ist.

. Führen Sie Folgendes aus und studieren Sie die Antwort: +

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

. Sehen Sie sich die Liste der grant_types_supported Typen an: +

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

  • .Beispielausgabe

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

  • Diese Liste der grant_type_supported Typen entspricht den verschiedenen OAuth2/OpenID-Connect-Flows, die vom Red Hat SSO-Server unterstützt werden.

=== OAuth2 Zugriffstoken

. Stellen Sie sicher, dass die Werte der Umgebungsvariablen $rhsso_realm, $realmUserId und $realmPasswd in Ihrer Shell gesetzt sind.

. Rufen Sie das OIDC Zugriffstoken von einem Bereich ab: +

$ 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')

  • HINWEIS: Diese Antwort vom OAuth2-Tokenendpunkt könnte zusätzlich für das refresh_token geparsed werden. Das refresh_token könnte dann optional verwendet werden, um das Zugriffstoken zu aktualisieren, wenn das Zugriffstoken abläuft.

=== Öffentliche Schlüssel des Bereichs In diesem Abschnitt rufen Sie den öffentlichen Schlüssel Ihres Bereichs ab. Später kann dieser öffentliche Schlüssel in den Keycloak-Adapter aufgenommen werden, der in einen Backend-Geschäftsdienst injiziert wird. Der Backend-Dienst wird dann in der Lage sein, an einem OpenID-Connect-Fluss teilzunehmen.

. Wenn ein Bereich erstellt wird, wird automatisch ein Schlüsselpaar und ein selbstsigniertes Zertifikat generiert. + Keycloak unterstützt derzeit nur RSA-Signaturen, daher gibt es nur ein aktives Schlüsselpaar. . Setzen Sie den Wert der Umgebungsvariablen $retrieve_key_url: +

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

. Abrufen des Wertes des RSA-Schlüssels: +

$ 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

=== Optional: Sehen Sie sich das RSA-Zertifikat des Bereichs an

. Abrufen des Wertes des RSA-Zertifikats des Bereichs: +

$ 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=

. Erstellen Sie eine PEM-Datei aus dem Zertifikat: .. Setzen Sie eine Umgebungsvariable, die den Pfad zum Ziel-x.509-Zertifikat im PEM-Format definiert: +

$ realm_cert=/tmp/$rhsso_realm.pem

.. Erstellen Sie das x.509-Zertifikat im PEM-Format: +

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

. Sehen Sie sich die Einzelheiten des SSO-Realm-Zertifikats an: +

$ openssl x509 -in $realm_cert -text -noout

== Generische Bereiche: Smoke-Test OAuth2 Auth und RBAC

=== Überblick über gesicherte Geschäftsdiensten

Sehr oft benötigen Dienste Identitätsinformationen über den Endbenutzer, der deren Funktionalitäten aufruft. Ein häufiger Anwendungsfall ist die Notwendigkeit für rollenbasierte Zugriffskontrolle (RBAC). Basierend auf der Rolle des Endbenutzers bestimmt der Geschäftsdienst, ob er den Zugriff auf die angeforderte Ressource gewährt.

HINWEIS: Dieses RBAC, das vom Backend-Geschäfts Service behandelt wird, ist anders als Policy und Rate Limit Durchsetzung, die von einem API-Manager behandelt werden.

In diesem Abschnitt des Labors werden Sie die OAuth2/OIDC-Sicherheit mit einem einfachen Backend-Dienst testen, der mit link:https://thorntail.io/[Thorntail Java Microprofile] Technologie erstellt wurde.

Der Quellcode für diesen einfachen Dienst ist link:https://github.com/gpe-mw-training/3scale_onpremise_implementation_labs/tree/secure/services/wfswarm-date-service[hier] zu finden.

Damit Ihr Microprofile-Backenddienst RBAC implementieren kann, muss Folgendes geschehen:

  • RBAC-Regeln in Ihren Geschäftsdienst einfügen: Für die Zwecke dieses Labors wurde dieser Schritt bereits für Sie durchgeführt. Insbesondere beachten Sie den folgenden neuen Codeausschnitt in der Konfigurationsdatei 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]

  • Einen Keycloak-Adapter hinzufügen: Ihr Backenddienst muss mit Funktionalität injiziert werden, die es ihm ermöglicht, mit dem Red Hat SSO-Server zu kommunizieren. Insbesondere muss er den öffentlichen Schlüssel des Red Hat SSO-Servers abrufen.

  • JWT mit dem öffentlichen Schlüssel des Red Hat SSO-Bereichs entpacken: Zur Laufzeit erhält der Backendgeschäftsdienst ein JSON-Web-Token (JWT) mit Identitätsinformationen über den Endbenutzer. Diese Identitätsinformationen umfassen die Rolle des Endbenutzers. Sobald das JWT empfangen wurde, validiert der eingebettete Keycloak-Adapter die Authentizität des JWT (unter Verwendung des öffentlichen Schlüssels des Red Hat SSO-Bereichs). Sobald das JWT als von Ihrem Red Hat SSO-Server stammend überprüft wurde, verwendet der Geschäftsdienst die Identitätsinformationen, um zu entscheiden, ob der Endbenutzer die richtigen Berechtigungen hat, um auf die gewünschte Ressource zuzugreifen.

=== Bereitstellung In diesem Abschnitt werden Sie eine DeploymentConfig für einen einfachen Backendgeschäftsdienst definieren, der über das OIDC-Protokoll gesichert werden soll.

. Erstellen Sie ein neues Projekt für Ihre Mock-RESTful-Geschäftsdienstanwendungen: +

$ oc new-project $OCP_PROJECT_PREFIX-bservices
--display-name="$OCP_PROJECT_PREFIX-bservices"
--description="Geschäftsdienste, die mithilfe von OIDC gesichert werden sollen"

. Falls noch nicht vorhanden, wechseln Sie in dieses neue Projekt: +

$ oc project $OCP_PROJECT_PREFIX-bservices

. Erstellen Sie eine neue Anwendung basierend auf einem einfachen RESTful-Service, der mit Wildfly Swarm implementiert wurde: +

$ 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"

  • Dieser Befehl erstellt eine DeploymentConfig mit einem pausierten Pod. Der Pod enthält einen Java-basierten Container. Der --XmX des JVM im Container ist auf 80 % von 1 Gi eingestellt; also etwa 800 MB.

=== keycloak.json Adapter

. Definieren Sie einen Keycloak-Adapter, der auf den vorhandenen bearer-only Klienten namens: realm-management spezifisch ist : +

$ 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

. Erstellen Sie ein ConfigMap aus der keycloak.json Datei. + Sie montieren es dann als Volume und weisen WildFly Swarm auf das montierte keycloak.json hin.

.. Erstellen Sie eine ConfigMap namens date-service-rhsso im bservices Projekt auf OpenShift aus der keycloak.json Datei: +

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

.. Montieren Sie die Configmap als Volume in der Swarm DC: +

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

. Setzen Sie die pausierte Deploymentconfig fort: +

$ oc rollout resume dc/wf-swarm-oauth

. Überprüfen Sie die Protokolldatei des sicheren Wildfly-Swarm-Dienstes. Logeinträge, die ähnlich wie die folgenden aussehen sollten, erscheinen: +

DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) KeycloakServletException initialisierung DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) Verwendung von /WEB-INF/keycloak.json DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) Verwendung des Anbieters 'secret' zur Authentifizierung des Klienten 'realm-management' DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) Geladene clientCredentialsProvider-Geheimnis DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) Geladene clientCredentialsProvider jwt DEBUG [org.keycloak.adapters.KeycloakDeployment] (ServerService Thread Pool -- 11) resolveUrls DEBUG [org.keycloak.adapters.KeycloakDeploymentBuilder] (ServerService Thread Pool -- 11) Verwendung von 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: NIE DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) Keycloak nutzt eine bestimmte Konfiguration pro Bereitstellung. DEBUG [org.keycloak.adapters.wildfly.WildflyKeycloakServletExtension] (ServerService Thread Pool -- 11) Erstelle WildflyAuthenticationMechanismus DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) Cookie-Pfad jsession auf einstellen: /

... INFO [org.wildfly.swarm] (main) WFSWARM99999: WildFly Swarm ist bereit

=== Testen Sie den OIDC-gesicherten Geschäftsdienst:

. Führen Sie Folgendes aus, um ein neues Zugriffstoken zu erhalten (da das ursprüngliche Zugriffstoken wahrscheinlich jetzt abgelaufen ist): +

$ 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')

  • Technisch wäre es besser, die refresh_token Funktionalität von OAuth2 zu verwenden, anstatt ein neues Zugriffstoken zu generieren. Mit diesem Ansatz werden die Parameter grant_type=refresh_token&refresh_token=$REFRESH_TOKEN im Body der Anfrage angegeben. Der Wert von $REFRESH_TOKEN hätte durch Parsing aus der Antwort der ursprünglichen OAuth2-Tokenanforderung erhalten werden können.

. Führen Sie Folgendes aus, um den Backend-RESTful-Dienst mit dem OAuth2-Zugriffstoken aufzurufen: +

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

. Die Rückantwort sollte Header und einen Körper enthalten, die ähnlich wie die folgenden aussehen: +

...

  • TLSv1.2 (IN), TLS-Handshake, Fertig (20):
  • SSL-Verbindung mit TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
  • ALPN, Server stimmte nicht mit einem Protokoll überein
  • Serverzertifikat:
  • Subject: CN=master.3295.openshift.opentlc.com
  • Startdatum: Nov 13 20:48:38 2018 GMT
  • Ablaufdatum: Feb 11 20:48:38 2019 GMT
  • Aussteller: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
  • SSL-Zertifikatüberprüfung 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" : "Die Uhrzeit ist 2018-11-14T16:44:57.576Z"}

. Überprüfen Sie die Protokolldatei des sicheren Wildfly-Swarm-Dienstes. Logeinträge, die ähnlich wie die folgenden aussehen sollten, erscheinen: +

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) Sicherheitskontext an Wildfly übergeben DEBUG [org.keycloak.adapters.RequestAuthenticator] (default task-1) Benutzer '476cfe90-1400-4850-893f-63e5c921f261' ruft 'http://wf-swarm-oauth-jb-bservices.apps.3295.openshift.opentlc.com/time/now' auf Klient 'realm-management' DEBUG [org.keycloak.adapters.RequestAuthenticator] (default task-1) Bearer AUTENTIFIZIERT 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) Richtlinieneinhaltung ist deaktiviert. INFO [stdout] (default task-1) userId = 476cfe90-1400-4850-893f-63e5c921f261

== Anhang

=== RH-SSO-Protokoll auf DEBUG setzen (Optional)

Zu verschiedenen Zeiten möchten Sie möglicherweise die Protokollebene des Java-Pakets org.keycloak Ihres RH-SSO-Servers von INFO auf DEBUG erhöhen. Dies ist hilfreich, wenn Sie Probleme mit Sicherheitsprotokollen und RH-SSO beheben möchten.

. Öffnen Sie eine Remote-Shell-Sitzung zu Ihrem RH-SSO-Pod: +

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

. Bearbeiten Sie die Hauptkonfigurationsdatei für Ihren RH-SSO-Server: .. Öffnen Sie die Konfigurationsdatei in einem Editor: +

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

.. Suchen Sie das Feld org.jboss.as.config: +

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

.. Fügen Sie direkt unter diesem XML-Block einen ähnlichen Block wie folgt hinzu: +

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

.. Speichern Sie die Änderung und beenden Sie.

. Starten Sie die Keycloak-JVM innerhalb desselben RH-SSO-Pods neu: .. Wechseln Sie in das folgende Verzeichnis: +

cd /opt/eap/bin/

.. Führen Sie diesen Befehl aus: +

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

Über das Projekt

Red Hat Single Sign-On Multi-Realm Automated Provisioning

role identityprovider oauth2 oidc rhsso
Installieren
ansible-galaxy install gpe_mw_ansible.rh_sso_multi_realm
GitHub Repository
0 Sterne
2 Forks
8 Offene Issues
Lizenz
Unknown
Downloads
89
Besitzer
gpe-mw-ansible-org
Ansible roles to support RHT middleware labs