gpe_mw_ansible.rh_sso_multi_realm

Descripción general Versiones Perspectivas

Sure! Here is a simplified translation of your text into Spanish:

= rh-sso-multi-realm

== Resumen

Este rol está destinado a provisionar una instalación persistente de Red Hat Single Sign-On (RH-SSO) en la Plataforma de Contenedores OpenShift de Red Hat (OCP).

También permite la gestión (es decir, creación y eliminación) de un número configurable de realms en esa instalación de RH-SSO.

Este rol puede ser valioso en las siguientes circunstancias:

. Capacitación dirigida por instructores (ILTs), hackatones y talleres: + Dado un número X de estudiantes en un ILT que requieren RH-SSO, provisionar un RH-SSO centralizado con múltiples realms donde cada estudiante tenga su propio realm. + Se proporciona al estudiante credenciales administrativas para su realm asignado. + Este enfoque podría ser más deseable que la alternativa donde cada estudiante provisiona su propio RH-SSO.

. Habilitación de RH-SSO + Algunos objetivos de aprendizaje pueden ser:

.. Demostrar el aprovisionamiento de RH-SSO en OCP. + En particular, la variante de RH-SSO que aprovecha los secretos de certificados x509 en OCP.

.. Integración con un proveedor SMTP externo para enviar correos electrónicos y facilitar un flujo de auto-registro de usuarios. .. Invocación de la API REST Admin de RH-SSO utilizando tokens access y refresh con OAuth2.

NOTA: Este rol de Ansible aún no utiliza el [Keycloak-operator]. Principalmente debido a la incapacidad de configurar verificaciones de salud y límites en la implementación actual del operador. La lista de Jiras abiertos relacionados con el operador está [aquí].

=== Referencia

. Última documentación de keycloak . RH-SSO para OCP . Secretos de Certificados de Servicio OCP

=== Supuestos y Requisitos Previos . Asegúrese de que Ansible esté instalado en su máquina local. + La versión más reciente de Ansible que ha sido probada en este rol es: 2.6.5-1 en Fedora 29.

. Este rol de Ansible supone la existencia de un clúster OCP remoto con un mínimo de 6 GB de RAM y 2 CPUs. + La versión de OCP que este rol de Ansible ha sido probada es: 3.11.43.

. Este rol de Ansible utiliza en gran medida un cliente oc que se ejecuta en su máquina local. Asegúrese de que este cliente oc esté en el $PATH de su ambiente local y que su versión se alinee con la de su ambiente OCP.

. El cliente oc local deberá estar autenticado previamente en el ambiente OCP remoto como un usuario cluster-admin.

==== Certificado Wildcard

Este rol de Ansible supone que su clúster OCP existente está configurado con un certificado firmado por una Autoridad de Certificación legítima (como LetsEncrypt).

NOTA: Los talleres de clúster OCP adquiridos del Sistema de Demostración de Socios de Red Hat (RHPDS) y de la Red de Habilitación de Socios Abiertos de Red Hat (OPEN) vienen equipados con certificados LetsEncrypt. Puede omitir esta sección.

Un tutorial muy bueno sobre cómo adquirir un certificado wildcard de LetsEncrypt y aplicarlo a su clúster OCP se puede encontrar aquí:

Hey Tate: Cómo comprar un nombre de dominio para certificados SSL válidos en sus sistemas de desarrollo. ** Cómo comprar ** Documento
Hey Tate: Crear certificado SSL wildcard válido para su dominio de forma gratuita con certbot! ** Crear certificado ** Documento
Hey Tate: Ejecutar OpenShift y rutas localmente con un certificado SSL válido. ** Ejecutar OpenShift ** Documento

Una alternativa a un certificado wildcard para su clúster OCP podría ser asegurar la ruta RH-SSO con un certificado de LetsEncrypt.

== Despliegue de RH-SSO

=== Variables de entorno

