gpe_mw_ansible.rh_sso_multi_realm

Aperçu Versions Perspectives

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

= rh-sso-multi-realm

:numbered:

== Vue d'ensemble

Ce rôle est destiné à provisionner une installation Red Hat Single Sign-On (RH-SSO) persistante sur la plateforme OpenShift Container Platform (OCP) de Red Hat.

Il permet également la gestion (c'est-à-dire : création et suppression) d'un nombre configurable de realms SSO dans cette installation RH-SSO.

Ce rôle peut être utile dans les circonstances suivantes :

. Formation dirigée par un instructeur (ILTs), hackathons et ateliers : + Étant donné un nombre X d'étudiants dans un ILT nécessitant RH-SSO, provisionner un RH-SSO multi-realm central où chaque étudiant se voit attribuer son propre realm. + L'étudiant se voit fournir des identifiants administratifs pour son realm attribué. + Cette approche pourrait être plus souhaitable que l'alternative où chaque étudiant provisionne son propre RH-SSO.

. Activation de RH-SSO + Quelques objectifs d'apprentissage pourraient être :

.. Démontrer le provisionnement de RH-SSO sur OCP. + En particulier, la variante RH-SSO qui tire parti du lien : 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 servant des secrets de certificat x509].

.. Intégration avec un fournisseur smtp externe pour envoyer des e-mails et faciliter un processus d'auto-inscription des utilisateurs. .. Invocation de l'API admin REST de RH-SSO en utilisant des tokens access et refresh OAuth2.

REMARQUE : Ce rôle Ansible n'utilise pas encore le lien : https://github.com/keycloak/keycloak-operator[Keycloak-operator]. Principalement en raison de l'incapacité à configurer des vérifications de santé et des limites et demandes dans l'implémentation actuelle de l'opérateur comme décrit ici : https://keycloak.discourse.group/t/various-issues-with-keycloak-operator/845[ici]. La liste des jiras actuellement ouverts concernant l'opérateur est accessible : https://issues.redhat.com/browse/KEYCLOAK-13065?jql=project%20%3D%20KEYCLOAK%20AND%20component%20%3D%20%22Containers%20-%20Operator%22[ici].

=== Référence

. lien : https://www.keycloak.org/documentation.html[Documentation la plus récente sur Keycloak] . lien : 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 pour OCP] . lien : https://docs.openshift.com/container-platform/3.10/dev_guide/secrets.html#service-serving-certificate-secrets[Secrets de certificats de service OCP]

=== Hypothèses et prérequis . Assurez-vous qu'Ansible est installé sur votre machine locale. + La version d'Ansible sur laquelle ce rôle a été récemment testé est : 2.6.5-1 sur Fedora 29.

. Ce rôle Ansible suppose l'existence d'un cluster OCP distant avec un minimum de 6 Go de RAM et de 2 CPU. + La version d'OCP sur laquelle ce rôle a été récemment testé est : 3.11.43.

. Ce rôle Ansible utilise intensivement un client oc fonctionnant sur votre machine locale. Assurez-vous que ce client oc est dans le $PATH de votre environnement local et que sa version est alignée avec celle de votre environnement OCP.

. [blue]#Le client local oc doit déjà être authentifié sur l'environnement OCP distant en tant qu'utilisateur cluster-admin.#

==== Certificat Wildcard

Ce rôle Ansible suppose que votre cluster OCP préexistant est configuré avec un certificat signé par une autorité de certification légitime (comme LetsEncrypt).

REMARQUE : lien : https://github.com/redhat-gpe/mw_docs/blob/master/ocp_cluster_workshop.adoc[Les ateliers de cluster OCP] acquis du système de démonstration des partenaires Red Hat (RHPDS) et du réseau d'activation des partenaires Open de Red Hat (OPEN) sont équipés de certificats LetsEncrypt. Vous pouvez ignorer cette section.

Un très joli tutoriel sur l'acquisition d'un certificat wildcard LetsEncrypt et son application à votre cluster OCP peut être trouvé ici :

