SAML vs connexion fédérée avec OAuth
Quelle est la différence entre SAML et federated login avec OAuth? La solution la plus logique, si une entreprise souhaite utiliser un tiers webapp, mais également en veut d'authentification unique et de l'autorité d'authentification?
7 réponses
ils résolvent différents problèmes.
SAML est un ensemble de normes qui ont été définies pour partager des informations sur qui est un utilisateur, ce que son ensemble d'attributs sont, et vous donner un moyen d'accorder/refuser l'accès à quelque chose ou même demander l'authentification.
outh est plus sur la délégation de l'accès à quelque chose. Vous êtes essentiellement permettant quelqu'un pour "agir" comme vous. Il est le plus couramment utilisé pour accorder des api d'accès qui peuvent faire quelque chose en votre nom.
ce sont deux choses complètement différentes.
quelques exemples qui pourraient aider.
pensez à un twitter. Disons que vous utilisez Google Buzz et Twitter, et vous voulez écrire une application pour pouvoir garder les deux synchronisés. En gros, vous pouvez établir la confiance entre votre application et twitter. La première fois que vous allez lier l'application à twitter, vous faites l'invite classique pour vous connecter à twitter, et puis cette boîte de confirmation apparaît et demande "Voulez-vous accorder l'accès à "votre nom d'application"?"une fois que vous cliquez sur "oui", la fiducie a été établie, et maintenant, votre application peut agir comme vous sur Twitter. Il peut lire vos messages, ainsi que faire de nouveaux.
SAML-pour SAML penser à une sorte d '"accord" entre deux systèmes d'adhésion sans rapport. Dans notre cas, nous pouvons utiliser US Airways et Hertz. Il n'y a aucun ensemble partagé de justificatifs d'identité qui peuvent vous emmener d'un site à un autre, mais disons que Hertz veut offrir un "deal" à US Airways. (Certes, je sais que c'est un exemple extrême, mais garder avec moi). Après avoir acheté un vol, ils offriront une voiture de location gratuite à ses membres Président. US Airways et Hertz établiraient une certaine forme de confiance, et un moyen d'identifier l'utilisateur. Dans notre cas, notre "fédéré id" serait l'adresse e-mail, et il serait un ensemble de confiance Hertz croit que US Airways identity provider fournira un jeton qui est exact et d'une manière sûre. Après la réservation le fournisseur d'identité de US Airways de vol produirait un jeton et peupler comment ils ont authentifié l'utilisateur, ainsi que des "attributs" sur la personne dans notre cas l'attribut le plus important serait son niveau de statut dans US Airways. Une fois que le token a été rempli, il le passe via un type de référence, ou encodé dans une url et une fois que nous arrivons à Hertz, il regarde le jeton, le valide et maintenant peut permettre la libre voiture de location.
le problème avec cet exemple de SAML est que c'est seulement un cas d'utilisation spécialisée sur beaucoup. SAML est une norme et il y a presque trop de façons de la mettre en œuvre.
alternativement, si vous ne vous souciez pas de l'autorisation, vous pourriez presque argumenter que l'affirmation de l'authentification via SAML et OpenID .
regarder cette simple explication , en voici un résumé:
beaucoup de gens sont confus au sujet des différences entre SAML, OpenID et OAuth, mais c'est en fait très simple. Bien qu'il existe certaines Chevauchement, voici une façon très simple de distinguer entre les trois.
OpenID – single sign-on pour les consommateurs
SAML – single sign-on pour les utilisateurs en entreprise
OAuth API d'autorisation entre les applications
pour les gens qui sont à l'aise avec les modèles de design OO, je pense qu'il y a un joli corollaire à wrapper patterns . Pensez à Façade , Décorateur et Proxy patterns. Fondamentalement, ce sont tous les mêmes, ce sont juste des emballages... la différence est la intention de chaque modèle .
de Même, SAML, OAuth et OpenID tous les faciliter des intentions différentes , via un commune mécanisme sous-jacent , qui est une redirection vers un fournisseur de service/de l'identité de l'autorité pour certains interaction privée, suivie par la redirection à l'origine de l'application tierce.
en regardant autour du filet, vous trouverez Chevauchement entre les capacités des protocoles. authentification via OAuth est parfaitement raisonnable. L'authentification unique sur OAuth ne peut pas faire beaucoup de sens, bien que SAML et OpenID sont spécifiquement orientées vers l'identité fédérée.
À la question elle-même, dans un contexte commercial, SAML semble plus approprié que OAuth pour l'authentification unique . Je parie que si vous regardez la troisième partie applications que vous souhaitez intégrer à votre identité d'entreprise, vous trouverez ils sont déjà conçus pour s'intégrer à SAML/LDAP/Radius etc. IMO OAuth est plus approprié pour l'interaction Internet entre les applications ou peut-être des applications comprenant une Architecture orientée services dans un grand environnement d'entreprise.
les règles D'autorisation peuvent également être précisées d'une autre manière dans un environnement d'entreprise. LDAP est un outil courant pour cela. Organiser les utilisateurs en groupes et associer les privilèges d'application contre l'appartenance à un groupe est une pratique répandue approche. Arrive LDAP peut être utilisé pour l'authentification. Active Directory est un bon exemple, bien que je préfère OpenLDAP.
SAML a une variété de" profils "à choisir de permettre aux autres utilisateurs de" se connecter " à votre site. SAML-P ou SAML passif est très commun et assez simple à mettre en place. WS-Trust est similaire et il permet aussi la fédération entre les sites web.
OAuth est conçu pour l'autorisation. Vous pouvez lire plus ici:
ils gèrent un cas d'utilisation subtile
- SAML de Partage d'informations d'identification (par exemple, SSO) d'un utilisateur à différents fournisseurs de services (par exemple, web ou service web)
- OAuth Un Utilisateur de déléguer une Application à accéder à une ressource sur le compte de son
SAML est pour l'authentification - principalement utilisé dans Mono signe sur scénario. OAuth est d'autorisation de ressource représentations.
JSON Web Token (JWT) est une alternative pour les Tokens SAML XML. JWT peut être utilisé avec OAuth
une bonne référence est SAML vs. OAuth: lequel devrais-je utiliser?
le terme Fédération signifie réellement des identités de connexion entre les systèmes. C'est lié à SSO mais ils ne sont pas tout à fait les mêmes. j'ai trouvé ce billet de blog vraiment utile en termes de ce que la Fédération signifie vraiment.
bon article trouvé ici
SAML (Security Assertion Markup Language) est un ensemble de normes afin d'assurer l'authentification Unique (SSO), de la Fédération et de Gestion de l'Identité.
exemple : un utilisateur (principal) s'authentifie avec un site de réservation de vol, AirFlyer (fournisseur d'identité) qui a SSO configuré via SAML avec un site de réservation de navette,Shuttler (prestataire de services). Une fois authentifié sur Flyer, l'utilisateur peut réserver des navettes sur Shuttler sans avoir besoin d'authentification
OAuth (Ouvrir Autorisation) est un standard pour l'autorisation de ressources. Il ne traite pas de l'authentification.
exemple : une application mobile de partage de photos (OAuth consumer) qui permet aux utilisateurs d'importer des photos à partir de leur compte Instagram (OAuth provider) qui envoie un jeton d'accès temporaire ou une clé de l'application de partage de photos qui expire après quelques heures.