Las siguientes variables de entorno deberán configurarse en el shell de su entorno local desde donde se ejecutará Ansible. Estas variables se usarán a lo largo de este rol.

Actualice cada uno de lo siguiente y luego ejecútelo:

echo "export OCP_PROJECT_PREFIX=" >> ~/.bashrc # Usado más tarde en el laboratorio al crear un proyecto OCP echo "export ocp_sso_admin_id=sso0" >> ~/.bashrc

Ejecute lo siguiente:

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 de OCP después de "apps"; es decir, 2345.openshift.opentlc.com

ejemplos:

Code Ready Containers: SUBDOMAIN_BASE=crc.testing

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

taller de 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

=== Configuración de Ansible

. Instale este rol: +

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

Alternativamente, también puede instalar el rol localmente de la misma manera:

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

. Crea el 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

=== Provisionar RH-SSO

El namespace OCP para la aplicación RH-SSO multi-realm será de la siguiente propiedad: {{ocp_sso_admin_id}}. Un usuario llamado {{ocp_sso_admin_id}} se le asignará un clusterquota para gestionar límites y solicitudes asignadas a 3scale.

. Asegúrese de que ImageStream esté en el namespace openshift: .. redhat-sso73-openshift stream de imágenes. + Ejecute lo siguiente si este stream de imágenes no existe en el namespace 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

. Ejecute: +

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

. Establezca una variable de entorno que haga referencia a la URL del nuevo RH-SSO provisionado: +

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

. Una vez que la provisión haya terminado, vea el certificado asociado al nuevo servidor RH-SSO: +

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

Suponiendo que su clúster OCP fue provisionado usando un certificado wildcard firmado por la Autoridad de Certificación LetsEncrypt, la respuesta debería incluir lo siguiente:

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

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

. Si el clúster OCP ha sido provisionado usando LetsEncrypt (u otra Autoridad de Certificación legítima) y se ha emitido un certificado wildcard, puede ver los detalles de la siguiente manera: +

$ 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" coincidiendo con el certificado "*.apps.3295.openshift.opentlc.com"

=== Consola Admin de RH-SSO . Abra un navegador web y navegue a la consola del realm master : +

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

. Autenticarse usando los valores de las variables de entorno $SSO_SITE_ADMIN_USERNAME y $SSO_SITE_ADMIN_PASSWORD que se utilizaron al provisionar la instancia de RH-SSO.

. Como administrador del sitio RH-SSO, tiene acceso total a todos sus recursos. + imagen::images/master_homepage.png[]

=== Eliminar RH-SSO

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

[[realm_mgmt]] == Creación / Eliminación de Realms

RH-SSO permite la creación de múltiples realms. Cada realm es completamente autónomo de todos los demás realms.

Esta sección de la instalación ayuda en la creación automatizada de realms para diversos casos de uso.

==== Proveedores SMTP Es probable que desee que los realms de su RH-SSO tengan la capacidad de enviar correos electrónicos. Como ejemplo, los realms genéricos configurados como parte de este rol de Ansible están configurados para un flujo de registro de usuarios que requiere que el nuevo usuario verifique el registro mediante un enlace proporcionado en un correo electrónico.

En RH-SSO, la configuración SMTP se realiza dentro del ámbito de un realm. Al provisionar realms, puede especificar las siguientes variables de Ansible:

smtp_host
smtp_userid
smtp_passwd

Algunos proveedores SMTP con Planes Gratuitos que este rol de Ansible ha probado se listan a continuación:

. SocketLabs: Actualmente ofreciendo un plan gratuito que permite [2000 correos electrónicos por mes]. . SendGrid: Actualmente ofreciendo un plan gratuito que permite [100 correos electrónicos por día].

=== Realms Genéricos

A través de este Ansible, se pueden crear un número configurable de realms SSO según el valor de las siguientes variables: first_generic_realm y last_generic_realm.

Si el valor de last_generic_realm es menor a 1, entonces no se crearán realms genéricos.