Une alternative à un certificat wildcard pour l'ensemble de votre cluster OCP pourrait simplement être de lier : https://developers.redhat.com/blog/2019/02/06/using-a-public-certificate-with-red-hat-single-sign-on-keycloak/[sécuriser la route RH-SSO avec un certificat LetsEncrypt].

== Déploiement de RH-SSO

=== Variables d'environnement

Les variables d'environnement suivantes devront être définies dans le shell de votre environnement local d'où vous exécuterez Ansible. Ces variables d'environnement seront utilisées tout au long de ce rôle.

Mettez à jour chacune des lignes suivantes puis exécutez :

echo "export OCP_PROJECT_PREFIX=" >> ~/.bashrc # Utilisé plus tard dans le lab lors de la création d'un projet OCP echo "export ocp_sso_admin_id=sso0" >> ~/.bashrc

Exécutez les lignes suivantes :

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

DNS wildcard OCP après "apps" ; c'est-à-dire ; 2345.openshift.opentlc.com

exemples :

Code Ready Containers : SUBDOMAIN_BASE=crc.testing

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

atelier 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

=== Configuration Ansible

. Installez ce rôle : +

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

  • Alternativement, vous pouvez également installer le rôle localement de la même manière :

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

. Créez un 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

=== Provisionnement de RH-SSO

L'espace de noms OCP pour l'application RH-SSO multi-realm sera détenu par l'utilisateur suivant : {{ocp_sso_admin_id}}. Un utilisateur appelé {{ocp_sso_admin_id}} sera attribué un quota de cluster afin de gérer les limites et demandes affectées à 3scale.

. Assurez-vous que l'ImageStream est dans l'espace de noms openshift : .. redhat-sso73-openshift image stream. + Exécutez la commande suivante si ce flux d'images n'existe pas dans l'espace de noms 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

. Exécutez : +

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

. Définissez une variable d'environnement qui fait référence à l'URL du RH-SSO nouvellement provisionné : +

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

. Une fois le provisionnement terminé, consultez le certificat associé au nouveau serveur RH-SSO : +

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

  • En supposant que votre cluster OCP a été provisionné en utilisant un certificat wildcard signé par l'autorité de certification LetsEncrypt, la réponse devrait inclure ce qui suit :

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

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

. Si le cluster OCP a été provisionné en utilisant LetsEncrypt (ou une autre Autorité de Certification légitime) et a été délivré un certificat wildcard, vous pouvez voir les détails comme suit : +

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

...

  • subjectAltName: hôte "sso-rhsso-sso0.apps.3295.openshift.opentlc.com" correspondant au certificat "*.apps.3295.openshift.opentlc.com"

=== Console Admin RH-SSO . Ouvrez un navigateur Web et accédez à la console du realm master : +

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

. Authentifiez-vous en utilisant les valeurs des variables d'environnement $SSO_SITE_ADMIN_USERNAME et $SSO_SITE_ADMIN_PASSWORD utilisées lors du provisionnement de l'instance RH-SSO.

. En tant qu'administrateur du site RH-SSO, vous avez un accès complet à toutes ses ressources. + image::images/master_homepage.png[]

=== Supprimer RH-SSO

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

[[realm_mgmt]] == Création / Suppression de Realm

RH-SSO permet de créer plusieurs realms. Chaque realm est totalement autonome par rapport aux autres realms.

Cette section de l'installation aide à la création automatisée de realms pour divers cas d'utilisation.

==== Fournisseurs SMTP Il est probable que vous souhaitiez que les realms de votre RH-SSO puissent envoyer des e-mails. Par exemple, les generic realms configurés dans ce rôle Ansible sont configurés pour un processus d'inscription des utilisateurs qui nécessite que le nouvel utilisateur vérifie son inscription via un lien fourni dans un e-mail.

Dans RH-SSO, les paramètres smtp sont configurés dans le cadre d'un realm. Lorsque vous provisionnez des realms, vous pouvez spécifier les variables Ansible suivantes :

  • smtp_host
  • smtp_userid
  • smtp_passwd

Quelques fournisseurs SMTP avec plans gratuits avec lesquels ce rôle Ansible a été testé sont listés ci-dessous :

