SSO avec CAS ou OAuth?

Je me demande si je devrais utiliser le protocole CAS ou OAuth + un fournisseur d'authentification pour la connexion unique.

Exemple de scénario:

1. Un utilisateur tente d'accéder à une ressource protégée, mais n'est pas authentifié.
2. L'application redirige l'utilisateur vers le serveur SSO.
3. S'il est authentifié, l'utilisateur obtient un jeton du serveur SSO.
4. Le SSO redirige vers l'application d'origine.
5. L'application d'origine vérifie le jeton par rapport au serveur SSO.
6. Si le jeton est correct, l'accès sera autorisé et l'application connaît l'identifiant de l'utilisateur.
7. 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 le CAS a été inventé. Les clients CAS doivent implémenter le protocole CAS pour utiliser le service d'authentification. Maintenant, je me demande comment utiliser CAS ou OAuth sur le site client (consommateur). OAuth remplace-t-il cette partie de CAS? Faut-il privilégier OAuth en tant que nouvelle norme de facto? 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 doivent utiliser quelque chose de semblable à une session.
• Les applications peuvent être des applications Web GUI ou des services (REST).
• Le serveur SSO doit fournir un ID utilisateur, ce 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 utilisateur centrale.
• La déconnexion unique devrait être possible.
• La plupart des clients sont écrits en Java ou PHP.

Je viens de découvrir WRAP , qui pourrait devenir le successeur d'OAuth. Il s'agit d'un nouveau protocole spécifié par Microsoft, Google et Yahoo.

Addenda

J'ai appris qu'OAuth n'était pas conçu pour l'authentification, même s'il pouvait être utilisé pour implémenter SSO, mais uniquement avec un service SSO comme OpenID.

OpenID me semble être le "nouveau CAS". CAS a quelques fonctionnalités qui manquent à OpenID (comme la déconnexion unique), mais il ne devrait pas être trop difficile d'ajouter les pièces 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 des applications ou des serveurs d'applications. Je sais que CAS prend également en charge OpenID, mais je pense que CAS est inutile avec OpenID.

OpenID n'est pas un «successeur» ou un «substitut» pour CAS, ils sont différents, dans l'intention et dans la mise en œuvre.

CAS centralise l' 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 l' authentification. Utilisez-le si vous voulez 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).

Aucune des autorisations ci-dessus ne gère (sans extensions 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 les 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écurisé pour l'utilisateur). L'application demande l'accès à Twitter, l' utilisateur l' autorise (via Twitter), puis l'application peut y avoir accès.

Ainsi, OAuth ne concerne pas l'authentification unique (ni un substitut au protocole CAS). Il est pas vous contrôler ce que l'utilisateur peut accéder. Il s'agit de laisser l' utilisateur contrôler la manière dont ses ressources peuvent être accédées 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.

[actualisé]

Cela dit, vous pouvez implémenter SSO avec OAuth, si vous considérez l'identité de l'utilisateur comme une ressource sécurisée. C'est essentiellement ce que font 'S'inscrire avec GitHub' et les likes. Probablement pas l'intention initiale du protocole, mais cela peut être fait. Si vous contrôlez le serveur OAuth et que vous limitez les applications à s'authentifier uniquement avec lui, c'est SSO.

Aucun moyen standard de forcer la déconnexion, cependant (CAS a cette fonctionnalité).

J'ai tendance à y penser de cette façon:

Utilisez CAS si vous contrôlez / possédez le système d'authentification des utilisateurs et devez prendre en charge un ensemble hétérogène de serveurs et d'applications qui nécessitent 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 l' extension hybride OpenID .

Je préfère fortement voir les gens s'appuyer sur des normes qui ont beaucoup d'élan (plus de support disponible, plus facile d'impliquer des tiers), même s'ils ne correspondent pas exactement à l'application en question. Dans ce cas, OAuth a l'élan, pas CAS. Vous devez être capable de faire tout ou du moins presque tout ce que vous devez faire avec OAuth. À un moment ultérieur dans le futur, OAuth WRAP devrait simplifier davantage les choses (il fait des compromis intéressants en utilisant un jeton porteur et en poussant le cryptage vers la couche de protocole), mais il en est encore à ses balbutiements, et en attendant, OAuth fera probablement très bien le travail.

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 toute autre personne qui doit s'intégrer au système. Vous avez également beaucoup plus de globes oculaires qui examinent les protocoles, pour vous assurer qu'ils sont vraiment aussi sûrs qu'ils sont censés l'être.

Pour moi, la vraie différence entre l' authentification unique et OAuth est subvention, pas d' authentification , car un serveur qui implémente OAuth évidemment a authentification (vous devez être connecté à votre google, openId ou facebook pour qu'OAuth se produise avec l'application cliente)

En SSO, un utilisateur expérimenté / administrateur système accorde à l'utilisateur final l'accès à une application au préalable sur «l'application SSO». Dans OAuth, l'utilisateur final accorde à l'application l'accès à ses «données» sur «l'application OAuth»

Je ne vois pas pourquoi le protocole OAuth ne peut pas être utilisé dans le cadre d'un serveur SSO. Retirez simplement l'écran d'autorisation du flux et laissez le serveur OAuth rechercher l'autorisation à partir de la base de données de sauvegarde.

Ancien message, mais cela pourrait être utile:

CAS 3.5 prendra en charge oAuth en tant que client et serveur. Voir: https://wiki.jasig.org/display/CASUM/OAuth