SSO avec CAS ou OAuth?
je me demande si je devrais utiliser le protocole CAS ou OAuth + un fournisseur d'authentification pour une seule connexion.
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.
- S'il est authentifié, l'utilisateur obtient un token de L'OSP serveur.
- le SSO renvoie à la demande initiale.
- l'application originale vérifie le token par rapport au serveur SSO.
- Si le jeton est ok, l'accès sera autorisé et l'application sait de l'id d'utilisateur.
- l'utilisateur effectue une déconnexion et est déconnecté de toutes les applications connectées en même temps (une seule déconnexion).
autant que je sache, c'est exactement ce pour quoi CAS a été inventé. Les clients des SAE doivent mettre en œuvre le protocole des SAE pour utiliser le service d'authentification. Maintenant je me demande si je vais utiliser CAS ou OAuth sur le site client (consommateur). OAuth remplace-t-il cette partie de la SAE? Faut-il privilégier la norme OAuth en tant que nouvelle norme de facto? Y at-il un facile à utiliser (Pas Sun OpenSSO!) remplacement de la partie authentification de CAS supportant différentes méthodes comme username / password, OpenID, TLS certifactes ...?
contexte:
- différentes applications doivent reposer sur l'authentification du serveur SSO et doivent utiliser quelque chose comme une session.
- les applications peuvent être GUI web applications ou (REST) serivces.
- le serveur SSO doit fournir un ID utilisateur, ce qui est nécessaire pour obtenir plus d'informations sur les rôles de l'utilisateur, le courrier électronique et ainsi de suite à partir d'un magasin central d'information utilisateur.
- une seule sortie 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 OAuth. Il s'agit d'un nouveau protocole spécifié par Microsoft, Google et Yahoo.
Addendum
j'ai appris Qu'OAuth n'a pas été conçu pour l'authentification même s'il pouvait être utilisé pour mettre en œuvre SSO, mais seulement avec un SSO service comme OpenID.
OpenID me semble être le"new CAS". CAS a quelques caractéristiques OpenID manque (comme une sortie unique), mais il ne devrait pas être trop difficile d'ajouter les parties manquantes dans un scénario particulier. Je pense Qu'OpenID est largement accepté et qu'il est préférable d'intégrer OpenID dans les applications ou les serveurs d'applications. Je sais que le CAS supporte aussi L'OpenID, mais je pense que le CAS est superflu avec L'OpenID.
5 réponses
OpenID n'est pas un "successeur" ou un "substitut" des AC, ils sont différents, dans leur intention et leur mise en œuvre.
CAS centralise authentification. Utilisez - le si vous voulez 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 decentralizes authentication. Utilisez - le si vous voulez votre application accepter que les utilisateurs se connectent à n'importe quel service d'authentification qu'ils veulent (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 traite l'autorisation (sans extension et/ou personnalisation).
OAuth gère l'autorisation, mais il ne remplace pas la traditionnelle 'table USER_ROLES' (accès utilisateur). Il gère l'autorisation pour des tiers.
Par exemple, vous voulez votre application à intégrer à Twitter: un utilisateur pourrait lui permettre de tweeter automatiquement lors de la mise à jour de ses données ou de l'affichage de nouveaux contenus. Vous souhaitez accéder à un service ou à une ressource tiers au nom d'un utilisateur, sans obtenir son mot de passe (ce qui est évidemment non sécurisé pour l'utilisateur). L'application demande L'accès à Twitter, l'utilisateur 151940920" l'autorise (via Twitter), et l'application peut y avoir accès.
ainsi, OAuth n'est pas à propos D'une seule inscription (ni un substitut au Protocole des SAE). Il ne s'agit pas de vous contrôler ce que l'utilisateur peut accéder. Il s'agit de laisser l'utilisateur 151940920 "contrôler comment leurs ressources peuvent être accessibles par des tiers. Deux cas d'utilisation très différents.
dans le contexte que vous avez décrit, CAS est probablement le bon choix.
[mise à jour]
cela dit, vous peut implémenter SSO avec OAuth, si vous considérez l'identité de l'utilisateur comme une ressource sécurisée. C'est ce que "S'inscrire avec GitHub" et les autres font, en gros. Probablement pas l'intention initiale du protocole, mais il peut être fait. Si vous contrôlez le serveur OAuth, et restreignez les applications à seulement authentifier avec elle, c'est SSO.
aucun moyen standard de forcer la déconnexion, cependant (CAS a cette caractéristique).
j'ai tendance à penser de cette façon:
utilisez CAS si vous contrôlez/possédez le système d'authentification de l'utilisateur et avez besoin de supporter un ensemble hétérogène de serveurs et d'applications qui ont besoin d'authentification centralisée.
utilisez OAuth si vous voulez prendre en charge l'authentification de l'utilisateur à partir de systèmes que vous ne possédez pas/ne prenez pas en charge (Google, Facebook, etc.).
OpenID est un protocole d'authentification, OAuth et OAuth WRAP sont des protocoles d'autorisation. Ils peuvent être combinés avec l'extension OpenID hybride .
je préférerais fortement voir des gens construire sur des normes supérieures qui ont beaucoup d'élan (plus de soutien disponible, plus facile à obtenir des tiers impliqués), même si elles ne sont pas un ajustement exact pour l'application à portée de main. Dans ce cas, C'est OAuth qui a le vent en poupe, pas le tas. Vous devriez être en mesure de faire tout ou au moins presque tout ce que vous devez faire avec OAuth. Plus tard dans l'avenir, OAuth WRAP devrait simplifier davantage les choses (il fait quelques compromis valables en utilisant un jeton porteur et en poussant le cryptage jusqu'à la couche de protocole), mais il est encore à ses balbutiements, et en attendant, OAuth fera probablement le travail très bien.
en fin de compte, si vous choisissez D'utiliser OpenID et OAuth, il y a plus de bibliothèques pour plus de langues disponibles pour vous et pour tous ceux qui ont besoin de s'intégrer au système. Vous avez également beaucoup plus de globes oculaires en regardant les protocoles, en s'assurant qu'ils sont vraiment sécurisé comme ils sont censés être.
Vieux post, mais cela peut ê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 grant, pas authentification parce qu'un serveur qui implémente OAuth de toute évidence a authentification (vous devez être connecté à votre google, openId ou facebook pour que OAuth se produise avec l'application client)
dans SSO, un power user / sysadmin accorde à l'utilisateur final l'accès à une application préalablement sur l'application SSO" L'utilisateur final accorde à la demande L'accès à ses "données" sur le site app "
Je ne vois pas pourquoi le protocole OAuth ne pourrait pas être utilisé comme partie d'un serveur SSO. Il suffit de sortir l'écran de subvention du flux et de laisser le serveur de OAuth regarder la subvention de la DB de soutien.