SAML vs inicio de sesión federado con OAuth
Respuestas:
Resuelven diferentes problemas.
SAML es un conjunto de estándares que se han definido para compartir información sobre quién es un usuario, cuál es su conjunto de atributos y brindarle una forma de otorgar / denegar acceso a algo o incluso solicitar autenticación.
OAuth se trata más de delegar el acceso a algo. Básicamente, estás permitiendo que alguien "actúe" como tú. Se usa más comúnmente para otorgar acceso a API que pueden hacer algo en su nombre.
Son dos cosas completamente distintas.
Algunos ejemplos que pueden ayudar.
OAuth piensa en un twitter. Supongamos que está utilizando Google Buzz y Twitter, y desea escribir una aplicación para poder mantener los dos sincronizados. Básicamente, puede establecer confianza entre su aplicación y Twitter. La primera vez que va a vincular la aplicación a Twitter, hace el mensaje clásico para iniciar sesión en Twitter, y luego aparece el cuadro de confirmación y pregunta "¿Le gustaría otorgar acceso a« el nombre de su aplicación »?" una vez que haga clic en "sí", se habrá establecido la confianza y ahora su aplicación puede actuar como usted en Twitter. Puede leer sus publicaciones, así como crear otras nuevas.
SAML: para SAML, piense en algún tipo de "acuerdo" entre dos sistemas de membresía no relacionados. En nuestro caso podemos utilizar US Airways y Hertz. No existe un conjunto compartido de credenciales que pueda llevarlo de un sitio a otro, pero digamos que Hertz quiere ofrecer un "trato" a US Airways. (De acuerdo, sé que este es un ejemplo extremo, pero tengan paciencia conmigo). Después de comprar un vuelo, ofrecerán un coche de alquiler gratuito a sus miembros presidentes. US Airways y Hertz establecerían alguna forma de confianza y alguna forma de identificar al usuario. En nuestro caso, nuestra "identificación federada" sería la dirección de correo electrónico, y sería un conjunto de confianza unidireccional. Hertz confía en que el proveedor de identidad de US Airways entregará un token que sea preciso y seguro. Después de reservar el vuelo, el proveedor de identidad de US Airways generará un token y completará cómo han autenticado al usuario, así como los "atributos" de la persona; en nuestro caso, el atributo más importante sería su nivel de estatus en US Airways. Una vez que se ha llenado el token, lo pasa a través de algún tipo de referencia, o se codifica en una url y una vez que llegamos a Hertz, mira el token, lo valida y ahora puede permitir el alquiler gratuito del auto.
El problema con este ejemplo de SAML es que es solo un caso de uso especializado entre muchos. SAML es un estándar y hay casi demasiadas formas de implementarlo.
Alternativamente, si no le importa la autorización, casi podría argumentar que afirmar la autenticación a través de SAML y OpenID .
Eche un vistazo a esta sencilla explicación resumida aquí:
Mucha gente está confundida acerca de las diferencias entre SAML, OpenID y OAuth, pero en realidad es muy simple. Aunque existe cierta superposición, aquí hay una forma muy sencilla de distinguir entre los tres.
OpenID: inicio de sesión único para consumidores
SAML: inicio de sesión único para usuarios empresariales
OAuth: autorización de API entre aplicaciones
Para las personas que se sienten cómodas con los patrones de diseño OO, creo que hay un buen corolario para los patrones de envoltura . Piense en los patrones de fachada , decorador y proxy . Básicamente, todos son iguales, solo son envoltorios ... La diferencia es la intención de cada patrón .
De manera similar, SAML, OAuth y OpenID facilitan diferentes intenciones a través de un mecanismo subyacente común , que es la redirección a un proveedor de servicios / autoridad de identidad para alguna interacción privada, seguida de la redirección a la aplicación de terceros de origen.
Si mira a su alrededor en la red, encontrará una superposición entre las capacidades de los protocolos. La autenticación a través de OAuth es perfectamente razonable. Sin embargo, es posible que SSO sobre OAuth no tenga mucho sentido, ya que SAML y OpenID están específicamente orientados a la identidad federada.
Para la pregunta en sí, en un contexto corporativo, SAML suena más apropiado que OAuth para SSO . Apuesto a que si observa las aplicaciones de terceros que le gustaría integrar con sus identidades corporativas, encontrará que ya están diseñadas para integrarse con SAML / LDAP / Radius, etc. IMO OAuth es más apropiado para la interacción de Internet. entre aplicaciones o quizás aplicaciones que comprenden una Arquitectura Orientada a Servicios en un gran entorno corporativo.
Las reglas de autorización también se pueden especificar en un entorno corporativo de otras formas. LDAP es una herramienta común para esto. Organizar a los usuarios en grupos y asociar los privilegios de la aplicación a la pertenencia a grupos es un enfoque generalizado. Da la casualidad de que LDAP también se puede utilizar para la autenticación. Active Directory es un gran ejemplo, aunque prefiero OpenLDAP.
Encontré un buen artículo aquí
SAML (Security Assertion Markup Language) es un conjunto de estándares para lograr el inicio de sesión único (SSO), la federación y la administración de identidades.
Ejemplo : un usuario (principal) se autentica con un sitio web de reserva de vuelos, AirFlyer (proveedor de identidad) que ha configurado el SSO a través de SAML con un sitio web de reserva de transporte, Shuttler (proveedor de servicios). Una vez autenticado en Flyer, el usuario puede reservar traslados en Shuttler sin requerir autenticación
OAuth (Autorización abierta) es un estándar para la autorización de recursos. No se ocupa de la autenticación.
Ejemplo : una aplicación móvil para compartir fotos (consumidor OAuth) que permite a los usuarios importar fotos desde su cuenta de Instagram (proveedor OAuth) que envía un token o clave de acceso temporal a la aplicación para compartir fotos que caduca después de algunas horas.
SAML tiene una variedad de "perfiles" para elegir que permiten a otros usuarios "iniciar sesión" en su sitio. SAML-P o SAML Passive es muy común y bastante simple de configurar. WS-Trust es similar y también permite la federación entre sitios web.
OAuth está diseñado para autorización. Puede leer más aquí:
SAMLes para autenticación: se utiliza principalmente en el escenario de inicio de sesión único . OAuthes para la autorización de representaciones de recursos.
JSON Web Token (JWT) es una alternativa a los tokens XML SAML. JWT se puede utilizar con OAuth
Una buena referencia es SAML frente a OAuth: ¿Cuál debo usar?
Los términos federación realmente significan identidades de conexión entre sistemas. Está relacionado con SSO pero no son lo mismo. Encontré esta publicación de blog realmente útil en términos de lo que realmente significa federación.