Conocer los protocolos de autenticación SAML, OpenID Connect y Oauth
Discernir los matices entre los protocolos de seguridad para la autenticación puede ser un reto. Esta perspectiva se proporciona para mostrar las diferencias entre AD FS, SAML, OpenID Connect, y Oauth lo que son y cómo se utilizan.
Active Directory Federation Services (AD FS) Protocolo de autenticación
Microsoft desarrolló AD FS para extender la identidad empresarial más allá del cortafuegos. Proporciona acceso de inicio de sesión único a los servidores que están fuera de las instalaciones. AD FS utiliza un modelo de autorización de acceso basado en reclamaciones. Este proceso implica autenticar a los usuarios a través de cookies y el lenguaje de marcado de seguridad (SAML).
Eso significa que AD FS es un tipo de Servicio de Token de Seguridad, o SAS. Puede configurar STS para tener relaciones de confianza que también acepten cuentas OpenID. Esto permite a las empresas eludir la creación de registros separados y credenciales de usuario cuando se agregan nuevos usuarios; solo pueden usar las credenciales existentes de OpenID.
AD FS es una herramienta valiosa, pero tiene algunos desventajas:
Es engorroso de usar cuando se integra con aplicaciones móviles en la nube o no-Microsoft
Requiere recursos de TI para instalar, configurar y mantener
Es difícil de escalar y requiere de instalaciones de aplicación tediosas
Aunque técnicamente es una oferta gratuita de Microsoft, el uso de AD FS puede incurrir en costos ocultos como el tiempo y el esfuerzo para que la TI lo mantenga.
Qué es el protocolo de autenticación SAML
Aserción de seguridad Markup Language o SAML es el más antiguo de los principales protocolos de identidad federada con su última revisión importante en 2005. Hay tres jugadores principales en SAML: el usuario, el Proveedor de Identidad (o IdP) que autentica al usuario, y el Proveedor de Servicios (o SP) como una aplicación.
SAML tiene tres componentes primarios que son la afirmación, el protocolo y la unión. La aserción SAML es un paquete de información basado en XML que contiene información específica como el usuario, el grupo al que pertenece el usuario o cualquier otra información que pueda ser útil para una aplicación. Las declaraciones son para autenticación (identificar un usuario), atributos (información sobre un usuario) o autorización (lo que un usuario puede acceder y hacer).
El protocolo define cómo se envían y reciben las afirmaciones. Por último, la unión es una definición de cómo los intercambios de mensajes SAML y los intercambios de Protocolo de Acceso a Objetos Simple (SOAP) se mapean entre sí.
Aquí hay un caso de uso simplificado de SAML. El usuario necesita acceder a muchas aplicaciones diferentes. El cliente del usuario le dice a una aplicación - que es el Proveedor de Servicios - que quiere acceder a sus servicios. El proveedor de servicios entonces necesita comprobar si el usuario está autenticado. Si lo son, entonces el usuario es libre de proceder. Si no lo son, el cliente necesita ir al Proveedor de Identidad para la autenticación.
El Proveedor de Identidad autenticará al usuario contra alguna credencial en este punto. Una vez que el Proveedor de Identidad ha autenticado al usuario que da acceso a la aplicación, crea la afirmación SAML. El Proveedor de Identidad pasa la afirmación SAML al cliente que luego la pasa al Proveedor de Servicios. El Proveedor de Identidad también puede pasar la afirmación a diferentes aplicaciones según sea necesario, salvando al usuario de re-autenticar.
Diagrama de flujo SAML 2.0
Terminología Microsoft y AD FS
Servicios de la Federación de Directorios activos de Microsoft tiene su propia terminología y enfoque a SAML, por lo que merece una breve explicación. Microsoft AD FS es un proveedor de identidad.
Confiar en Parte es el término que Microsoft AD FS utiliza para significar proveedor de servicios.
Las Normas de Reclamaciones es otro término que sólo Microsoft AD FS utiliza. Las reglas de reclamaciones son reglas que puede aplicar para modificar cómo o cuándo invocar la autenticación. Por ejemplo, un administrador podría configurar una regla de reclamos que solo se aplica cuando un usuario viene a AD FS cuando está tratando de llegar a Dropbox. Además, les impide utilizar un dispositivo móvil que le permita iniciar sesión con un computadora portátil o un dispositivo de escritorio, pero no con su Android o iPhone. Algunos IdPs distintos de AD FS pueden crear reglas similares, pero AD FS permite la creación de algunas de las reglas más robustas y complejas.
ImmutableID es el Microsoft Azure AD equivalente de un ObjectGUID. No es específico de AD FS, pero vale la pena mencionar.
WS-Fed es similar a SAML y cumple con muchas de las mismas reglas. Es un protocolo creado específicamente por Microsoft y no ampliamente apoyado por IdPs distintos de AD FS.
Beneficios de configurar los proveedores de autenticación 3rd Party como autenticación primaria en AD FS
Las organizaciones están experimentando ataques que tratan de forzar, comprometer o bloquear cuentas de usuario enviando solicitudes de autenticación basadas en contraseñas. Para ayudar a proteger a las organizaciones del compromiso, AD FS ha introducido capacidades como el bloqueo “inteligente” de extranet y el bloqueo basado en direcciones IP.
Sin embargo, estas medidas de mitigación son reactivas. Para proporcionar una forma proactiva de reducir la gravedad de estos ataques, AD FS tiene la capacidad de solicitar factores no contraseña antes de recoger la contraseña. Por ejemplo, AD FS 2016 introdujo Azure MFA como autenticación primaria, de modo que los códigos OTP de la aplicación Authenticator podrían ser utilizados como el primer factor. Basándose en esto con AD FS 2019, puede configurar proveedores de autenticación externos como factores de autenticación primarios. A continuación se presentan dos escenarios clave que permiten.
Escenario 1: Proteger la contraseña
Microsoft desarrolló AD FS para extender la identidad empresarial más allá del cortafuegos.
Proporciona acceso de inicio de sesión único a los servidores que están fuera de las instalaciones. AD FS utiliza un modelo de autorización de acceso basado en reclamaciones. Este proceso implica autenticar a los usuarios a través de cookies y el lenguaje de marcado de seguridad (SAML).
Escenario 2: Sin contraseña
También puede eliminar contraseñas completamente completando una autenticación fuerte, multifactor mediante métodos totalmente sin contraseña en AD FS.
Azure MFA con la aplicación Autenticator
Windows 10 Hola para Negocios
Autenticación del certificado
Proveedores de autenticación externos (esto proporciona la mejor mitigación de riesgos para ataques de suplantación como phishing y MitM) que requiere algún tipo de integración con Microsoft
Definir el protocolo de autenticación de OpenID Connect
Mientras que OAuth 2.0 no es muy adecuado para la autenticación, OpenID Connect se las arregla para resolver este problema. Establecido en 2014, OpenID Connect es una capa de identidad construida encima de OAuth 2.0, con un gran número de implementaciones de empresas como Google y PayPal. OpenID Connect permite a las aplicaciones clientes recibir información básica valiosa sobre un usuario, como la identidad del usuario, los atributos disponibles del usuario y otros detalles relacionados con la autenticación. Al igual que SAML, la autenticación es realizada por algún Proveedor de Identidad, como Google, que luego se transmite de nuevo a la parte de retransmisión o el servicio que solicita la autenticación.
Los proveedores de identidad apoyados van desde las grandes empresas hasta los pequeños proveedores, como uno mismo-emitido. OpenID Connect fue diseñado con sencillez en mente y utiliza flujos de mensajes REST/JSON. Soporta una variedad de clientes, incluyendo clientes basados en la web, clientes móviles y clientes de JavaScript. Por último, la especificación extensible de OpenID Connects permite funciones opcionales como cifrado de datos de identidad, descubrimiento de proveedores de OpenID y gestión de sesiones.
Diagrama de flujo OpenID Connect
Conclusión
OpenId Connect se basa en los flujos de proceso de OAuth 2.0 y normalmente utiliza el formato JWT (JSON Web token) para el id-token.
El flujo SAML es independiente de OAuth 2.0 y se basa en el intercambio de mensajes para la autenticación en formato XML SAML (en lugar del formato JWT).
Ambos flujos permiten SSO (Inicio de sesión único), y la capacidad de iniciar sesión en un sitio web utilizando sus credenciales de inicio de sesión desde un sitio social (por ejemplo. Inicio de sesión en Facebook o en Google).
OpenId Connect es más reciente y se basa en el flujo de proceso OAuth 2.0. Se prueba y prueba y se utiliza típicamente en sitios web de consumidores, aplicaciones web y aplicaciones móviles.
SAML es su primo mayor, y se utiliza típicamente en la configuración de la empresa en, por ejemplo, permitiendo un solo inicio de sesión en varias aplicaciones dentro de una empresa utilizando el Active Directory login.
Comparando SAML vs. Protocolos de autenticación OpenID Connect
A riesgo de simplificación excesiva, OpenID Connect es una reescritura de SAML usando OAuth 2.0. Aquí hay algunas similitudes y diferencias.
IDP / SP vs. PO / RP
En SAML, el usuario es redirigido del Proveedor de Servicios (SP) al Proveedor de Identidad (IDP) para iniciar sesión. En OpenID Connect, el usuario es redirigido desde la Parte de Confianza (RP) al Proveedor de OpenID (OP) para iniciar sesión. El SAML SP es siempre un sitio web. El OpenID Connect RP es una aplicación web o móvil y se llama con frecuencia el “cliente” porque extiende un cliente OAuth 2.0. En ambos casos, el IDP/OP controla el inicio de sesión para evitar la exposición de secretos (como contraseñas) al sitio web o la aplicación.
Aserción vs. id_token
En SAML, hay una “aserción” - un documento XML firmado con la información de asunto (que autenticado), atributos (información sobre la persona), el emisor (que emitió la afirmación), y otra información sobre el evento de autenticación. El equivalente en OpenID Connect es el id_token. Este es un documento JSON firmado que contiene la información del sujeto, el emisor y la autenticación.
Front Channel vs. Canal trasero
Una gran diferencia entre OpenID Connect y SAML es el uso de un “canal frontal” y un “canal trasero”. El canal frontal es el navegador y el canal trasero es la comunicación directa entre la aplicación y el IDP/OP.
Aunque SAML define mecanismos de back-canal, rara vez se utilizan en la práctica. La forma más común en que SAML envía la petición XML y la respuesta XML (aserción) es a través del navegador. La mayoría de los sitios de SAML utilizan la “Encuadernación POST” para enviar la respuesta. En este escenario, el navegador se envía como un formulario HTML desde el IDP con la respuesta XML como parámetro de formulario. Hay un poco de JavaScript en el formulario para auto-enviar los datos de vuelta al SP. Es un truco limpio porque el SP y el IDP no necesitan conectividad de red para comunicarse porque el navegador actúa como el intermediario!
OpenID Connect define un mecanismo similar (“Modo de respuesta al post del formulario”), pero a diferencia de SAML, su uso es más la excepción que la regla. Tanto OpenID Connect como SAML usan frecuentemente algo como la “Redirect Binding” para enviar la solicitud. Aquí es donde se utilizan los parámetros de URL para enviar el XML. Esto también aprovecha el navegador.
OpenID Connect normalmente utiliza el canal de atrás - una llamada directa del RP al OP - para recuperar esta información. Los atributos (o “reclamaciones de usuario” en la jerga OpenID) están disponibles para el cliente llamando al endpoint user_info que es un JSON REST API. Sin embargo, porque esto es OAuth 2.0, el cliente necesita un token para llamar a este API. De acuerdo con el marco OAuth 2.0, el token se obtiene del punto final del token del OP utilizando el canal de atrás.
¿Qué protocolo de autenticación, cuándo?
¿Cuándo debe utilizarse SAML y cuándo debe utilizarse OAuth 2.0 o OpenID Connect en su lugar?
Con aplicaciones móviles, no hay duda - utilizar OpenID Connect
Si la aplicación ya es compatible con SAML, utilice SAML
Si está escribiendo una nueva aplicación, utilice OpenID Connect porque ahí es donde se acepta la tecnología
Si necesita proteger las API o necesita crear una pasarela API, la respuesta corta es utilizar OAuth 2.0 o el protocolo de acceso administrado por el usuario ("UMA"). Sí, esta respuesta es una simplificación excesiva
¿Cómo es SAML diferente de Oauth y la Federación de Servicios Web?
Usted puede haber oído hablar de estas otras alternativas SAML de pasada, pero ¿cómo difieren? ¿Deberías tener una opinión sobre cuál es el mejor? Entender que SAML, OAuth, y Web Services Federation (WS-Fed) todos varían técnicamente, así como la mejor manera de ponerlos en uso.
SAML – es más utilizado por las empresas para permitir a sus usuarios acceder a los servicios por los que pagan. Salesforce, Gmail, Box y Expensify son ejemplos de proveedores de servicios a los que un empleado accedería después de un inicio de sesión SAML. SAML afirma al proveedor de servicios quién es el usuario; Esto es autenticación.
WS-Fed - Web Services Federation se utiliza para los mismos fines que SAML, para federar la autenticación de los proveedores de servicios a un proveedor de identidad común. Está bien soportado con ciertos IdPs, como Microsoft Active Directory Federation Services (AD FS), pero no es frecuente en los proveedores de servicios en la nube. WS-Fed es posiblemente más simple que SAML para los desarrolladores a implementar, pero su soporte limitado entre IdPs y SPs por igual limitan la adopción.
OAuth – es el más comúnmente utilizado por las aplicaciones y servicios del consumidor para que los usuarios no tienen que registrarse para un nuevo nombre de usuario y contraseña. “Iniciar sesión con Google” y “Iniciar sesión con Facebook” son ejemplos de OAuth en el mundo real. OAuth delega el acceso a la cuenta de Google o Facebook de una persona por un tercero.
Por lo general, la aplicación en la que el usuario está iniciando sesión puede leer directamente la información del perfil del usuario o tomar acciones (como publicar imágenes o hacer actualizaciones) en su nombre. Este es un ejemplo de autorización. Lo que es más importante es examinar la prevalencia de cada tecnología para cada caso de uso. SAML es omnipresente en el lugar de trabajo para aplicaciones basadas en la nube, mientras que WS-Fed no lo es. Por el contrario, OAuth es omnipresente entre las aplicaciones de consumo.