SALM 2.0: solución universal de identidad
17 March, 2014
category: Seguridad en Internet, Seguridad lógica
Por Pat Patterson, desarrollador principal de Evangelist, Salesforce.com
La identidad digital gana cada vez más en importancia a medida que las empresas se esfuerzan por proteger y controlar el acceso a los recursos en línea. Se desarrollan una serie de estándares que contribuyen a que la gestión de identidad y el inicio de sesión único (single sign-on) se hagan realidad para las organizaciones que implementan sistemas.
Al concluir 2013, SecureIDNews.com consideró cuatro diferentes estándares de identidad, y el rol que estos juegan en el apoyo a las empresas para la creación de ecosistemas de identidad.
Una escena familiar: sentado frente a una página web con dos campos de entrada, nombre de usuario y contraseña, devanándote los sesos para desenterrar la mágica combinación que te dará acceso al sitio web de tu banco, red social o proveedor de salud de tu compañía.
Aunque a veces encuentras un escape en un botón que dice “Inicia sesión con Facebook, Google o Twitter”, o haces clic en una página intranet de tu compañía y te lleva directo a la página de los beneficios de salud sin tener que autenticarte. Das un respiro de alivio, pero quizás nunca te has preguntado qué pasa detrás del telón o cómo podrías aplicar esa misma magia. Bienvenido al mundo del inicio único de sesión o “single sign-on”.
Existen varios protocolos que permiten que sitios como Google, Facebook e incluso tu propio empleador confirmen las identidades de sus usuarios a sitios como Quora, Workday o Concur. Los grandes proveedores de servicio Internet están utilizando una especificación llamada OpenID Connect, pero en el mundo empresarial la que predomina es la versión 2.0 de Security Assertion Markup Language o SAML (se pronuncia SAM-ul para abreviar).
SAML 2.0, ratificada en marzo de 2005 como un estándar OASIS, comprende una serie de documentos de especificación que definen de forma abarcadora cómo representar la información de identidad y pasarla entre las partes interesadas.
En primer lugar, algo del lenguaje técnico necesario: un sujeto se registra con un proveedor de identidad, que confirma la identidad del usuario a uno o más proveedores de servicios. En el caso de una empresa, el proveedor de identidad puede ser un producto de software implementado en el establecimiento, como ForgeRock OpenAM o un servicio en línea como Salesforce Identity.
Por otra parte, el proveedor de servicios puede ser un servicio en línea como Workday o Concur, o incluso un sitio de intranet como por ejemplo el departamento de nóminas de la compañía.
¿Cómo es que el proveedor de identidad “confirma” la identidad del sujeto? El perfil de inicio único de sesión (SSO) de navegador web de SAML 2.0 define una serie de mecanismos para pasar la información entre los proveedores. He aquí uno de los más comunes: utilizar Salesforce Identity como proveedor de identidad y Workday como proveedor de servicios.
Tú (el sujeto) tratas de acceder a Workday a través de una dirección URL específica para tu compañía. Workday recibe tu solicitud, ve que no estás conectado en ese momento (ya que tu navegador no ha presentado un cookie de sesión con la solicitud), busca en Acme la URL del proveedor de identidad, crea una solicitud SAML y la envía a la URL mediante un formulario HTML.
La solicitud SAML es un documento XML que dice en esencia “Envíenme una confirmación SAML respecto a este sujeto”. Típicamente contiene un identificador para el proveedor de servicio de modo que el proveedor de identidad sepa quién envió la solicitud, pero también puede contener instrucciones adicionales, por ejemplo, que el atributo ForceAuthn requiere que el proveedor de identidad le pida al usuario que se autentifique, incluso aunque el usuario ya tenga una sesión existente.
Al recibir la solicitud SAML, de ser necesario, el proveedor de identidad autentica al usuario. Este paso de autenticación está fuera de la especificación SAML – puede ser nombre de usuario/contraseña, un token de hardware, biometría – hasta que el proveedor de identidad establezca la identidad del usuario mediante un mecanismo apropiado.
Después de realizar la autenticación con éxito, el proveedor de identidad crea una confirmación SAML. Esta es la pieza central de la especificación SAML, un documento XML firmado que identifica al usuario y que confirma que el proveedor de identidad ha autenticado a ese usuario. Como mínimo, la confirmación contiene un identificador para el usuario (por ejemplo, una dirección de correo electrónico), una marca de tiempo y una referencia al mecanismo de autenticación, quizás “contraseña por SSL/TLS.” El proveedor de identidad incluye la confirmación en una respuesta SAML y la devuelve al proveedor de servicios, nuevamente mediante un formulario HTML.
Ahora el proveedor de servicios puede validar la confirmación SAML, revisando que haya sido firmada por un proveedor de identidad de confianza y que haya emitido un cookie de sesión para el usuario. El usuario tiene acceso simplemente yendo a la dirección URL Workday/Acme y es como si lo hubieran autenticado directamente por parte del proveedor de servicios. ¡Asunto resuelto!
De modo que el perfil SSO de navegador web de SAML 2.0 es la base para el inicio único de sesión de la empresa, pero SAML como un todo puede hacer mucho más. Como el paso de la autenticación real está fuera del alcance de SAML, puedes incorporar allí cualquier protocolo, quizás autenticación biométrica o autenticación integrada Windows. El mismo SAML puede incorporarse dentro de otros protocolos, como OAuth, y la confirmación SAML suele utilizarse como un formato token para comunicar datos de identidad, autenticación y autorización en la web y dentro de las empresas.
A la avanzada edad de ocho años, SALM es el “abuelo de los protocolos de identidad en internet”. Goza del apoyo casi unánime de los proveedores de Internet y los productos empresariales, pero hasta cierto punto representa la “vieja guardia” de los protocolos, una especificación voluminosa basada en XLM que trata de abarcar todos los posibles casos de uso.
El pasado y el presente le pertenecen a SAML, pero la mayoría de los expertos en identidad apuntan a OpenID Connect como el futuro, ya que es un protocolo más ligero, basado en JSON, que implementa los casos de uso más comunes de inicio único de sesión.