security services SSO avec CAS ou OAuth?




serveur cas (4)

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. Si elle est authentifiée, l'utilisateur reçoit un jeton du serveur SSO.
  4. L'authentification unique redirige vers l'application d'origine.
  5. L'application d'origine vérifie le jeton sur le serveur SSO.
  6. Si le jeton est correct, l'accès sera autorisé et l'application connaîtra 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 qui a été inventé par CAS. Les clients CAS doivent implémenter le protocole CAS pour utiliser le service d'authentification. Maintenant je m'interroge sur l'utilisation de CAS ou OAuth sur le site client (consommateur). OAuth remplace-t-il cette partie de CAS? OAuth devrait-il être préféré en tant que nouveau standard de facto? Existe-t-il un remplacement facile à utiliser (pas Sun OpenSSO!) Pour la partie authentification de CAS qui supporte différentes méthodes comme nom d'utilisateur / mot de passe, OpenID, TLS certifie ...?

Le contexte:

  • Différentes applications devraient s'appuyer sur l'authentification du serveur SSO et devraient utiliser quelque chose comme une session.
  • Les applications peuvent être des applications web GUI ou des services (REST).
  • Le serveur SSO doit fournir un identifiant utilisateur, qui est nécessaire pour obtenir plus d'informations sur les rôles de l'utilisateur, les e-mails, etc. à partir d'un magasin d'informations utilisateur central.
  • La déconnexion unique devrait être possible.
  • La plupart des clients sont écrits en Java ou en PHP.

Je viens de découvrir WRAP , qui pourrait devenir le successeur d'OAuth. C'est 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 seulement avec un service SSO comme OpenID.

OpenID me semble être le "nouveau CAS". CAS a certaines fonctionnalités manquées par OpenID (comme la déconnexion unique), mais il ne devrait pas être 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 des applications ou des serveurs d'applications. Je sais que CAS prend également en charge OpenID, mais je pense que CAS est dispensable 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 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 serveur CAS unique).

OpenID décentralise l' authentification. Utilisez-le si vous voulez que votre application accepte que les utilisateurs se connectent au service d'authentification qu'ils souhaitent (l'utilisateur fournit l'adresse du serveur OpenID - en fait, le 'nom d'utilisateur' est l'URL du serveur).

Aucun de ces éléments ne gère les autorisations (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 l'autorisation pour les tiers.

Par exemple, vous souhaitez que votre application s'intègre à Twitter: un utilisateur peut l'autoriser à tweeter automatiquement lorsqu'il met à jour ses données ou publie du nouveau contenu. Vous souhaitez accéder à un service ou une ressource tiers pour le compte d'un utilisateur, sans avoir obtenu son mot de passe (ce qui n'est évidemment pas sûr pour l'utilisateur). L'application demande à Twitter pour l'accès, l' utilisateur l' autorise (via Twitter), puis l'application peut avoir accès.

Ainsi, OAuth ne concerne pas Single Sign-On (ni un substitut au protocole CAS). Il ne s'agit pas de 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 consultées par des tiers. Deux cas d'utilisation très différents.

Au 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 ce que «Inscrivez-vous avec GitHub» et les goûts, fondamentalement. Probablement pas l'intention originale du protocole, mais cela peut être fait. Si vous contrôlez le serveur OAuth et que vous restreignez les applications pour qu'elles s'authentifient uniquement avec, c'est l'authentification unique.

Il n'existe cependant pas de moyen standard de forcer la déconnexion (CAS a cette fonctionnalité).



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

En SSO, un utilisateur de pouvoir / sysadmin accorde à l'utilisateur final l'accès à une application à l'avance sur "l'application SSO" Dans OAuth, l'utilisateur final accorde l'accès de l'application à ses "données" sur "l'application OAuth"

Je ne vois pas pourquoi le protocole OAuth ne pourrait pas être utilisé dans le cadre d'un serveur SSO. Il suffit de retirer l'écran d'attribution du flux et de laisser le serveur OAuth rechercher la subvention à partir de la base de données db.

(mes 2 cents)


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érerais fortement voir les gens s'appuyer sur des normes qui ont beaucoup d'élan (plus de soutien disponible, plus facile d'impliquer des tiers), même si elles ne correspondent pas exactement à l'application en question. Dans ce cas, OAuth a l'élan, pas CAS. Vous devriez être capable de faire tout ou au moins 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 de support et en poussant le chiffrement vers la couche de protocole), mais il n'en est encore qu'à 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 d'intégrer le système. Vous avez également beaucoup plus de regard sur les protocoles, en s'assurant qu'ils sont aussi sûrs qu'ils sont censés être.







cas