Se puede personalizar el nombre de estos realms genéricos sobrescribiendo la variable de Ansible: realm_base_name.

Cada uno de estos realms SSO está habilitado para permitir que uno o más usuarios se registren como usuarios de este realm. Por defecto, el comportamiento de los usuarios registrados en el realm es que son administradores completos del realm. Obviamente, este comportamiento es apropiado solo para escenarios de demostración y aprendizaje.

=== Realm KIE Si al crear realms la variable loadKieRealm se establece en verdadero, entonces se creará un realm especial específico para apoyar escenarios de Business y Decision Manager.

. Los detalles de este kieRealm provisionado son los siguientes:

.. realmId: kieRealm .. URL de inicio de sesión: https://$rhsso_hostname/auth/admin/kieRealm/console .. ID de Usuario Admin del Realm: ssoRealmAdmin .. Contraseña Admin del Realm: pam .. Roles relacionados con KIE: ... admin ... kie-server ... kiemgmt ... rest-all

. Los detalles de todos los usuarios registrados en este realm se pueden identificar de la siguiente manera: +

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

=== Realm CRW Si al crear realms la variable loadCRWRealm se establece en verdadero, entonces se creará un realm especial específico para apoyar los Code Ready Workspaces.

Detalles de este crwRealm provisionado

. realmId: crwRealm . URL de inicio de sesión: https://$rhsso_hostname/auth/admin/crwRealm/console . ID de Usuario Admin: admin . Contraseña Admin: admin

=== Realm OpenShift

Si al crear realms la variable loadOCPRealm se establece en verdadero, entonces se creará un realm llamado ocp-realm en su RH-SSO. Su propósito es servir como un [Proveedor de Identidad para autenticación a OCP].

Detalles de este ocp-realm provisionado son los siguientes:

. realmId: ocp-realm . URL de inicio de sesión: https://$rhsso_hostname/auth/admin/ocp-realm/console . Cliente SSO: ocp-client . ID de Usuario Admin: gpte-mgr . Contraseña Admin: r3dh4t1! . Usuarios SSO: Número configurable de usuarios asociados con este realm son creados conforme a las variables: start_ocp_user y end_ocp_user + El nombre de cada usuario de este realm comenzará con el valor: {{ocp_realm_user_base_name}} (predeterminado = ocp)

. Roles relacionados con OCP: + Ninguno. Los roles deben ser asignados por un administrador del clúster.

Después del aprovisionamiento del ocp-realm en RH-SSO, hay algunos pasos adicionales que ejecutar en el nodo maestro de OCP. Los detalles sobre estos pasos se detallan en: {{new_app_output_dir}}/ocp-realm-suggestion.txt. En la sección IdentityProvider del archivo master-config.xml, recuerde sobrescribir la sección htpasswd con la configuración del ocp-client.

=== Crear Realms

. Establezca las siguientes variables de entorno en su shell y luego ejecute el comando Ansible como se indica a continuación: +

smtp_host= # Los detalles del proveedor SMTP permiten que RH-SSO entregue correos en apoyo de funcionalidades como el Registro de Usuario smtp_userid= smtp_passwd=

FIRST_GENERIC_REALM=1 # el primer realm a inicializar será: realm$FIRST_GENERIC_REALM LAST_GENERIC_REALM=1 # el último realm a inicializar será: realm$LAST_GENERIC_REALM ; si el valor es menor a 1, entonces no se crearán realms genéricos realm_base_name=realm # nombre base de sus realms genéricos. El predeterminado es simplemente: realm.

loadKieRealm=false # el predeterminado es falso. Si es verdadero, entonces se inicializará un realm utilizado para soportar Red Hat Process Automation y Decision Manager

loadCRWRealm=false # el predeterminado es falso. Si es verdadero, entonces se inicializará un realm para soportar Red Hat Code Ready Workspaces