. SocketLabs : Offre actuellement un plan gratuit permettant de lien: https://www.socketlabs.com/signup/[2000 e-mails par mois]. . SendGrid : Offre actuellement un plan gratuit permettant de lien: https://sendgrid.com/pricing/[100 e-mails par jour].

=== Generic Realms

Grâce à cet Ansible, un nombre configurable de realms SSO peut être créé en fonction de la valeur des variables suivantes : first_generic_realm et last_generic_realm.

Si la valeur de last_generic_realm est inférieure à 1, aucun generic realm ne sera créé.

Le nom de ces generic realms peut être personnalisé en redéfinissant la variable Ansible : realm_base_name.

Chacun de ces realms SSO est activé pour permettre à un ou plusieurs utilisateurs de s'inscrire en tant qu'utilisateur de ce realm. Le comportement par défaut des utilisateurs inscrits dans le realm est qu'ils sont des administrateurs complets du realm. Évidemment, ce comportement est approprié uniquement pour les scénarios de démonstration et d'apprentissage.

=== KIE Realm Si lors de la création des realms, la variable loadKieRealm est définie sur true, alors un realm spécial spécifique au support des scénarios Business et Decision Manager sera créé.

. Les détails de ce kieRealm provisionné sont les suivants :

.. realmId : kieRealm .. Login URL : https://$rhsso_hostname/auth/admin/kieRealm/console .. Realm Admin User Id : ssoRealmAdmin .. Realm Admin Passwd : pam .. Rôles liés à KIE : ... admin ... kie-server ... kiemgmt ... rest-all

. Les détails de tous les utilisateurs enregistrés avec ce realm peuvent être identifiés comme suit : +

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

=== CRW Realm Si lors de la création des realms, la variable loadCRWRealm est définie sur true, alors un realm spécial spécifique au support des Code Ready Workspaces sera créé.

Détails de ce crwRealm provisionné :

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

=== OpenShift Realm

Si lors de la création des realms, la variable loadOCPRealm est définie sur true, alors un realm appelé ocp-realm sera créé dans votre RH-SSO. Son objectif est de servir de lien : 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[IdentityProvider pour l'authentification à OCP].

Les détails de ce ocp-realm provisionné sont les suivants :

. 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! . Utilisateurs SSO : Un nombre configurable d'utilisateurs associés à ce realm est créé selon les variables : start_ocp_user et end_ocp_user + Le nom de chaque utilisateur de ce realm commencera par la valeur : {{ocp_realm_user_base_name}} (défaut = ocp).

. Rôles liés à OCP : + Aucun. Les rôles doivent être assignés par un administrateur de cluster.

Après le provisionnement de ocp-realm dans RH-SSO, quelques étapes supplémentaires doivent être exécutées dans le nœud principal de OCP. Les détails concernant ces étapes sont décrits dans : {{new_app_output_dir}}/ocp-realm-suggestion.txt. Dans la section IdentityProvider du fichier master-config.xml, n'oubliez pas de remplacer la section htpasswd par les paramètres ocp-client.

=== Créer des Realms

. Définissez les variables d'environnement suivantes dans votre shell puis exécutez la commande Ansible indiquée ci-dessous : +

smtp_host= # Détails du fournisseur SMTP permettant à RH-SSO de livrer des e-mails pour des fonctionnalités comme l'inscription des utilisateurs smtp_userid= smtp_passwd=

FIRST_GENERIC_REALM=1 # le premier realm à être initialisé sera : realm$FIRST_GENERIC_REALM LAST_GENERIC_REALM=1 # le dernier realm à être initialisé sera : realm$LAST_GENERIC_REALM ; si la valeur est inférieure à 1, alors aucun generic realm ne sera créé realm_base_name=realm # nom de base de vos generic realms. Défaut : realm.

loadKieRealm=false # le défaut est false. Si true, alors un realm sera initialisé pour supporter les installations Red Hat Process Automation et Decision Manager.

loadCRWRealm=false # le défaut est false. Si true, alors un realm sera initialisé pour supporter les Red Hat Code Ready Workspaces.

crw_redirect_url="" # Seulement applicable si loadCRWRealm=true. Définissez l'URL de la route CodeReadyWorkspace.

loadOCPRealm=true # le défaut est false. Si true, alors il configurera un realm appelé ocp-realm qui peut être utilisé pour configurer OCP afin de tirer parti de RH-SSO pour l'authentification. end_ocp_user=1 # le dernier utilisateur à être créé dans ocp-realm sera : 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"

. À la fin de l'exécution d'Ansible, des messages de la console tels que ceux-ci devraient apparaître : +

rh-sso-multi-realm : Déploiement des Realms terminé]

