SAML vs connexion fédérée avec OAuth
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, quel est son ensemble d'attributs, et vous donner un moyen d'accorder / refuser l'accès à quelque chose ou même de demander une authentification.
OAuth consiste davantage à déléguer l'accès à quelque chose. Vous autorisez essentiellement quelqu'un à «agir» comme vous. Il est le plus souvent 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.
OAuth pense à un twitter. Disons que vous utilisez Google Buzz et Twitter et que vous souhaitez écrire une application pour pouvoir garder les deux synchronisés. Vous pouvez essentiellement établir la confiance entre votre application et Twitter. La première fois que vous liez l'application à Twitter, vous exécutez l'invite classique pour vous connecter à Twitter, puis cette boîte de confirmation apparaît et vous demande "Voulez-vous accorder l'accès à« votre nom d'application »?" une fois que vous avez cliqué sur «oui», la confiance a été établie et votre application peut maintenant agir comme vous sur Twitter. Il peut lire vos messages et en créer de nouveaux.
SAML - Pour SAML, pensez à un certain type d '"accord" entre deux systèmes d'adhésion non liés. Dans notre cas, nous pouvons utiliser US Airways et Hertz. Il n'y a pas d'ensemble partagé d'informations d'identification qui peuvent vous emmener d'un site à un autre, mais disons que Hertz souhaite proposer un «accord» à US Airways. (Certes, je sais que c'est un exemple extrême, mais soyez indulgents avec moi). Après avoir acheté un vol, ils offriront une voiture de location gratuite à ses membres présidents. US Airways et Hertz établiraient une forme de confiance et un moyen d'identifier l'utilisateur. Dans notre cas, notre «identifiant fédéré» serait l'adresse e-mail, et ce serait un ensemble de confiance à sens unique. Hertz a confiance que le fournisseur d'identité d'US Airways fournira un jeton précis et sécurisé. Après la réservation du vol, le fournisseur d'identité US Airways générerait un jeton et indiquerait comment il a authentifié l'utilisateur, ainsi que des "attributs" concernant la personne dans notre cas, l'attribut le plus important serait son niveau de statut dans US Airways. Une fois que le jeton a été rempli, il le transmet via un type de référence, ou encodé dans une URL et une fois que nous sommes arrivés à Hertz, il regarde le jeton, le valide et peut maintenant autoriser la location de voiture gratuite.
Le problème avec cet exemple SAML est qu'il ne s'agit que d'un cas d'utilisation spécialisé sur plusieurs. SAML est une norme et il existe presque trop de façons de l'implémenter.
Sinon, si vous ne vous souciez pas de l'autorisation, vous pourriez presque affirmer que l'authentification via SAML et OpenID .
Jetez un œil à cette explication simple résumée ici:
Beaucoup de gens sont confus sur les différences entre SAML, OpenID et OAuth, mais c'est en fait très simple. Bien qu'il y ait un certain chevauchement, voici une façon très simple de distinguer les trois.
OpenID - authentification unique pour les consommateurs
SAML - authentification unique pour les utilisateurs d'entreprise
OAuth - Autorisation d'API entre applications
Pour les personnes à l'aise avec les modèles de conception OO, je pense qu'il y a un joli corollaire aux modèles d'emballage . Pensez aux modèles de façade , de décorateur et de proxy . Fondamentalement, ce sont tous les mêmes, ce ne sont que des wrappers ... La différence est l' intention de chaque motif .
De même, SAML, OAuth et OpenID facilitent tous des intentions différentes via un mécanisme sous-jacent commun , qui est la redirection vers un fournisseur de services / une autorité d'identité pour une interaction privée, suivie d'une redirection vers l'application tierce d'origine.
En regardant autour de vous sur le net, vous constaterez un chevauchement entre les capacités des protocoles. L'authentification via OAuth est parfaitement raisonnable. Cependant, l'authentification unique sur OAuth n'a pas beaucoup de sens, car SAML et OpenID sont spécifiquement axés sur l'identité fédérée.
À la question elle-même, dans un contexte d'entreprise, SAML semble plus approprié que OAuth pour SSO . Je parie que si vous regardez les applications tierces que vous souhaitez intégrer à votre identité d'entreprise, vous constaterez qu'elles sont déjà conçues pour s'intégrer à SAML / LDAP / Radius, etc. OAuth OAuth est plus approprié pour l'interaction Internet entre des 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 spécifiées dans un environnement d'entreprise. LDAP est un outil courant pour cela. L'organisation des utilisateurs en groupes et l'association des privilèges d'application à l'appartenance à un groupe est une approche répandue. C'est ainsi que LDAP peut également être utilisé pour l'authentification. Active Directory est un excellent exemple, même si je préfère OpenLDAP.
Trouvé un bon article ici
SAML (Security Assertion Markup Language) est un ensemble de normes permettant de réaliser l'authentification unique (SSO), la fédération et la gestion des identités.
Exemple : Un utilisateur (principal) s'authentifie auprès d'un site Web de réservation de vol, AirFlyer (fournisseur d'identité) qui a configuré SSO via SAML avec un site Web de réservation de navette, Shuttler (fournisseur de services). Une fois authentifié sur Flyer, l'utilisateur peut réserver des navettes sur Shuttler sans nécessiter d'authentification
OAuth (Open Authorization) est une norme pour l'autorisation des ressources. Il ne traite pas de l'authentification.
Exemple : une application mobile de partage de photos (consommateur OAuth) qui permet aux utilisateurs d'importer des photos depuis leur compte Instagram (fournisseur OAuth) qui envoie un jeton d'accès temporaire ou une clé à l'application de partage de photos qui expire après quelques heures.
SAML propose une variété de «profils» permettant à d'autres utilisateurs de «se connecter» à votre site. SAML-P ou SAML Passive est très courant et assez simple à mettre en place. WS-Trust est similaire et permet également 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 subtil
- SAML - Partage des informations d'identification (par exemple, SSO) d'un utilisateur à divers fournisseurs de services (par exemple, Web ou service Web)
- OAuth - Un utilisateur déléguant une application pour accéder à une ressource au nom de son / elle
SAMLest pour l'authentification - principalement utilisé dans le scénario Single Sign On . OAuthest pour l'autorisation des représentations de ressources.
Le jeton Web JSON (JWT) est une alternative aux jetons XML SAML. JWT peut être utilisé avec OAuth
Une bonne référence est SAML vs OAuth: lequel dois-je utiliser?
Les termes fédération désignent en réalité les identités de connexion entre les systèmes. C'est lié au 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 signifie vraiment la fédération.