crw_redirect_url="" # Solo aplicable si loadCRWRealm=true. Establecer en la URL de la ruta de CodeReadyWorkspace.

loadOCPRealm=true # el predeterminado es falso. Si es verdadero, entonces se configurará un realm llamado ocp-realm que puede ser utilizado para configurar OCP para aprovechar RH-SSO para autenticación end_ocp_user=1 # el último usuario que se creará en el ocp-realm será: 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"

. Al finalizar la ejecución de Ansible, los mensajes en la consola serán como los siguientes: +

rh-sso-multi-realm : Implementación de Realm Completa]

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

La representación JSON de cada realm creado se puede encontrar en el directorio mencionado como: new_app_output_dir.

==== Eliminar 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"

== Realms Genéricos: Registro de Usuario Esta sección del laboratorio asume que ya ha provisionado uno o más realms SSO genéricos según la sección <> de este laboratorio.

El propósito de esta sección es proporcionar instrucciones a los estudiantes sobre cómo registrarse como usuario de un realm SSO genérico previamente provisionado. Esta sección completa se puede copiar y pegar en las instrucciones del laboratorio de un curso que aproveche este RH-SSO multi-realm.

. Establezca una variable de entorno que corresponda a un realm específico (por ejemplo, = realm1...realm20) que desea utilizar: +

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

$ source ~/.bashrc

. Abra un navegador y navegue a la consola de su realm objetivo: +

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

. Haga clic en el enlace Registrar: + imagen::images/register_link.png[]

. Complete todos los campos del formulario de registro. Asegúrese de usar un correo electrónico válido. . Haga clic en Registrar. . Espere que su navegador sea redirigido a una página que indique la necesidad de verificar su correo electrónico y cuenta: + imagen::images/email_verification.png[] . Verifique su correo electrónico en busca de una solicitud de verificación similar a la siguiente: + imagen::images/registration_email.png[]

. En el correo electrónico, haga clic en el enlace para verificación de correo electrónico. . Su navegador ahora debería ser redirigido a la página de inicio de su realm SSO objetivo. + imagen::images/realm_homepage.png[] + NOTA: Este nuevo usuario registrado en el realm tiene acceso administrativo a todos los ajustes de un realm.

. En una ventana de terminal de su máquina local, establezca variables de entorno específicas para este nuevo usuario de realm: +

$ realmUserId=<cámbielo> $ realmPasswd=<cámbielo>

. En su navegador, navegue a los Clientes de su realm. + Observe la presencia de 5 clientes SSO predeterminados. Cada uno está configurado para permitir diferentes protocolos OAuth2 y OIDC. + imagen::images/default_sso_clients.png[]

=== Realms Genéricos: Explorar Clientes

Un cliente, en el contexto de la terminología OAuth2, es una aplicación que solicita acceso a un recurso protegido en nombre de un Propietario de Recurso. El Propietario de Recurso es típicamente un usuario final (también conocido como una entidad) y el recurso protegido puede ser atributos confidenciales de una o más identidades de ese Propietario de Recurso/entidad.

RH-SSO permite la creación de clientes personalizados. Sin embargo, para el propósito de este laboratorio, utilizaremos uno de los clientes predeterminados que vienen con su realm.

==== Revisar realm-management Este es un cliente bearer-only que estará afiliado a un servicio backend seguro en una sección posterior de este laboratorio. Un cliente bearer-only se utiliza para servicios de backend que no inician un inicio de sesión con Red Hat SSO, pero requieren un token de ID válido. El token de ID se utiliza típicamente por el servicio de backend para determinar el acceso a recursos a través del control de acceso basado en roles (RBAC).

==== Revisar admin-cli

En este laboratorio, también se define un segundo cliente llamado admin-cli. admin-cli es un cliente OAuth2. Utilizará admin-cli más adelante en este laboratorio solo para fines de prueba.

Tenga en cuenta que admin-cli está habilitado para utilizar el flujo OAuth2 llamado Resource Owner Password Credentials.

