SSO avec CAS ou OAuth?
Je me demande si je devrais utiliser le protocole CAS ou OAuth + un fournisseur d'authentification pour l'authentification unique.
Exemple de scénario:
- Un utilisateur tente d'accéder à une ressource protégée, mais n'est pas authentifié.
- L'application redirige l'utilisateur vers le serveur SSO.
- Si authentifié, l'utilisateur reçoit un jeton du serveur SSO.
- Le SSO redirige vers l'application d'origine.
- L'application d'origine vérifie le jeton par rapport au serveur SSO.
- Si le jeton est correct, l'accès sera autorisé et l'application connaît l'identifiant de l'utilisateur.
- L'utilisateur effectue une déconnexion et est déconnecté de toutes les applications connectées en même temps (déconnexion unique).
Autant que je sache, c'est exactement ce pour quoi la SCS a été inventée. Les clients CAS doivent implémenter le protocole CAS pour utiliser le service d'authentification. Maintenant, je me demande si vous souhaitez utiliser CAS ou OAuth sur le site client (consommateur). OAuth remplace-t-il cette partie de CAS? Est-ce que OAuth en tant que nouveau standard de facto devrait être préféré? Existe-t-il un remplacement facile à utiliser (pas Sun OpenSSO!) Pour la partie authentification de CAS prenant en charge différentes méthodes telles que nom d'utilisateur/mot de passe, OpenID, certifactes TLS ...?
Le contexte:
- Différentes applications doivent s'appuyer sur l'authentification du serveur SSO et utiliser un type de session.
- Les applications peuvent être des applications Web GUI ou des services (REST).
- Le serveur SSO doit fournir un ID utilisateur, qui est nécessaire pour obtenir plus d'informations sur l'utilisateur, telles que les rôles, le courrier électronique, etc., à partir d'une banque d'informations centralisée.
- La déconnexion unique devrait être possible.
- La plupart des clients sont écrits en Java ou en PHP.
Je viens de découvert WRAP , qui pourrait devenir le successeur de OAuth. C'est un nouveau protocole spécifié par Microsoft, Google et Yahoo.
Addendum
J'ai appris que OAuth n'était pas conçu pour l'authentification, même s'il pouvait être utilisé pour implémenter l'authentification unique, mais uniquement avec un service d'authentification unique comme OpenID.
OpenID me semble être le "nouveau CAS". CAS présente certaines fonctionnalités manquantes à OpenID (comme la déconnexion unique), mais il ne devrait pas être trop difficile d’ajouter les éléments manquants dans un scénario particulier. Je pense qu'OpenID est largement accepté et qu'il est préférable d'intégrer OpenID dans des applications ou des serveurs d'applications. Je sais que CAS prend également en charge OpenID, mais je pense que CAS ne nécessite pas OpenID.
OpenID n'est pas un "successeur" ou un "substitut" de CAS, ils sont différents, d'intention et de mise en œuvre.
CAS centralise authentification. Utilisez-le si vous souhaitez que toutes vos applications (probablement internes) demandent aux utilisateurs de se connecter à un seul serveur (toutes les applications sont configurées pour pointer vers un seul serveur CAS).
OpenID décentralise authentification. Utilisez-le si vous souhaitez que votre application accepte que les utilisateurs se connectent au service d'authentification de leur choix (l'utilisateur fournit l'adresse du serveur OpenID - en fait, le 'nom d'utilisateur' est l'URL du serveur).
Aucun des éléments ci-dessus ne gère l'autorisation (sans extensions et/ou personnalisation).
OAuth gère les autorisations, mais ne remplace pas la traditionnelle "table USER_ROLES" (accès utilisateur). Il gère les autorisations pour des tiers.
Par exemple, vous souhaitez que votre application s'intègre à Twitter: un utilisateur peut lui permettre de tweeter automatiquement lorsqu'il met à jour ses données ou publie un nouveau contenu. Vous souhaitez accéder à un service ou à une ressource tiers pour le compte d'un utilisateur, sans obtenir son mot de passe (ce qui n'est évidemment pas sûr pour l'utilisateur). L'application demande un accès à Twitter, le utilisateur l'autorise (via Twitter), puis l'application peut y avoir accès.
Donc, OAuth ne concerne pas l'authentification unique (ni un substitut du protocole CAS). Il ne s'agit pas de vous contrôler ce à quoi l'utilisateur peut accéder. Il s’agit de laisser les utilisateurs contrôler comment les ressources leurs peuvent être consultées par des tiers. Deux cas d'utilisation très différents.
Compte tenu du contexte que vous avez décrit, le CAS est probablement le bon choix.
[mise à jour]
Cela dit, vous pouvez implémenter l'authentification unique avec OAuth, si vous considérez l'identité de l'utilisateur comme une ressource sécurisée. C’est ce que "Inscrivez-vous avec GitHub" et les "j'aime", en gros. Probablement pas l'intention initiale du protocole, mais cela peut être fait. Si vous contrôlez le serveur OAuth et si vous limitez l'authentification des applications, il s'agit de la connexion unique.
Pas de moyen standard pour forcer la déconnexion (CAS dispose de cette fonctionnalité).
J'ai tendance à penser de cette façon:
Utilisez CAS si vous contrôlez/possédez le système d'authentification d'utilisateur et devez prendre en charge un ensemble hétérogène de serveurs et d'applications nécessitant une authentification centralisée.
Utilisez OAuth si vous souhaitez prendre en charge l’authentification des utilisateurs à partir de systèmes que vous ne possédez pas/ne supportez pas (par exemple Google, Facebook, etc.).
OpenID est un protocole d'authentification, OAuth et OAuth WRAP sont des protocoles d'autorisation. Ils peuvent être combinés avec extension hybride OpenID .
Je préférerais vivement que les personnes s'appuyant sur des normes très dynamiques (soutien plus important, implication plus facile des tiers), même si elles ne correspondent pas parfaitement à l'application envisagée. Dans ce cas, OAuth a l'élan, pas le CAS. Vous devriez être capable de faire tout ou presque tout ce que vous devez faire avec OAuth. À un moment ultérieur. , OAuth) WRAP devrait simplifier davantage les choses (il fait des compromis intéressants en utilisant un jeton porteur et en poussant le cryptage vers le niveau de protocole), mais il en est encore à ses balbutiements et entre-temps , OAuth fera probablement l'affaire très bien.
En fin de compte, si vous choisissez d'utiliser OpenID et OAuth, vous disposerez d'un plus grand nombre de bibliothèques pour davantage de langues, ainsi que de toute autre personne devant intégrer le système. Vous avez également beaucoup plus de regards en regardant les protocoles, en vous assurant qu'ils sont aussi sécurisés qu'ils sont supposés l'être.
Ancien post, mais cela pourrait être utile:
CAS 3.5 supportera oAuth en tant que client et serveur. Voir: https://wiki.jasig.org/display/CASUM/OAuth
Pour moi, la vraie différence entre SSO et OAuth est une autorisation, pas une authentification, car un serveur qui implémente OAuth évidemment a authentification ( vous devez être connecté à votre google, openId ou facebook pour OAuth pour passer avec l'application client)
Dans SSO, un utilisateur privilégié/sysadmin accorde préalablement à l'utilisateur final l'accès à une application sur "l'application SSO". Dans OAuth, l'utilisateur final accorde l'accès à ses "données" à l'application "OAuth".
Je ne vois pas pourquoi OAuth ne pourrait pas être utilisé dans le cadre d'un serveur SSO. Retirez simplement l'écran d'octroi du flux et laissez le OAuth = serveur recherche l'octroi de la base de données de sauvegarde.