SSO avec CAS ou OAuth ?

Question

Je me demande si je devrais utiliser le CAS du protocole ou OAuth + certains fournisseur d'authentification pour l'authentification 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 d'authentification unique.
3. Si en étant authentifié l'utilisateur reçoit un jeton à partir du serveur d'authentification unique.
4. La SSO redirige vers l'application d'origine.
5. L'application d'origine vérifie le jeton contre le serveur d'authentification unique.
6. Si le jeton est ok, l'accès sera autorisé et l'application sait de l'id d'utilisateur.
7. L'utilisateur effectue une session et est enregistré dans toutes les applications connectées à la même époque (single sign-out).

Comme je le comprends, c'est exactement ce CAS a été inventé pour. CAS clients ont à mettre en œuvre le CAS du protocole à utiliser le service d'authentification. Maintenant, je me demandais à propos de CAS d'utilisation ou de OAuth au client (consommateur). Est OAuth un remplacement pour la partie de la SAE? Devrait OAuth comme un nouveau standard de facto à privilégier? Est-il facile à utiliser (pas de Soleil OpenSSO!) remplacement pour la partie authentification de CAS à l'appui des différents méthodes comme nom d'utilisateur/mot de passe, OpenID, TLS certifactes ...?

Contexte:

• Différentes applications devrait s'appuyer sur l'authentification du serveur d'authentification unique et utilisez quelque chose de session.
• Les applications peuvent être GUI ou les applications web (REST) services.
• Le serveur d'authentification unique doit être de fournir une identification de l'utilisateur, ce qui est nécessaire pour obtenir plus d'informations sur l'utilisateur comme des rôles, e-mail et ainsi de suite à partir d'un centre d'utilisateur de banque d'informations.
• Single Sign-out devrait être possible.
• La plupart des clients sont écrites en Java ou en PHP.

J'ai juste découvert WRAP, qui pourrait devenir le OAuth successeur. C'est un nouveau protocole spécifié par Microsoft, Google et Yahoo.

Addendum

J'ai appris que ce Protocole n'a pas été conçu pour l'authentification de même, il pourrait être utilisé pour mettre en œuvre l'authentification unique, mais seulement avec un service d'authentification unique comme OpenID.

OpenID me semble être le "nouveau CAS". Le SATJ a certaines fonctionnalités OpenID manque (comme l'authentification unique), mais il ne devrait pas être trop dur d'ajouter les pièces manquantes dans un scénario particulier. Je pense que OpenID a une large acceptation et il est préférable d'intégrer OpenID dans des applications ou des serveurs d'application. Je sais que le TAS prend également en charge OpenID, mais je pense que TAS est pas indispensable avec OpenID.

Answer 1

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

CAS centralise l'authentification. Utilisez cette option si vous souhaitez que tous vos (probablement interne) des applications pour demander à l'utilisateur de se connecter à un serveur unique (toutes les applications sont configurées pour pointer vers un seul serveur CAS).

OpenID decentralizes d'authentification. Utilisez cette option si vous voulez que votre demande d'accepter de connexion des utilisateurs à ce que le 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).

Aucune de gérer l'autorisation (sans les extensions et/ou de personnalisation).

OAuth poignées d'autorisation, mais il n'est pas un substitut pour le traditionnel "USER_ROLES table" (accès utilisateur). Il gère l'autorisation pour des tiers.

Par exemple, vous souhaitez que votre candidature pour intégrer Twitter: un utilisateur pourrait lui permettre de tweeter automatiquement lors de la mise à jour de leurs données ou de poster de nouveau contenu. Vous souhaitez accéder à certains services par des tiers ou des ressources sur le compte d'un utilisateur, sans obtenir son mot de passe (ce qui est évidemment dangereux pour l'utilisateur). L'application demande à Twitter pour l'accès, l' utilisateur autorise (via Twitter), puis l'application peut avoir accès.

Donc, OAuth est pas Sur la connexion Unique (ni un substitut pour le CAS du protocole). Il n'est pas à propos de vous contrôler ce que l'utilisateur peut accéder. Il s'agit de laisser l' utilisateur de contrôler la façon dont leurs ressources peuvent être consultées par des tiers. Deux très différents cas d'utilisation.

Pour le contexte que vous avez décrits, CAS est probablement le bon choix.

Answer 2

J’ai tendance à pensez-y de cette façon :

Utiliser l’EDC si vous contrôle/propre système d’authentification de l’utilisateur et devez prendre en charge un ensemble hétérogène des serveurs et des applications nécessitant une authentification centralisée.

Utiliser OAuth si vous souhaitez prendre en charge l’authentification utilisateur de systèmes que vous ne possédez/soutien (c’est à dire, Google, Facebook, etc.).

Answer 3

OpenID est un protocole d'authentification OAuth et OAuth WRAP sont d'autorisation de protocoles. Ils peuvent être combinés avec l' hybride OpenID extension.

J'avais fortement préfère voir les gens à s'appuyer sur des normes qui ont beaucoup d'élan (plus de soutien disponibles, plus facile d'obtenir des tierces parties impliquées), même si elles ne sont pas un ajustement exact pour l'application à la main. Dans ce cas, OAuth a de l'élan, pas CAS. Vous devriez être en mesure de faire tout ou au moins presque tout ce que vous devez faire avec OAuth. À un moment plus tard dans l'avenir, OAuth ENVELOPPER de simplifier encore plus les choses (il fait de la peine un compromis à l'aide d'un porteur du jeton et en poussant de cryptage jusqu'à la couche de protocole), mais il est encore dans son enfance, et dans l'intervalle, OAuth va probablement faire le travail tout aussi bien.

En fin de compte, si vous choisissez d'utiliser OpenID et OAuth, il y a plus de bibliothèques de plus de langues disponibles, à vous et à personne d'autre qui en a besoin pour s'intégrer avec le 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.

Answer 4

Pour moi, la vraie différence entre SSO et OAuth est de subvention, pas d'authentification parce qu'un serveur qui implémente le protocole OAuth évidemment a d'authentification (vous devez être connecté à votre compte google, openId ou facebook pour OAuth pour se produire avec le client app)

Dans l'authentification unique, un utilisateur de puissance/sysadmin accorde à l'utilisateur final d'accéder à une demande à l'avance sur le "SSO app" Dans OAuth, final utilisateur accorde l'accès de l'application à ses "données" sur le "OAuth app"

Je ne vois pas pourquoi protocole d'authentification OAuth ne pouvait pas être utilisé comme partie d'un serveur d'authentification unique. Il suffit de prendre la subvention de l'écran de l'écoulement et de laisser le serveur OAuth la recherche de la subvention de la sauvegarde de la db.

(mes 2 cents)

Answer 5

Vieux post, mais cela pourrait être utile :

3.5 CAS soutiendra oAuth comme Client et serveur. Voir : https://wiki.jasig.org/display/CASUM/OAuth