ok: [localhost] => { "msg": [ "create_realms: true", "new_app_output_dir: /home/jbride/provisioning_output/3295.openshift.opentlc.com", "début et fin des realms = 1 25" ] }

  • La représentation json de chaque realm créé peut être trouvée dans le répertoire mentionné comme : new_app_output_dir.

==== Supprimer des Realms

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

== Generic Realms : Inscription des Utilisateurs Cette section du lab suppose que vous avez déjà provisionné un ou plusieurs generic SSO realms selon la section <> de ce lab.

Le but de cette section est de fournir aux étudiants des instructions détaillant comment s'inscrire en tant qu'utilisateur d'un generic SSO realm précédemment provisionné. Toute cette section peut être copiée et collée dans les instructions du lab d'un cours utilisant ce RH-SSO multi-realm.

. Définissez une variable d'environnement qui correspond à un realm spécifique (ex. = realm1...realm20) que vous souhaitez utiliser : +

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

$ source ~/.bashrc

. Ouvrez un navigateur Web et accédez à la console de votre realm cible : +

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

. Cliquez sur le lien Register : + image::images/register_link.png[]

. Remplissez tous les champs du formulaire d'inscription. Assurez-vous d'utiliser un e-mail valide. . Cliquez sur Register. . Attendez-vous à ce que votre navigateur soit redirigé vers une page indiquant qu'il est nécessaire de vérifier votre e-mail et votre compte : + image::images/email_verification.png[] . Vérifiez votre e-mail pour une demande de vérification similaire à ce qui suit : + image::images/registration_email.png[]

. Dans l'e-mail, cliquez sur le lien pour la vérification de l'adresse e-mail. . Votre navigateur devrait maintenant être redirigé vers la page d'accueil de votre realm SSO cible : + image::images/realm_homepage.png[] + REMARQUE : Cet utilisateur de realm nouvellement inscrit a un accès administratif à tous les paramètres d'un realm.

. Dans une fenêtre de terminal de votre machine locale, définissez des variables d'environnement spécifiques à ce nouvel utilisateur de realm : +

$ realmUserId= $ realmPasswd=

. Dans votre navigateur, accédez aux Clients de votre realm. + Remarquez la présence de 5 clients SSO par défaut. Chacun d'eux est configuré pour autoriser différents protocoles OAuth2 et OIDC. + image::images/default_sso_clients.png[]

=== Generic Realms : Explorer les Clients

Un client, dans le contexte de la terminologie OAuth2, est une application demandant un accès à une ressource protégée au nom d'un propriétaire de ressource. Le propriétaire de ressource est généralement un utilisateur final (également connu sous le nom d'entité) et la ressource protégée pourrait être des attributs confidentiels d'une ou plusieurs identités de ce propriétaire d'entité.

RH-SSO permet la création de clients personnalisés. Pour les besoins de ce lab, cependant, vous utiliserez l'un des clients par défaut qui sont fournis avec votre realm.

==== Revue de realm-management C'est un client bearer-only qui sera affilié à un service backend sécurisé dans une section ultérieure de ce lab. Un client bearer-only est utilisé pour des services backend qui n'initient pas une connexion avec Red Hat SSO, mais nécessitent un token ID valide. Le token ID est généralement utilisé par le service backend pour déterminer l'accès aux ressources via le contrôle d'accès basé sur les rôles (RBAC).

==== Revue de admin-cli

