Single sign on spanish - guía completa
1 recomendación901 vistas
El documento presenta una guía completa sobre el mecanismo de Single Sign-On (SSO) utilizado por Google, describiendo su funcionamiento, los roles implicados, y los estándares como SAML y OAuth2. Se detalla cómo Google Apps se integra como proveedor de servicios y de identidad, así como las herramientas y soluciones de control de acceso recomendadas para implementar SSO eficazmente. Además, incluye ejemplos de configuración y adaptación de sistemas existentes al SSO utilizando tecnologías como OpenAM y Moodle.
Single sign on spanish - guía completa
- 1. Google confidential | Do not distribute Single Sign On Guía completa Carlos Toxtli
- 2. Google confidential | Do not distribute Comprendiendo Single Sign-On Webinar 01 Carlos Toxtli
- 3. Google confidential | Do not distribute ¿Qué es Single Sign-On ? Single Sign-On es un mecanismo de autenticación que permite a los usuarios acceder a múltiples servicios con un solo inicio de sesión.
- 4. Google confidential | Do not distribute
- 5. Google confidential | Do not distribute Conceptos básicos Entidades ● Proveedor de identidad (Identity provider IdP) o Servidor de autorización (Authorization Server AS): Entidad que otorga el acceso. ● Proveedor de servicio (Service provider SP) o Servidor de recursos (Resource Server RS) Entidad que solicita y obtiene la confirmación de acceso del proveedor de identidad. ● Usuario o Propietario de recursos (Resource Owner RO) Persona que solicita acceso.
- 6. Google confidential | Do not distribute Conceptos básicos ● SAML Usado para la autenticación web. ● OAuth2 Usado para la autenticación multiplataforma. ● OpenID & OpenID Connect OpenID ha sido paulatinamente descontinuado y OpenID Connect ha ocupado su lugar usando como base OAuth2 Estándares SSO
- 7. Google confidential | Do not distribute Conceptos básicos Plataformas que funcionan como servidor SAML o OAuth2 y sirven como interfaz para conectarse a los principales proveedores de identidad. Soluciones de control de acceso
- 8. Google confidential | Do not distribute Estandares de SSO usados por Google ● SAML como proveedor de servicios Cuando una institución requiere validar el acceso a Google Apps por medio de su actual método de autenticación. ● OAuth2 como proveedor de identidades Cuando una institución desea otorgar acceso a otras aplicaciones usando las cuentas guardadas en Google Apps.
- 9. Google confidential | Do not distribute Diagrama de SAML
- 10. Google confidential | Do not distribute Diagrama de OAuth2
- 11. Google confidential | Do not distribute
- 12. Google confidential | Do not distribute Demostración http://mail.google.com/a/appsedudemo.com https://www.youtube.com/watch?edit=vd&v=65yypNrPqq8 Google como SP
- 13. Google confidential | Do not distribute Demostración http://idp-moodle-admin.sso.appsedudemo.com https://www.youtube.com/watch?edit=vd&v=0LvFxQhblAE Google como IdP
- 14. Google confidential | Do not distribute Herramientas usadas en Single Sign-On Webinar 02 Carlos Toxtli
- 15. Google confidential | Do not distribute Soluciones de control de acceso Son las plataformas utilizadas para conectar a los proveedores de servicio con los proveedores de identidad y mantener el estatus de conectado entre ellos. Algunas soluciones de software libre que tienen integradas las tecnologías soportadas por Google (SAML/OAuth2/OpenID Connect) son: ● SimpleSAML (PHP) ● Gluu (Modulo de Apache) ● WSO2 (Archivos ejecutables) ● CAS (Java, se configura usando XML) ● OpenAM (Java, se configura desde una interfaz web)
- 16. Google confidential | Do not distribute ● Para conectar múltiples proveedores de servicio a un solo proveedor de identidad. ● Preservar la sesión del usuario autenticado. ● Provee una interfaz web de acceso a los proveedores de identidad. ● Puede usarse para administrar usuarios y ser replicados. ● Permite restablecer contraseñas. ● Encadenar múltiples inicios de sesión al mismo tiempo (chaining). ● Usado también como conector para plataformas que no estan aún adaptadas para conectarse a sistemas federados por medio de Fedlets y OpenIG. Distintos usos de OpenAM
- 17. Google confidential | Do not distribute Entendiendo los conceptos básicos Circles of trust: Concepto usado en SAML para agrupar a los SPs que confían en el mecanismo de autenticación de un IdP. Realm: Ambientes federados que permiten tener configuraciones separadas y jerárquicas entre distintos mecanismos SSO que existan en una institución. Subjects: La forma en la que OpenAM guarda los perfiles de usuario y estan ligados al IdP. Data Store: Mecanismo que guarda y sincroniza Subjects. Agents: Valida las conexiones entrantes y cifra las conexiones salientes para proteger los medios de acceso a OpenAM. Services: Sobre cada Realm se pueden asociar servicios como envio de correo, restablecimiento de contraseña, opciones de idiomas, etc.
- 18. Google confidential | Do not distribute Instalación de OpenAM Requerimientos ● Java ● Tomcat 7 ● Un subdominio llamado openam (i.e. openam.federation.com)
- 19. Google confidential | Do not distribute Prueba Vamos a crear un usuario y acceder con sus credenciales. https://www.youtube.com/watch?edit=vd&v=loSIDqLrEfo
- 20. Google confidential | Do not distribute Google Apps como Proveedor de Servicio Webinar 03 Carlos Toxtli
- 21. Google confidential | Do not distribute ¿Cómo funciona Google Apps como Proveedor de Servicio? Google Apps funciona como proveedor de soluciones cuando la institución en la cuál se va a implementar ya cuenta con un proveedor de identidad en el cuál son almacenadas las cuentas. Las cuentas de Google Apps deben estar sincronizadas con el proveedor de identidad. Cada solicitud de inicio de sesión será enviada al servidor SAML el cuál validará directamente con el proveedor de identidad.
- 22. Google confidential | Do not distribute Para proveedores de identidad como Active Directory y LDAP usamos la herramienta Google Apps Directory Sync para la sincronización. Esta herramienta se ejecuta periódicamente para agregar/actualizar usuarios de LDAP a Google Apps. Sincronización de cuentas
- 23. Google confidential | Do not distribute Google Apps al servidor SAML de OpenAM solo como un medio para autenticar con el proveedor de identidad. Ambas plataformas comparten certificados para garantizar la comunicación segura. OpenAM como servidor SAML
- 24. Google confidential | Do not distribute OpenAM cuenta con un asistente que facilita el proceso de configuración. En Google Apps la configuración de SSO se realiza desde: Admin Console > Security > Advanced settings > Setup Single Sign-On https://www.youtube.com/watch?edit=vd&v=z1exg9kP2eg Configurando OpenAM y Google Apps
- 25. Google confidential | Do not distribute En este ejemplo habilitaremos un servidor OpenLDAP que es compatible con el protocolo LDAP como también lo es Active Directory. https://www.youtube.com/watch?v=eV5ySrdn2mo&edit=vd Configuración del Proveedor de Identidad
- 26. Google confidential | Do not distribute Configuración de la herramienta. https://www.youtube.com/watch?v=LU9RM1oOF5Y&edit=vd Google Apps Directory Sync
- 27. Google confidential | Do not distribute Probemos la plataforma con la cuenta de demostración creada. https://www.youtube.com/watch?v=UzjMrTVgIOk&edit=vd Prueba
- 28. Google confidential | Do not distribute Google Apps como Proveedor de Identidad Webinar 04 Carlos Toxtli
- 29. Google confidential | Do not distribute ¿Cómo funciona Google Apps como Proveedor de Identidad? Es usado cuando una institución quiere garantizar el acceso a sus distintos sistemas (Proveedores de Servicio), usando las credenciales almacenadas en Google Apps.
- 30. Google confidential | Do not distribute Google Apps funciona como servidor de estos protocolos: ● OpenID Connect ● OAuth2 Protocolos soportados por Google Apps
- 31. Google confidential | Do not distribute En la mayoría de los casos, procedemos a conectar los Proveedores de Servicio directamente a Google Apps, sin necesidad de usar un servidor intermedio. En ambientes federados complejos, en los cuales tenemos plataformas que soportan distintos protocolos de autenticación, es recomendable usar soluciones de administración de acceso como por ejemplo OpenAM. Servidor de OAuth2
- 32. Google confidential | Do not distribute La ventaja de OAuth2 es que es multiplataforma, no solo soporta a navegadores como clientes. Si el Proveedor de Servicio no soporta aún OAuth2 como mecanismo de autenticación, puede ser fácilmente desarrollado siguiendo las guías que se encuentran en Google Developers https://developers.google.com/oauthplayground Clientes de OAuth2
- 33. Google confidential | Do not distribute Conectando un cliente directamente a Google Apps En este ejemplo conectaremos Moodle (un LMS muy popular) para que consuma las credenciales de Google Apps. https://www.youtube.com/watch?edit=vd&v=eSt2ohRPA7U
- 34. Google confidential | Do not distribute Conectando Moodle con Google Apps a través de OpenAM En ambientes complejos en los que conviven múltiples protocolos de autenticación, es recomendable administrarlos desde una solución de control de acceso, en este ejemplo configuraremos de nuevo Moodle con Google Apps pero esta vez pasando a través de OpenAM. https://www.youtube.com/watch?edit=vd&v=rAjexJJnS0k
- 35. Google confidential | Do not distribute Adaptando sistemas existentes a SSO Webinar 05 Carlos Toxtli
- 36. Google confidential | Do not distribute Dependiendo la tecnología SSO que la institución utilice, son los sistemas que pueden ser integrados para garantizar el uso de las mismas credenciales y la persistencia de la sesión. El proceso de adaptar un sistema puede hacerse ya sea desarrollando un cliente o configurando uno existente. Adaptando sistemas existentes
- 37. Google confidential | Do not distribute Evaluando la solución La solución adecuada depende de como esté SSO implementado. En este webinar exploraremos arquitecturas de SSO basadas en SAML y OAuth2.. Las tecnologías SSO empleadas en estos ejemplos son: ● SAML ○ OpenAM ○ SimpleSAML ● OAuth2 ○ OpenAM ○ Google Apps
- 38. Google confidential | Do not distribute ● Tanto servidor como cliente SAML deben compartir un certificado. ● Soporte de HTTPS. ● Cliente SAML ○ Cliente desarrollado usando librerías de SSO ■ Lasso ( C/C++, Python, Java, Perl, PHP ) ■ Onelogin ( ASP/.NET, Java, PHP, Python, Ruby ) ○ Cliente generico ■ OpenIG (Plataformas web) Requerimientos para integrar en un entorno SAML
- 39. Google confidential | Do not distribute ● Cliente OAuth2 ○ Cliente desarrollado usando librerías genéricas de OAuth2. ■ OAuth2 site libraries (PHP,Objective C,Java,Apache,Python,Ruby,Javascript,.NET,C++) ○ Cliente desarrollado usando librerías propias del servicio. ■ Google APIs Client Library ○ Cliente generico ■ OpenIG Requerimientos para integrar en un entorno OAuth2
- 40. Google confidential | Do not distribute ● Descargar OneLogin SAML Toolkit de http://www.onelogin.com/resources/saml-toolkits/ ● Extraer el ejemplo contenido a el servidor web y cambiar los parámetros por los del servidor SAML. ● Registrar el servicio en OpenAM Desarrollando un cliente SAML usando la librería de OneLogin Ejemplo 1: Integrando un sistema existente a SAML
- 41. Google confidential | Do not distribute ● Descargar OpenIG de http://openig.forgerock.org/ ● Renombrar el archivo war (Tomcat=ROOT.war, jetty=root.war) y copiarlo a la raíz del servidor Java. ● Crear un Fedlet dentro de OpenAM, descomprimir el archivo zip y el war y copiar la carpeta “saml” a: ○ /usr/share/tomcat7/.openig/saml ● Crear un archivo de configuración y llenarlo con los datos del servidor. /usr/share/tomcat7/.openig/config/config.json Integrando OpenIG como cliente generico. Ejemplo 2: Integrando un sistema existente a SAML
- 42. Google confidential | Do not distribute ● Descarga una de las librerías del sitio de OAuth2 ○ http://oauth.net/2/ ● Descarga el código de ejemplo ● Descomprime el código de ejemplo en tu servidor y configura los parámetros de tu servidor. Desarrollando un cliente OAuth2. Ejemplo 3: Integrando un sistema existente a OAuth2
- 43. Google confidential | Do not distribute Son los mismos pasos de la configuración de OpenIG con SAML, solamente hay que cambiar el archivo config.json con los parámetros de OAuth2. Integrating OpenIG as a generic client. Ejemplo 4: Integrando un sistema existente a OAuth2
- 44. Google confidential | Do not distribute Gracias