Y luego regresemos, no en Grecia, discutiremos a un alto nivel una descripción general sobre el salmón.
Así que Salmon significa el lenguaje de marcado de la Asociación de Seguridad y es un mecanismo de
comunicación seguro basado en XML para comunicar las identidades entre las organizaciones.
Ahora, este punto se entenderá mejor en un momento aquí.
Entonces, el salmón elimina la necesidad de mantener múltiples credenciales de autenticación, como contraseñas en
múltiples ubicaciones.
Entonces, si observa la forma clásica en la que tiene múltiples aplicaciones y servicios que se
ejecutan dentro de su organización y cada aplicación tiene sus propias identidades.
Entonces Jenkins tiene su propio nombre de usuario y contraseña.
El editor tiene su propio nombre de usuario y contraseña en términos de H. R. El software de gestión tendrá su propio nombre
de usuario y contraseña, etc.
Así que tener estos es un poco molesto.
Así que analicemos algunos de los desafíos de la manera clásica que estábamos discutiendo.
El primero es que el administrador no tiene realmente la visibilidad con la base de datos subyacente
del proveedor SAS.
Así que actualmente estábamos discutiendo sobre JENKINS '.
Entonces, si está alojando un Jenkins dentro de su propio servicio, entonces tiene una buena cantidad de visibilidad.
Pero hay muchos proveedores de servicios que realmente no le brindan ninguna visibilidad de la base de datos.
Y, de hecho, se ha visto que muchos de los lugares donde se almacenan los nombres de
usuario y las contraseñas subyacentes al almacenamiento en texto sin formato e incluso las grandes organizaciones están involucrados aquí.
Entonces este es un gran desafío.
El segundo desafío es que si hay varios proveedores de SaaS, es difícil hacer un seguimiento de qué
usuario tiene acceso a qué aplicación SaaS.
Entonces puede suceder que el desarrollador tenga acceso a Jenkins.
Sin embargo, el desarrollador, Steve, tiene acceso a la base de datos y todos los usuarios tienen acceso a ella.
Entonces, al final, si un determinado usuario está abandonando la organización, es difícil saber que el usuario tiene acceso a
esta aplicación, específicamente si usted tiene tal vez una aplicación dentro de su organización.
Y ese es el tercer punto, que cuando el usuario abandona la organización, necesita ser eliminado
de todas las entidades.
Puede ser Jenkins, ET, etc. etcétera.
Así que aún recuerdo eso en la organización con la que he estado trabajando para que cualquier usuario que
esté saliendo de la organización en su último día se le ocurra un formulario y necesite la firma de la autoridad.
Entonces, por ejemplo, él tiene acceso a una VPN y entonces vino a nuestro equipo y le quitamos el acceso y luego lo firmamos
en el documento, que tendrá que enviar a la API.
Entonces, en tales casos, tendrá que tomar una firma de todos que digan que su usuario y su acceso
se eliminan y Post enviará ese formulario a la ATO.
Entonces, en las organizaciones que realmente no tienen un inicio de sesión único para hacer tales cosas, es un poco molesto porque
ahora tendrá que eliminar su acceso manualmente de todas las aplicaciones.
Así que veamos las diferentes vistas aquí en un enfoque clásico.
Entonces, la visión de los administradores en el enfoque clásico aquí es que tendrá que iniciar sesión en un proveedor
diferente para administrar y controlar el permiso de un usuario individual en toda la organización.
Y en caso de que haya olvidado su nombre de usuario y contraseña y tal vez haya perdido este para
Amethi, el administrador tendrá que configurar el nuevo MFA en todas las aplicaciones.
Así que esto es un poco molesto.
En segundo lugar, la vista de los usuarios La vista de los usuarios es que tendrá que recordar la contraseña de todas las aplicaciones
dentro de la organización.
Y también puede estar presente que el uso de la idea del usuario en las aplicaciones es diferente.
Entonces, esto es más abierto y la vista más amplia del sitio en caso de que el proveedor de servicios, si está almacenando el nombre
de usuario y la contraseña, el proveedor de servicios tendrá que mantener la base de datos de nombre de usuario y contraseña
de sus clientes.
Y en caso de que se filtre esta base de datos, entonces es una gran responsabilidad de seguridad de este aspirador.
Entonces, en la vista clásica, el administrador, el usuario, así como el sur de Florida, no todos están contentos.
Así que ahora viene la mejor forma, que es la misma.
Entonces, en resumen, lo que tiene, tiene un proveedor de identidad y tiene un proveedor de servicios, Banzet.
Entonces, el proveedor de servicios puede ser de Jenkins, puede ser EWR, puede ser una configuración, etc.
Y el proveedor de identidad es el que almacenará todas las identidades.
Entonces, en lugar de que todas las identidades se almacenen en un proveedor de servicios, trasladamos esa identidad al sitio del proveedor
de identidades.
Así que echemos un vistazo al diagrama de flujo de trabajo donde tiene el proveedor de identidad, todo lo que es.
Y el proveedor de servicios de ADP.
Entonces, lo que sucederá aquí es el uso de su primer inicio de sesión en el proveedor de identidad,
el proveedor de identidad verificará si las credenciales son correctas y se dirá una respuesta.
Por lo tanto, el usuario enviará esa respuesta al proveedor de servicios y al proveedor de servicios.
Si la respuesta es la esperada, se redireccionará al consultor de gestión.
Por lo tanto, recuerde que para que el proveedor de servicios acepte esta respuesta, debe existir una confianza
entre el proveedor de identidad y el proveedor de servicios, que se habría establecido antes de que
todo este proceso funcione.
Así que esto es lo que es el samawi.
Y esta respuesta también puede denominarse esta afirmación de Samael.
Así que veamos el nivel alto más o menos, el flujo se inicia cuando el usuario abre el ADP preocupado y hace el nombre
de usuario y la contraseña y selecciona la aplicación adecuada o para que la aplicación pueda ser una jenkins
con bordes y así sucesivamente.
Por lo tanto, el proveedor de identidad validará las credenciales y los permisos asociados y luego los usará, recibirá
una afirmación de Samit de la parte de la respuesta del IDP.
Entonces, ya sabes, estábamos discutiendo esta respuesta.
Esta es básicamente esta afirmación de Samin que recibe el usuario.
Entonces, una vez que el usuario ha recibido esta afirmación, el usuario realiza la mayor parte de esa afirmación
de Samin en la página de firma de origen y el proveedor de servicios validará esas afirmaciones en la validación.
El proveedor de servicios creará las credenciales temporales relevantes y también creará una autorización de firma para la consola
y la enviará de vuelta al usuario.
Así que ese es el nivel alto en el que, ya sabes, veamos rápidamente una demostración para que se comprenda
mejor.
Ahora, el primer paso que estamos discutiendo es que el usuario deberá enviar un nombre de usuario y una contraseña
al proveedor de identidad.
Por lo tanto, serían una preocupación, algo similar a esto, y sería necesario enviar el nombre de usuario y la contraseña
del usuario.
Así que intentémoslo en la cuadrícula.
Entonces la autenticación ha sido exitosa.
Ahora, si miras aquí, una vez que la autenticación sea exitosa, el usuario tendrá que
seleccionar la aplicación apropiada porque puede haber múltiples aplicaciones que estarían presentes.
Entonces puede ser una base de datos, puede ser de jenkins, puede ser de otras.
Entonces, dependiendo de la aplicación, debido a que el proveedor de servicios te cambia todo, tienes un proveedor de servicios
de W. S. Jenkins, etc.
Entonces esto es importante.
Entonces, lo que sucederá es que dependiendo del proveedor de servicios que elija el usuario, se dirá la afirmación
adecuada de Samin.
Así que probémoslo.
Entonces, tan pronto como hago clic en la consola de administración que está actualmente en funcionamiento,
ves que es Stammen y básicamente está iniciando sesión y verifica y estás conectado a la cuenta.
Así que entre bastidores ha sucedido algo.
Al igual que ha recibido la afirmación del salmón, la Asociación del salmón se remitió al proveedor de servicios.
El proveedor de servicios había validado ese salmón, como dije, y lo agregaría redireccionado a la consola de
administración.
Así que hagamos una cosa para entenderlo mejor.
Tengo un prensador dominical instalado dentro de mi equipo y lo usamos para ver qué sucede exactamente detrás de escena para comprender este
proceso en una descripción general de alto nivel.
Está bien.
Entonces, lo primero que estábamos discutiendo es que el usuario hará clic en la consola de administración.
Entonces te está registrando y tú estás registrando.
Entonces vamos.
Y.
Así que ahora déjame maximizar.
Entonces, lo primero aquí es básicamente que se está realizando la solicitud de puerta.
Así que esta es la solicitud de puerta que se está haciendo a la ISS aquí.
Ahora, si miras aquí, también hay una publicación ahora, ya que estábamos discutiendo que una vez que se reciba
esta afirmación, la publicación se enviará al proveedor de servicios.
Entonces, si miras esta solicitud de publicación específica, esta publicación ha sido enviada a esta página de firma de Dawe
con salmón.
Así que recuerde que Eatables tiene una oficina separada para autenticar si está utilizando salmón.
Entonces, esta es el área exacta en la que necesitará hundir su afirmación de salmón, como estaba discutiendo una
vez que recibió una afirmación de salmón.
Esa afirmación debe enviarse a un en específico en el caso de un dispositivo.
Es esta Eweida.
Entonces aquí es donde está sucediendo la publicación.
Y si miras el salmón, esta es la afirmación del salmón, que se está enviando a, ya
sabes, si bajas a.
Hay una pequeña lectura que está entrando y dentro de esta redirección, si observa la ubicación, esta es
la ubicación que está siendo compartida por AWB.
De manera similar a lo que estamos discutiendo, se está enviando una solución similar al proveedor de
servicios, el proveedor de servicios verificará y luego enviará una redirección a la consola de administración.
Y eso es lo que ha estado sucediendo.
Así que esa es la descripción general de alto nivel sobre Simon.
Y también analizamos cómo los proveedores individuales de Sinon pueden hacer uso de Samin para seguir adelante y permitir que los usuarios se
conecten a un proveedor de servicios específico para que esto concluya este video.
Espero que este video te haya resultado informativo.
Y espero verte en el próximo video.