CAS vs SAML vs OAuth2
Avant de me réprimander pour avoir posé une question trop basique sans faire mes devoirs, je voudrais dire que j'ai beaucoup lu sur ces sujets, mais je suis toujours confus.
Mes besoins semblent assez simples. Dans mon entreprise, nous avons un tas de Ruby sur Rails applications. Je veux construire un service d'authentification SSO que toutes ces applications devraient utiliser.
En essayant de faire des recherches sur la façon de procéder, j'ai lu sur CAS, SAML et OAuth2. (Je sais que "Auth" dans OAuth signifie autorisation, et non authentification, mais j'ai lu suffisamment d'articles expliquant comment OAuth peut être utilisé pour l'authentification simplement bien - ceci est l'un d'entre eux.)
Quelqu'un pourrait-il me dire en termes simples ce que ces 3 sont? S'agit-il d'alternatives (concurrentes)? Est-il même juste de les comparer?
Et il y a tellement de joyaux qui semblent tous dire des choses très similaires:
- https://github.com/rubycas/rubycas-server et https://github.com/rubycas/rubycas-client
- https://github.com/nbudin/devise_cas_authenticatable
- https://github.com/onelogin/Ruby-saml
- CASino et https://github.com/rbCAS/casino-activerecord_authenticator
- Et je suis sûr qu'il existe des centaines de OAuth gemmes liées.
Je veux juste une application Rails séparée qui gère toute l'authentification pour mes autres Rails applications.
Remarque: Je ne souhaite pas autoriser les utilisateurs à utiliser leur compte Google/Facebook pour se connecter. Nos utilisateurs ont déjà des comptes sur notre site. Je veux qu'ils puissent se connecter en utilisant ce compte une fois et pouvoir accéder à toutes nos applications sans se reconnecter. La déconnexion dans n'importe quelle application doit les déconnecter de toutes les applications.
[~ # ~] mise à jour [~ # ~]
J'ai rencontré ces deux solutions OAuth:
- http://dev.mikamai.com/post/110722727899/oauth2-on-Rails
- http://blog.yorkxin.org/posts/2013/11/05/oauth2-tutorial-grape-api-doorkeeper-en/
Ils semblent décrire quelque chose de très similaire à ce que je veux. Mais je n'ai trouvé aucun guide/billet de blog/tutoriel montrant comment faire cela avec SAML/CAS.
Suggestions bienvenues.
MISE À JOUR 2
Plus de détails sur notre cas d'utilisation.
Nous n'avons aucune architecture SAML existante en place. Principalement, ce seront NOS utilisateurs (enregistrés directement sur notre site Web) qui accéderont à toutes nos applications. À l'avenir, nous pourrions avoir des sociétés tierces (partenaires) appelant nos API. Nous pouvons également avoir des utilisateurs de ces sociétés tierces (partenaires) (enregistrés sur leurs sites Web) qui accèdent à nos applications.
Si vous devez vous authentifier pour [~ # ~] ldap [~ # ~] ou ActiveDirectory , alors une solution comme l'une des [~ # ~] cas [~ # ~] les gemmes que vous avez mentionnées ci-dessus vous conviennent (RubyCAS, CASino).
Si vous pouvez vous le permettre, l'un des fournisseurs commerciaux (comme Okta ) est votre meilleure option car ils resteront au courant des correctifs de sécurité et géreront votre besoins d'authentification pour vous. En particulier, si vous devez prendre en charge ActiveDirectory, ils l'ont déjà implémenté.
OAuth est le plus utile pour l'authentification tierce, bien qu'il puisse faire l'authentification unique. Donc, si vous souhaitez prendre en charge les connexions Google/Facebook ou être un authentificateur tiers, c'est un excellent choix. Puisque vous ne voulez pas prendre en charge Google/Facebook, alors OAuth n'est probablement pas ce que vous voulez.
Si vous avez l'intention d'utiliser uniquement HTTP POST pour vos besoins d'authentification unique, la gemme Ruby-saml pourrait être la voie à suivre. Vous devez implémenter votre propre fournisseur d'identité et ajouter un composant fournisseur de services à tous vos sites Web (éventuellement sous la forme d'une gemme). vous auriez besoin d'un Rails api pour agir en tant que fournisseur d'identité. Cette gem aide à prendre en charge l'écriture d'API dans Rails.
[~ # ~] modifier [~ # ~]
Vous mentionnez la possibilité que de futurs utilisateurs tiers se connectent à votre site. Cela change votre calcul de rouler votre propre solution Ruby-saml.
La meilleure façon de partager votre API d'authentification est d'implémenter une couche OAuth . Doorkeeper est une solution populaire et devient rapidement la norme pour l'authentification Rails. C'est le support communautaire, la flexibilité et la facilité d'utilisation en font la meilleure solution pour une API d'authentification consommable.
Serveur CAS :
Une page de connexion centrale autonome où l'utilisateur entre ses informations d'identification (c'est-à-dire son nom d'utilisateur et son mot de passe).
CAS prend en charge le protocole SAML 1.1 normalisé principalement pour prendre en charge la libération d'attributs aux clients et la déconnexion unique.
(un tableau dans une base de données SQL, ActiveDirectory/LDAP, des comptes Google, etc.) Compatibilité totale avec le protocole CAS ouvert et multiplateforme (les clients CAS sont mis en œuvre pour un large éventail de plates-formes, y compris PHP, divers Java, .NET, Zope , etc.) Localisation multilingue - RubyCAS-Server détecte automatiquement la langue préférée de l'utilisateur et présente l'interface appropriée.
[~ # ~] saml [~ # ~] : le langage de balisage d'assertion de sécurité est un format de données standard ouvert basé sur XML pour l'échange d'authentification et d'autorisation les données entre les parties, en particulier entre un fournisseur d'identité et un fournisseur de services. L'autorisation SAML est un processus en deux étapes et vous devez implémenter la prise en charge des deux.
OAuth 2.0 :
Le cadre d'autorisation OAuth 2.0 permet à une application tierce d'obtenir un accès limité à un HTTP soit au nom d'un propriétaire de ressource en orchestrant une interaction d'approbation entre le propriétaire de la ressource et le service HTTP, soit en permettant à l'application tierce d'obtenir l'accès en son propre nom.
Remarque importante:
[~ # ~] saml [~ # ~] possède une fonctionnalité qui manque OAuth2 : le jeton SAML contient les informations d'identité de l'utilisateur (en raison de la signature). Avec OAuth2, vous ne retirez pas cela de la boîte, et à la place, le serveur de ressources doit effectuer un aller-retour supplémentaire pour valider le jeton avec le serveur d'autorisation.
D'un autre côté, avec OAuth2, vous pouvez invalider un jeton d'accès sur le serveur d'autorisation et le désactiver pour tout accès ultérieur au serveur de ressources.
Les deux approches ont des fonctionnalités Nice et les deux fonctionneront pour SSO. Nous avons démontré les deux concepts dans plusieurs langues et différents types d'applications. À la fin de la journée, OAuth2 semble être mieux adapté à nos besoins (car il n'y a pas d'infrastructure SAML existante en place pour l'utiliser).
OAuth2 fournit une solution plus simple et plus standardisée qui couvre tous nos besoins actuels et évite l'utilisation de solutions de contournement pour l'interopérabilité avec les applications natives.
Quand dois-je utiliser lequel?
1.Si votre cas d'utilisation implique l'authentification unique (quand au moins un acteur ou participant est une entreprise), utilisez [~ # ~] saml [~ # ~] .
2.Si votre cas d'utilisation implique de fournir un accès (temporaire ou permanent) à des ressources (telles que des comptes, des images, des fichiers, etc.), utilisez OAuth .
3.Si vous devez fournir un accès à une application partenaire ou cliente à votre portail, utilisez [~ # ~] saml [~ # ~] .
4.Si votre cas d'utilisation nécessite une source d'identité centralisée, utilisez [~ # ~] saml [~ # ~] (fournisseur d'identité).
5.Si votre cas d'utilisation implique des appareils mobiles, alors OAuth2 avec une certaine forme de jetons de porteur est approprié.
Anjan.
J'ai utilisé CAS et OAuth dans mon travail. Voici quelques-unes de mes opinions et j'espère pouvoir vous aider.
Fondamentalement
- CAS et SAML visent à résoudre la situation SSO. Et CAS est un service ou un système d'authentification, qui peut prendre en charge le protocole SAML.
- OAuth vise à résoudre l'autorisation et l'authentification.
Et en pratique,
- CAS et SAML agissent tous deux comme une passerelle devant un groupe d'applications qui appartiennent à une seule organisation. Tout comme votre cas.
- OAuth est utilisé pour autoriser et authentifier entre différentes organisations.
Juste mes pensées, et j'espère entendre plus de voix.
Nous avons utilisé CAS et SAML dans notre architecture (application mobile, portail en ligne et microServices) et les deux sont utilisés à des fins différentes. Notre portail en ligne est comme une banque en ligne qui fonctionne dans le domaine public et doit être sécurisé. Nous ne voulons pas stocker de mot de passe et d'autres jetons sécurisés dans la base de données du portail en ligne, par conséquent, nous utilisons CAS pour l'authentification et l'autorisation. Lors de l'inscription, lorsque l'utilisateur choisit le mot de passe, nous stockons le mot de passe dans CAS et stockons le jeton correspondant dans la base de données du portail
Lors de la prochaine connexion de l'utilisateur, l'utilisateur saisit le nom d'utilisateur et le mot de passe dans Portal. Le portail récupère le jeton correspondant à l'utilisateur de la base de données et envoie le nom d'utilisateur, le mot de passe et le jeton au CAS pour validation.
Mais, si l'utilisateur s'est déjà connecté à une application et que nous redirigeons l'utilisateur vers notre autre application, nous ne voulons pas que l'utilisateur saisisse à nouveau le nom d'utilisateur et le mot de passe pour la deuxième application. Nous utilisons SAML pour résoudre ce problème. La première application partage les détails de l'utilisateur avec le serveur SAML et obtient un jeton en retour. La première application passe le jeton à la deuxième application. La deuxième application envoie un jeton au serveur SAML pour obtenir les détails de l'utilisateur et, en cas de réussite, l'utilisateur arrive à la page souhaitée. Notre première application peut être Mobile App et la seconde peut être Portal dans le scénario d'App2Web.
Puisque vous avez beaucoup de réponses à cette question, je voudrais vous suggérer un produit d'identité qui peut répondre à ce type de protocole dans une main avec beaucoup de fonctionnalités d'authentification et de gestion des utilisateurs. Vous pouvez simplement essayer la version WSO2 Identity Server pour cela.