Dans ce lab, vous définissez également un deuxième client appelé admin-cli. admin-cli est un client OAuth2. Vous utilisez admin-cli plus tard dans ce lab uniquement à des fins de test.

Notez que admin-cli est activé pour utiliser le flux OAuth2 appelé Resource Owner Password Credentials.

Grâce à ce flux, le client permet d'échanger les identifiants utilisateur et mot de passe – dans ce cas, votre utilisateur SSO – contre un token d'accès. Ce token peut ensuite être utilisé pour accéder aux API REST de vos services métiers.

== Generic Realms : Points de terminaison

=== Vue d'ensemble

Votre serveur Red Hat SSO implémente un point de terminaison appelé well-known qui répertorie d'autres points de terminaison et options de configuration pertinentes à l'implémentation OAuth2/OpenID Connect de Red Hat Single Sign-On.

Le but de cette section est d'exposer un utilisateur (c'est-à-dire un étudiant) à certains des points de terminaison well-known de la spécification OIDC. Ces points de terminaison well-known sont spécifiques au realm SSO de l'utilisateur.

Red Hat SSO expose également des points de terminaison d'administration de realm. Quelques-uns de ces points de terminaison d'administration de realm sont également introduits dans cette section.

Cette section entière peut être copiée et collée dans les instructions de lab de votre cours.

Les utilitaires suivants devront être installés sur votre machine locale :

. openssl . keytool : (du kit de développement Java)

=== Points de terminaison OIDC bien connus

. Assurez-vous que l'utilitaire lien : https://stedolan.github.io/jq/[jq] est installé sur votre machine.

. Exécutez la commande suivante et étudiez la réponse : +

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

. Affichez la liste des types grant_types_supported : +

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

  • .Exemple de sortie

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

  • Cette liste des types grant_type_supported correspond aux différents flux OAuth2/OpenID Connect pris en charge par le serveur Red Hat SSO.

=== Token d'accès OAuth2

. Assurez-vous que les valeurs des variables d'environnement $rhsso_realm, $realmUserId et $realmPasswd sont définies dans votre shell.

. Récupérer le token d'accès OIDC d'un 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')

  • REMARQUE : Cette réponse du point de terminaison token OAuth2 pourrait également être analysée pour le refresh_token. Le refresh_token pourrait ensuite être utilisé pour rafraîchir le token d'accès lorsque le token d'accès expire.

=== Clé publique du Realm Dans cette section, vous récupérerez la clé publique de votre realm. Plus tard, cette clé publique peut être incluse dans l'adaptateur keycloak qui est injecté dans un service métier backend. Le service backend pourra alors participer à un flux OpenID Connect.

. Lorsqu'un realm est créé, une paire de clés et un certificat auto-signé sont automatiquement générés. + Keycloak ne prend actuellement en charge que les signatures RSA, il n'y a donc qu'une seule paire de clés active. . Définissez la valeur de la variable d'environnement $retrieve_key_url : +

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

. Récupérer la valeur de la clé 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

=== Optionnel : Voir le certificat RSA du Realm

. Récupérer la valeur du certificat RSA du 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=

. Créez un fichier PEM à partir du certificat : .. Définissez une variable d'environnement qui définit le chemin du certificat x.509 au format PEM : +

$ realm_cert=/tmp/$rhsso_realm.pem

.. Créez un certificat x.509 au format PEM : +

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

. Voir les détails du certificat SSO Realm : +

$ openssl x509 -in $realm_cert -text -noout

== Generic Realms : Test de sécurité OAuth2 Auth et RBAC

=== Vue d'ensemble du service métier sécurisé

Très souvent, les services ont besoin d'informations d'identité sur l'utilisateur final invoquant sa fonctionnalité. Un cas d'utilisation courant est le besoin de contrôle d'accès basé sur les rôles (RBAC). En fonction du rôle de l'utilisateur final, le service métier détermine s'il doit accorder l'accès à la ressource invoquée.

REMARQUE : Ce RBAC géré par le service métier backend est différent de l'application policy et rate limit qui est gérée par un gestionnaire d'API.

