En esta guía se explican los conceptos básicos de como implementar Single Sign On para federar multiples tecnologías bajo las mismas credenciales.

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