A través de este flujo, el cliente permite intercambiar ID de usuario y credenciales de contraseña--en este caso, su usuario SSO--por un token de acceso. Este token se puede utilizar para acceder a las APIs REST de sus servicios de negocio.

== Realms Genéricos: Puntos finales

=== Resumen

Su servidor Red Hat SSO implementa un punto final llamado well-known que enumera otros puntos finales y opciones de configuración relevantes para la implementación de OAuth2/OpenID Connect de Red Hat Single Sign-On.

El propósito de esta sección es exponer a un usuario (es decir, un estudiante) a algunos de los puntos finales well-known de la especificación OIDC. Estos puntos finales well-known son específicos para el realm SSO del usuario.

Red Hat SSO también expone puntos finales de administración de realms. Algunos de estos puntos finales de administración de realms también se introducen en esta sección.

Toda esta sección se puede copiar y pegar en las instrucciones del laboratorio de su curso.

Las siguientes utilidades deberán estar instaladas en su máquina local:

. openssl . keytool: (del Kit de Desarrollo de Java)

=== Puntos finales OIDC bien conocidos

. Asegúrese de que la utilidad jq esté instalada en su máquina.

. Ejecute lo siguiente y estudie la respuesta: +

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

Los diversos clientes de Partido de Confianza de OpenID invocan estos puntos finales de Red Hat SSO en el resto de este laboratorio.
Dos puntos finales son de particular interés: ** Punto final de Autorización ** Punto final de Token

. Vea la lista de tipos grant_types_supported: +

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

Ejemplo de Salida

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

Esta lista de tipos de grant_type_supported corresponde a los diversos flujos de OAuth2/OpenID Connect que son soportados por el servidor Red Hat SSO.

=== Token de Acceso OAuth2

. Asegúrese de que los valores de las variables de entorno $rhsso_realm, $realmUserId y $realmPasswd estén configurados en su shell.

. Recupere el Token de Acceso OIDC de 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')

NOTA: Esta respuesta del punto final de token OAuth2 podría adicionalmente analizarse para obtener el refresh_token. El refresh_token podría usarse opcionalmente para refrescar el token de acceso cuando el token de acceso expire.

=== Clave Pública del Realm En esta sección, usted recuperará la clave pública de su realm. Más adelante, esta clave pública puede ser incluida en el adaptador de keycloak que se inyecte en un servicio de negocio backend. El servicio backend podrá participar en un flujo OpenID Connect.

. Cuando se crea un realm, se genera automáticamente un par de claves y un certificado autofirmado. + Keycloak actualmente solo soporta firmas RSA, por lo que solo hay un par de claves activo. . Establezca el valor de la variable de entorno $retrieve_key_url: +

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

. Recupere el valor de la clave 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 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE...

=== Opcional: Ver Certificado RSA del Realm

. Recupere el valor del Certificado RSA del Realm: +

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

$ echo $RSA_CERT MIICuTCCAaECBgFcJ85oAjANBgkqhkiG9w0BAQsFADAg...

. Cree un archivo PEM a partir del certificado: .. Establezca una variable de entorno que defina la ruta al certificado x.509 en formato PEM: +

$ realm_cert=/tmp/$rhsso_realm.pem

.. Cree el certificado x.509 en formato PEM: +

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

. Verifique los detalles del certificado del Realm SSO: +

$ openssl x509 -in $realm_cert -text -noout

== Realms Genéricos: Prueba de humo de la Autenticación OAuth2 y RBAC

=== Resumen del servicio de negocio seguro

A menudo, los servicios necesitan información de identidad sobre el usuario final que invoca su funcionalidad. Un caso de uso común es la necesidad de control de acceso basado en roles (RBAC). Según el rol del usuario final, el servicio de negocio determina si debe otorgar acceso al recurso que se invoca.

NOTA: Este RBAC manejado por el servicio de negocio backend es diferente de la aplicación de política y límite de tasa que es manejada por un Gestor de API.