Dans cette section du lab, vous allez tester la sécurité OAuth2/OIDC à l'aide d'un simple service backend écrit avec la technologie de lien : https://thorntail.io/[Thorntail Java Microprofile].

Le code source de ce service simple se trouve lien : https://github.com/gpe-mw-training/3scale_onpremise_implementation_labs/tree/secure/services/wfswarm-date-service[ici].

Afin que votre service backend microprofile mette en œuvre le RBAC, il faut que ceci se produise :

  • Tisser des règles RBAC dans votre service métier : Pour les besoins de ce lab, cette étape a déjà été réalisée pour vous. En particulier, notez le nouvel extrait de code suivant dans le fichier de configuration src/main/resources/project-defaults.yml :

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

  • Ajouter un adaptateur Keycloak : Votre service backend doit être injecté avec une fonctionnalité lui permettant de communiquer avec le serveur RH-SSO. En particulier, il doit récupérer la clé publique du realm du serveur RH-SSO.

  • Décompresser le JWT à l'aide de la clé publique du realm Red Hat SSO : Au moment de l'exécution, le service métier backend reçoit un token JSON Web Token (JWT) avec des informations d'identité sur l'utilisateur final. Ces informations d'identité incluent le rôle de l'utilisateur final. Une fois le JWT reçu, l'adaptateur Keycloak intégré valide l'authenticité du JWT (en utilisant la clé publique du realm RH-SSO). Une fois que le JWT est vérifié comme ayant été émis par votre serveur RH-SSO, le service métier utilise les informations d'identité pour décider si l'utilisateur final a les bonnes identifiants pour accéder à la ressource désirée.

=== Déploiement Dans cette section, vous allez définir un DeploymentConfig pour un simple service métier backend qui sera sécurisé via le protocole OIDC.

. Créez un nouveau projet pour vos applications de services RESTful fictives : +

$ oc new-project $OCP_PROJECT_PREFIX-bservices
--display-name="$OCP_PROJECT_PREFIX-bservices"
--description="Services métiers à sécuriser à l'aide de l'OIDC"

. Si ce n'est pas déjà fait, passez à ce nouveau projet : +

$ oc project $OCP_PROJECT_PREFIX-bservices

. Créez une nouvelle application basée sur un simple service RESTful mis en œuvre à l'aide de 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"

  • Cette commande crée une configuration de déploiement avec un pod mis en pause. Le pod inclut un conteneur basé sur Java. Le --XmX de la JVM dans le conteneur est réglé à 80 % de 1Gi ; soit environ 800 Mo.

=== Adaptateur keycloak.json

. Définissez un adaptateur keycloak spécifique au client bearer-only existant appelé : 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

. Créez un ConfigMap à partir du fichier keycloak.json. + Vous le montez ensuite en tant que volume et pointez WildFly Swarm vers le keycloak.json monté.

.. Créez un ConfigMap appelé date-service-rhsso dans le projet bservices sur OpenShift à partir du fichier keycloak.json : +

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

.. Montez le ConfigMap en tant que volume dans le 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

. Reprenez le déploiement configuré mis en pause : +

$ oc rollout resume dc/wf-swarm-oauth

. Examinez le journal du service sécurisé Wildfly Swarm. Des déclarations de log similaires à celles-ci devraient apparaître : +

DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) Exception d'initialisation de KeycloakServlet DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) utilisant /WEB-INF/keycloak.json DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) Utilisation du fournisseur 'secret' pour l'authentification du client 'realm-management' DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) Secret clientCredentialsProvider chargé DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) jwt clientCredentialsProvider chargé DEBUG [org.keycloak.adapters.KeycloakDeployment] (ServerService Thread Pool -- 11) resolveUrls DEBUG [org.keycloak.adapters.KeycloakDeploymentBuilder] (ServerService Thread Pool -- 11) Utilisation de 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 : JAMAIS DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) Keycloak utilise une configuration par déploiement. DEBUG [org.keycloak.adapters.wildfly.WildflyKeycloakServletExtension] (ServerService Thread Pool -- 11) création de WildflyAuthenticationMechanism DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) Définition du chemin de cookie jsession à : /

