¿Cómo estás?
Y bienvenido de nuevo.
Ahora, en el video de hoy, discutiremos sobre el concepto de federación.
Ahora, antes de continuar y analizarlo con más detalle, tomemos un caso de uso
simple para comprender el desafío que enfrentan muchos millones y la mayoría de las organizaciones a gran escala.
Así que supongamos que hay 500 usuarios dentro de su organización, y esta organización está utilizando tres servicios
principales de forma activa.
El primero es la ayuda, al menos para infraestructura.
El segundo es Jenkins y el tercero es la aplicación relacionada con la edad.
Y su función es básicamente dar acceso a los usuarios a los tres servicios.
Así que supongamos que todos los usuarios, los 500 usuarios dentro de la organización necesitan tener
acceso a estos tres sistemas.
Ahora, uno de los desafíos que veremos primero es que tendrá que crear usuarios individuales en
todos estos tres sistemas.
Entonces, en cualquiera de las listas, deberá crear un usuario de IAM en el sistema de administración de VIH.
De nuevo, tendrás que crear un usuario y así sucesivamente.
Así que ahora digamos que un nuevo usuario se unió a su organización o que un nuevo usuario abandona su organización.
Básicamente, tendrá que iniciar sesión en estas tres aplicaciones para agregar o eliminar usuarios.
Ahora, supongamos que hay dos nuevas aplicaciones que están llegando a la organización.
Esencialmente, de nuevo, tendrá que agregar los 500 usuarios a los próximos dos nuevos sistemas que se están
planificando.
Así que esta no es realmente una forma muy eficiente de hacer las cosas.
Entonces, este es uno de los desafíos que realmente enfrentará en la organización de mediana a gran escala.
Específicamente, cuando habla sobre organizaciones a gran escala que tienen miles de usuarios, en tal caso,
no se recomienda administrar los usuarios en todos y cada uno de los sistemas, así como la identidad.
Entonces, para superar esto, básicamente lo que se usa en el sistema es almacenar el centro de usuario.
Así que digamos que tienes un sistema.
Entonces, en esta aplicación antigua, tiene almacenadas todas las identidades de los usuarios.
Entonces, todo el nombre de usuario y todas las contraseñas se almacenan en este directorio del centro.
Y este único directorio está conectado con todos los sistemas de forma que los usuarios del centro directamente pueden
iniciar sesión con el nombre de usuario y la contraseña de estos tres sistemas.
Entonces, esto se convierte en una arquitectura mucho más eficiente porque solo habrá un único conjunto de
nombre de usuario y contraseña que se almacenará en el nivel final y desde el final.
Dado que habrá confianza entre todos estos sistemas, el usuario puede iniciar sesión fácilmente.
Entonces, cada vez que un nuevo usuario se une a la organización, todo lo que el administrador debe hacer, debe agregar
su usuario como parte de la aplicación anterior, y eso es todo.
Podrá iniciar sesión en estos tres sistemas y quizás mañana se planee agregar un nuevo sistema
en su organización.
Todo lo que tendrá que hacer es confiar entre su aplicación anterior y ese nuevo sistema y todos los
usuarios existentes también podrán iniciar sesión en los nuevos sistemas.
Ahora, hay muchas soluciones que nos permiten almacenar el usuario de forma centralizada.
Uno de los principales que quizás haya escuchado es Microsoft Active Directory.
Esta es una solución muy popular que le permite almacenar el centro de usuarios y también le permite tener
una gestión ordenada.
El segundo popular específicamente para Linux es Red Hat Identity Management, también conocido como una aplicación
gratuita.
Entonces, si observa la captura de pantalla, esto está asociado con Active Directory y ve que
hay varios usuarios que se han agregado aquí y la edición del orden del usuario es muy simple.
Verá que puede hacer clic en Nuevo y puede hacer clic en usuario y se agregará un nuevo usuario a su Active Directory.
Así que ahora digamos que tiene Active Directory y tiene estos tres sistemas.
Lo que debe hacer, debe confiar entre su Active Directory y estos tres sistemas
de tal manera que los usuarios que forman parte de su Active Directory puedan iniciar sesión en
estos tres sistemas según la política que ha establecido.
Estupendo.
Entonces, con esto, avancemos y entendamos los conceptos básicos de la federación desde una perspectiva idealista.
Básicamente, la federación permite que las identidades externas, también conocidas como usuarios federados, tengan acceso seguro
a una cuenta de comestibles interna sin tener que crear ningún usuario.
Entonces, ya hemos discutido que las identidades no se almacenan en un lugar, estas se
almacenan en un servidor central como Active Directory y todos estos usuarios podrán iniciar sesión en su cuenta.
Así que esto es lo que el concepto de Federación realmente entra en escena.
Por lo tanto, estas identidades externas pueden provenir de varias fuentes, como el proveedor de identidad corporativa que puede
ser Active Directory IPA, proveedor de identidad web.
Facebook.
Google.
Amazonas.
Incógnito o abierto, según el caso de uso que desee lograr.
Ahora veamos rápidamente el flujo de trabajo de alto nivel cuando hablemos sobre la federación.
Así que hay tres entidades principales que están involucradas.
El primero es el usuario.
El segundo es el proveedor de servicios y el tercero es el proveedor de identidad.
Ningún proveedor de servicios es básicamente estas aplicaciones del lado derecho de las que hablábamos, como Jenkins EAW es
un sistema de gestión de datos, etc.
Además, estos son los proveedores que brindan algunos servicios.
Entonces tienes un proveedor de identidad del propio nombre.
Podemos identificar qué hace exactamente esto.
Esto proporciona identidad.
Básicamente, eso significa que los usuarios se almacenan en el nivel del proveedor de identidad y que el proveedor de servicios
y el proveedor de identidad tienen una relación de confianza entre ambos.
Por lo tanto, este proveedor de servicios confía en el proveedor de identidad y, por lo tanto, los usuarios
que provienen de este proveedor de identidad podrán iniciar sesión en el proveedor de servicios según las políticas que haya
establecido.
Bien.
Entonces, si observa el diagrama, el usuario primero se autentica con el proveedor de identidad.
No se autentica con un proveedor de servicios.
Básicamente, esto significa que digamos que este flujo de trabajo es el de EWR.
Entonces es un proveedor de servicios y hay un proveedor de identidad como Okta.
Entonces los usuarios se almacenarán en el nivel de octanaje.
Los usuarios no se almacenarán a nivel de base de datos.
Entonces, el usuario primero se autenticará con el proveedor de identidad.
Ahora, dado que existe una relación, una relación de confianza entre el IDP y el
proveedor de servicios, el usuario, una vez que se autentique con éxito con el proveedor de identidad, podrá
realizar una solicitud exitosa al proveedor de servicios de EWR.
Entonces, con esto, avancemos y entendamos rápidamente las cosas con más detalle.
Primero, un concepto importante aquí es el agente de identidad.
Entonces, el agente de identidad es un servicio intermedio que conecta a múltiples proveedores aquí.
Entonces, bajo identidad, tienes un idlis.
En el lado izquierdo, tiene un Directorio Activo que tiene todos los nombres de usuario y contraseñas
de todos los empleados de su organización.
¿Entonces qué quieres?
Desea intimidar al servicio que puede conectar ambos.
Así que esto es lo que se conoce como intermediario de identidad.
Así que sigamos adelante y veamos el video de trabajo.
En el lado derecho, tiene el lugar, en el lado izquierdo tiene el Directorio Activo y aún
en su lugar.
Entonces, primero los usuarios deberán iniciar sesión en el agente de identidad.
Entonces, este agente de identidad está conectado a Microsoft Active Directory.
Entonces, básicamente, ¿qué nombre de usuario y contraseña que el usuario proporcionó al agente de identidad coinciden con
los que están almacenados en Active Directory?
Así que aquí es donde realmente se lleva a cabo la autenticación.
El primer paso es iniciar sesión.
El segundo paso es autenticar al usuario con Active Directory.
Una vez que la autenticación es exitosa, este agente de identidad seguirá adelante y llamará al servicio
Aspear y recibe un token específico y luego el agente de identidad envía la respuesta adecuada al
cliente.
Y este token es lo que se utilizó nuevamente para conectarse a los servicios web de Amazon.
Entonces, cuando discutimos sobre este autor, este es el token.
Esto no es más que un conjunto de claves secretas y de acceso.
Por lo tanto, se proporcionan claves secretas y de acceso a los usuarios, y los usuarios pueden usar esas claves secretas de acceso
para conectarse al EWG.
Creo que este es el flujo de trabajo de alto nivel sobre cómo funcionarían las cosas desde un punto de vista federado.
Así que sigamos adelante y revisemos rápidamente los pasos.
Primero, los usuarios inician sesión con el nombre de usuario y la contraseña, y estas credenciales se entregan al
agente de identidad.
Ahora Identity Broker valida estas credenciales contra Active Directory.
En este ejemplo, hemos tomado Active Directory.
Si las credenciales son válidas.
Básicamente, si el nombre de usuario y la contraseña son válidos, el corredor se pondrá en contacto con el servicio SDR, ya que
este seguirá adelante y le devolverá la seguridad de acceso.
Y esta clave secreta de acceso será proporcionada por el intermediario de identidad al usuario y el usuario podrá iniciar sesión en la
consola de la base de datos o de forma segura utilizando este conjunto de claves secretas de acceso junto con el
token específico, que tiene una duración específica.
Entonces, si no puede recordar cuando discutimos sobre identidades, identidades, nada más que los usuarios.
Entonces, cuando discutimos nuestras identidades externas, eso básicamente significa que los usuarios están almacenados en un
sistema externo, no en IEM.
El segundo es el intermediario de identidad, que es básicamente un software intermedio que lleva al usuario desde el punto y lo ayuda
a conectarse al punto B.
Y el tercer concepto importante es la identidad almacenada, que es básicamente un lugar donde están los usuarios, pero
como se almacenan otros usuarios.
Entonces Active Directory o IP o quizás Facebook.
Así que estos son básicamente la identidad almacenada.
Ahora, antes de concluir, cosas muy importantes que quería compartir.
La primera es que para que la Federación funcione, este proveedor de servicios también debe admitir esa funcionalidad porque,
en última instancia, estábamos discutiendo una.
El proveedor de identidad almacenará las identidades y existirá una relación de confianza entre la identidad proporcionada y también la
del proveedor del servicio.
Ahora bien, si el proveedor de servicios realmente no admite esa funcionalidad en absoluto, entonces realmente no puede
tener una federación.
Así que esta es una parte importante para recordar.
Ahora, cuando discutimos sobre Idlis, cuando va a la consola de IAM, tiene una opción específica de la
del proveedor de identidad.
Así que aquí es donde puede continuar y agregar múltiples proveedores de identidad.
Entonces, en el menú de identidad de Gordon, tendrá que especificar básicamente un tipo de proveedor, así como el documento de
metadatos de su proveedor de identidad.
Entonces, por ejemplo, supongamos que ha elegido el proveedor de identidad de OCTA.
Entonces, OCTA es una plataforma de proveedor de identidad muy popular.
Entonces, este documento de metadatos que estábamos discutiendo, proviene de OCTA.
Entonces, después de haber configurado los ajustes de solicitud en OCTA, puede continuar y cargar este documento
de metadatos después de haberlo descargado de OCTA.
Y así es como en una auditoría de alto nivel, la confianza realmente sucede entre un proveedor de servicios
y el proveedor de identidad.
Así que esta es una parte.
La segunda cosa que también discutimos, tomemos un ejemplo de Jenkins.
Vayamos rápidamente a Manager Jenkins y configuremos la seguridad global.
Entonces, básicamente, lo que estamos discutiendo en estas cuentas se basa en cómo los datos del usuario se almacenan centralmente
en un laboratorio, debería poder iniciar sesión en una aplicación específica como Jenkins.
Ahora bien, si Jenkins no lanza o instala eso, entonces todo este concepto realmente no funcionará.
Por lo tanto, Jenkins también deberá admitir un punto de vista específico de LDAP.
Entonces, si va a la configuración de Jenkins en URI, básicamente tiene dos opciones importantes.
El primero es la propia base de datos de usuarios de Jenkins.
Básicamente, eso significa que cada vez que agrega un usuario, lo agrega a la base de datos de Jenkins y también tiene la
opción de permitir que el usuario diga, no, este es uno.
Ahora veamos, como estamos discutiendo, realmente no desea crear el usuario individualmente en un sistema
individual.
¿Qué quieres?
¿Quieres terminar?
Así que también tiene una opción para un tablero aquí, y dentro de él tendrá que proporcionar los detalles de la palabra del
episodio final.
Entonces, una vez que tenga ese servidor, proporcione los detalles al de Jenkins, y una vez que tenga la configuración
necesaria, los usuarios que forman parte de un LDAP podrán iniciar sesión en el audio de Jenkins.
Derecha.
Así que esta es la descripción general de alto nivel.
En caso de que esto sea algo que realmente te interese, entonces Okta es una plataforma popular que puedes
probar.
También tienen múltiples certificaciones asociadas, que son bastante buenas.
Así que esto es algo que puede esperar hacer.
Esa es la descripción general de alto nivel sobre la Federación.
Y con esto concluirá el vídeo de hoy.