En esta sección del laboratorio, probará la seguridad de OAuth2/OIDC usando un sencillo servicio backend escrito con la tecnología [Thorntail Java Microprofile].

El código fuente para este servicio simple se encuentra aquí.

Para que su servicio backend de microprofile implemente RBAC, se deben realizar las siguientes acciones:

Tejer reglas RBAC en su servicio de negocio: Para los propósitos de este laboratorio, este paso ya ha sido hecho para usted. En particular, observe el siguiente nuevo fragmento de código en el archivo de configuración 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]

Agregar un adaptador Keycloak: Su servicio de negocio necesita ser inyectado con funcionalidades que le permitan comunicarse con el servidor Red Hat SSO. En particular, necesita obtener la clave pública del realm del servidor Red Hat SSO.
Desempacar JWT utilizando la clave pública del realm de Red Hat SSO: En tiempo de ejecución, el servicio de negocio recibe un Token de ID JSON Web (JWT) con información de identidad sobre el usuario final. Esta información de identidad incluye el rol del usuario final. Una vez que se recibe el JWT, el adaptador Keycloak embebido valida la autenticidad del JWT (usando la clave pública del realm de Red Hat SSO). Una vez que el JWT se verifica que ha originado de su servidor Red Hat SSO, el servicio de negocios utiliza la información de identidad para decidir si el usuario final tiene las credenciales correctas para acceder al recurso deseado.

=== Despliegue En esta sección, definirá un DeploymentConfig para un sencillo servicio de negocio backend que se asegurará a través del protocolo OIDC.

. Cree un nuevo proyecto para sus aplicaciones de servicios de negocio RESTful simuladas: +

$ oc new-project $OCP_PROJECT_PREFIX-bservices
--display-name="$OCP_PROJECT_PREFIX-bservices"
--description="Servicios de Negocios que serán asegurados usando OIDC"

. Si aún no está allí, cambie a este nuevo proyecto: +

$ oc project $OCP_PROJECT_PREFIX-bservices

. Cree una nueva aplicación basada en un sencillo servicio RESTful implementado usando 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"

Este comando crea una configuración de despliegue con un pod pausado. El pod incluye un contenedor basado en Java. El --XmX de la JVM en el contenedor se establece en el 80% de 1Gi; por lo que aproximadamente 800 MB.

=== Adaptador keycloak.json

. Defina un adaptador keycloak específico para el cliente bearer-only existente llamado: 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

. Cree un ConfigMap desde el archivo keycloak.json. + Luego lo monta como un volumen y apunta WildFly Swarm al keycloak.json montado.

.. Cree un ConfigMap llamado date-service-rhsso en el proyecto bservices en OpenShift desde el archivo keycloak.json: +

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

.. Monte el configmap como un volumen en el 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

. Reanude la configuración de despliegue pausada: +

$ oc rollout resume dc/wf-swarm-oauth

. Revise el archivo de registro del servicio seguro wildfly swarm. Deberían aparecer declaraciones de registro similares a las siguientes: +

DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) Inicialización de KeycloakServletException DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) utilizando /WEB-INF/keycloak.json DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) Usando proveedor 'secreto' para la autenticación del cliente 'realm-management' DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) Proveedor de clientCredentialsProvider cargado DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) Proveedor de jwt de clientCredentialsProvider cargado DEBUG [org.keycloak.adapters.KeycloakDeployment] (ServerService Thread Pool -- 11) resolveUrls DEBUG [org.keycloak.adapters.KeycloakDeploymentBuilder] (ServerService Thread Pool -- 11) Usa 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: NUNCA DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) Keycloak está usando una configuración por despliegue. DEBUG [org.keycloak.adapters.wildfly.WildflyKeycloakServletExtension] (ServerService Thread Pool -- 11) creando WildflyAuthenticationMechanism DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) Configurando la cookie jsession en: /