... INFO [org.wildfly.swarm] (main) WFSWARM99999 : WildFly Swarm est prêt

=== Tester le service métier sécurisé avec OIDC :

. Exécutez la commande suivante pour acquérir un nouveau token d'accès (puisque le token d'accès original est probablement expiré maintenant) : +

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

  • Techniquement, la meilleure approche serait d'utiliser la fonctionnalité refresh_token d'OAuth2 plutôt que de régénérer un nouveau token d'accès. Avec cette approche, les paramètres grant_type=refresh_token&refresh_token=$REFRESH_TOKEN sont spécifiés dans le corps de la demande. La valeur de $REFRESH_TOKEN aurait pu être acquise en l'analysant à partir de la réponse de la demande originale de tokens OAuth2.

. Exécutez la commande suivante pour invoquer le service RESTful backend en utilisant le token d'accès OAUTH2 : +

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

. La réponse devrait inclure des en-têtes et un corps similaires à ce qui suit : +

...

  • TLSv1.2 (IN), négociation TLS, terminé (20) :
  • Connexion SSL utilisant TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
  • ALPN, le serveur n'a pas accepté un protocole
  • Certificat du serveur :
  • sujet : CN=master.3295.openshift.opentlc.com
  • date de début : 13 nov 20:48:38 2018 GMT
  • date d'expiration : 11 févr 20:48:38 2019 GMT
  • émetteur : C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
  • Vérification du certificat SSL OK.

    GET /time/now HTTP/1.1 Hôte : 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"}

. Examinez le journal du service sécurisé Wildfly Swarm. Des déclarations de log similaires à celles-ci devraient apparaître : +

DEBUG [org.keycloak.adapters.PreAuthActionsHandler] (default task-1) requête admin http://wf-swarm-oauth-jb-bservices.apps.3295.openshift.opentlc.com/time/now DEBUG [org.keycloak.adapters.wildfly.WildflyRequestAuthenticator] (default task-1) propagation du contexte de sécurité vers wildfly DEBUG [org.keycloak.adapters.RequestAuthenticator] (default task-1) Utilisateur '476cfe90-1400-4850-893f-63e5c921f261' invoquant 'http://wf-swarm-oauth-jb-bservices.apps.3295.openshift.opentlc.com/time/now' sur le client 'realm-management' DEBUG [org.keycloak.adapters.RequestAuthenticator] (default task-1) Bearer AUTHENTIFIÉ 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) L'application des politiques est désactivée. INFO [stdout] (default task-1) userId = 476cfe90-1400-4850-893f-63e5c921f261

== Annexe

=== Définir le log RH-SSO sur DEBUG (Optionnel)

Parfois, vous voudrez peut-être augmenter le niveau de log du paquet java org.keycloak de votre serveur RH-SSO de INFO à DEBUG. Cela peut être bénéfique lorsqu'on essaie de résoudre des problèmes liés aux protocoles de sécurité et à RH-SSO.

. Ouvrez une session shell distante vers votre pod RH-SSO : +

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

. Modifiez le fichier de configuration principal de votre serveur RH-SSO : .. Ouvrez le fichier de configuration dans un éditeur : +

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

.. Recherchez le champ org.jboss.as.config : +

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

.. Juste en dessous de ce bloc XML, ajoutez un bloc similaire comme suit : +

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

.. Enregistrez le changement et sortez.

. Redémarrez la JVM Keycloak dans le même pod RH-SSO : .. Changez de répertoire vers celui-ci : +

cd /opt/eap/bin/

.. Exécutez cette commande : +

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

À propos du projet

Red Hat Single Sign-On Multi-Realm Automated Provisioning

role identityprovider oauth2 oidc rhsso
Installer
ansible-galaxy install gpe_mw_ansible.rh_sso_multi_realm
GitHub référentiel
0 étoiles
2 forks
8 problèmes ouverts
Licence
Unknown
Téléchargements
89
Propriétaire
gpe-mw-ansible-org
Ansible roles to support RHT middleware labs