... INFO [org.wildfly.swarm] (main) WFSWARM99999: WildFly Swarm está listo

=== Probar el servicio de negocio seguro OIDC:

. Ejecute lo siguiente para adquirir un nuevo token de acceso (ya que probablemente el token de acceso original ha expirado): +

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

Técnicamente, un mejor enfoque sería usar la función refresh_token de OAuth2 en lugar de regenerar un nuevo token de acceso. Con este enfoque, los parámetros grant_type=refresh_token&refresh_token=$REFRESH_TOKEN se especifican en el cuerpo de la solicitud. El valor de $REFRESH_TOKEN podría haberse adquirido analizando la respuesta de la solicitud original para obtener tokens OAuth2.

. Ejecute lo siguiente para invocar el servicio RESTful backend utilizando el token de acceso OAUTH2: +

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

. La respuesta debería incluir encabezados y un cuerpo similar a lo siguiente: +

...

TLSv1.2 (IN), Finalización del Handshake TLS (20):
Conexión SSL usando TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
ALPN, el servidor no acordó un protocolo
Certificado del servidor:
subject: CN=master.3295.openshift.opentlc.com
fecha de inicio: Nov 13 20:48:38 2018 GMT
fecha de expiración: Feb 11 20:48:38 2019 GMT
issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
verificación de certificado SSL 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" : "La hora es 2018-11-14T16:44:57.576Z"}

. Revise el archivo de registro del servicio seguro wildfly swarm. Declaraciones de registro similares a las siguientes deberían aparecer: +

DEBUG [org.keycloak.adapters.PreAuthActionsHandler] (default task-1) httpRequest de admin http://wf-swarm-oauth-jb-bservices.apps.3295.openshift.opentlc.com/time/now DEBUG [org.keycloak.adapters.wildfly.WildflyRequestAuthenticator] (default task-1) propagar el contexto de seguridad a wildfly DEBUG [org.keycloak.adapters.RequestAuthenticator] (default task-1) Usuario '476cfe90-1400-4850-893f-63e5c921f261' invocando 'http://wf-swarm-oauth-jb-bservices.apps.3295.openshift.opentlc.com/time/now' en el cliente 'realm-management' DEBUG [org.keycloak.adapters.RequestAuthenticator] (default task-1) Bearer AUTENTICADO 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) Se desactiva la aplicación de políticas. INFO [stdout] (default task-1) userId = 476cfe90-1400-4850-893f-63e5c921f261

== Apéndice

=== Establecer el Log de RH-SSO en DEBUG (Opcional)

A veces, puede que desee aumentar el nivel de log del paquete java org.keycloak de su servidor RH-SSO de INFO a DEBUG. Hacer esto es beneficioso al intentar resolver problemas con protocolos de seguridad y RH-SSO.

. Abra una sesión de shell remota en su pod RH-SSO: +

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

. Edite el archivo de configuración principal de su servidor RH-SSO: .. Abra el archivo de configuración en un editor: +

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

.. Busque el campo org.jboss.as.config: +

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

.. Justo debajo de este bloque XML, agregue un bloque similar como el siguiente: +

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

.. Guarde el cambio y salga.

. Reinicie la JVM de keycloak dentro del mismo pod RH-SSO: .. Cambie al siguiente directorio: +

cd /opt/eap/bin/

.. Ejecute este comando: +

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

Espero que esta traducción sea útil y clara para ti. Si necesitas más ayuda, no dudes en preguntar.

Acerca del proyecto

Red Hat Single Sign-On Multi-Realm Automated Provisioning

role identityprovider oauth2 oidc rhsso

Instalar

ansible-galaxy install gpe_mw_ansible.rh_sso_multi_realm

GitHub repositorio

0 estrellas

2 bifurcaciones

8 problemas abiertos

Licencia

Unknown

Descargas

Propietario

gpe-mw-ansible-org

Ansible roles to support RHT middleware labs