Cross Domain Login - Comment connecter automatiquement un utilisateur lors du transfert d'un domaine à un autre

Question

Nous offrons un certain nombre de services en ligne. Nous sommes tenus d'élaborer un système qui fournit un moyen rapide/simple d'expérience pour les utilisateurs, s'ils sont transférés d'un service (en domain1.com) à un autre service (en domain2.com).

Est-il un moyen sûr et sécurisé pour une session automatiquement un utilisateur automatiquement une fois qu'il a été transféré au nouveau service?

Crier à moi si la solution ci-dessous est complètement précaire, mal.

Nous envisagions un système similaire à celui fourni par un certain nombre de services en ligne pour la récupération de mot de passe - elles sont envoyées par email un lien avec un hachage unique, qui expire, qui leur permet de changer leur mot de passe.

L' domain1.com permettrait de générer un hachage unique, et de les stocker dans une base de données avec le hachage lié à un utilisateur avec une expiration champ datetime.

L'utilisateur sera transféré à l' domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e

domain2.com prochaine faire une demande d' domain1.com avec le hash pour obtenir les informations sur l'utilisateur. domain1.com serait alors supprimer le hachage de la base de données. domain2.com se connectent à l'utilisateur et de mettre en cookie etc.

Quelque chose basé sur OpenID ou OAuth d'atteindre les mêmes résultats?

Answer 1

Single sign-on (SSO) est conceptuellement assez simple.

• L'utilisateur frappe domain1.com.
• domain1.com y voit aucun cookie de session.
• domain1.com redirige vers sso.com
• sso.com présente page de connexion, et de prendre des informations d'identification
• sso.com jeux de cookie de session de l'utilisateur
• sso.com redirige ensuite retour à l' domain1 d'une url (comme domain1.com/ssologin)
• l' ssologin l'URL contient un paramètre qui est fondamentalement "signé" par l' sso.com. Il pourrait être aussi simple que d'une base64 de cryptage de l'identifiant de connexion à l'aide d'une clé secrète partagée.
• domain1.com prend le jeton crypté, déchiffre, utilise l'id de connexion pour vous connecter à l'utilisateur.
• domain1 définit le cookie de session de l'utilisateur.

Maintenant, le cas suivant.

• L'utilisateur frappe domain2.com, ce qui suit domain1 vers sso.com
• sso.com a déjà un cookie de l'utilisateur, de façon à ne pas présenter la page de connexion
• sso.com redirige retour à l' domain2.com avec les informations chiffrées
• domain2.com connecte l'utilisateur.

Qui sont les fondements de la façon dont cela fonctionne. Vous pouvez la rendre plus robuste, plus riche en fonctionnalités (par exemple, c'est SSOn, mais pas SSOff, l'utilisateur peut "log out" de l' domain1, mais encore être connecté pour domain2). Vous pouvez utiliser des clés publiques pour la signature d'informations d'identification, vous pouvez faire les demandes de transfert de plus d'informations (comme les droits d'autorisation, etc) à partir du serveur d'authentification unique. Vous pouvez avoir plus intime de l'intégration, tels que les domaines de systématiquement vérifier que l'utilisateur a toujours les droits du serveur d'authentification unique.

Mais le cookie poignée de main via le navigateur en utilisant des redirections est la clé de la fondation sur laquelle l'ensemble de ces SSO solutions sont basées.

Answer 2

Si quelqu'un a la possibilité de jouer l'homme dans le milieu et de saisir que de hachage, seraient-ils capables de voler la croix de transfert de domaine? Évidemment, il doit être généré et envoyé au client avant d'avoir besoin de l'utiliser. Donc, dire par exemple:

Je suis en train de jouer l'homme dans le milieu de l'espionnage sur Jack. Jack accède domain1.com ce qui provoque un hachage être préparé et envoyé à lui afin que, lorsqu'il accède domain2.com il peut envoyer que de hachage que l'authentification. Comme il accède domain1.comde sa requête en moi, de vous renvoyer à la page, je prends le hachage et de le laisser continuer. - Je accéder domain2.com à l'aide de la table de hachage, vous avez maintenant, laissez-moi en domain2.com et supprimé le hachage. Il est pas plus sage jusqu'à ce qu'il tente de s'identifier à l' domain2.com et il est dit que ses pouvoirs ne sont plus valides.

Comment faites-vous face à cela?

Answer 3

L'utilisation de SSL pour la connexion entre domaines ne servirait à rien, sauf si vous utilisez SSL pour toute la session. Il est aussi facile de voler un cookie de session que d'utiliser un hash dans une URL. À quoi sert-il de cacher le hachage en SSL si le reste de la session n’est pas sécurisé?

La méthode indiquée en haut est à peu près la méthode standard. Que vous choisissiez d'utiliser des protocoles sécurisés est un tout autre problème, mais il ne servirait à rien de ne chiffrer qu'une partie de la session.

Answer 4

C'est une bonne solution. Voici deux points à considérer:

Vous utilisez le terme "hash", mais les données que vous allez hacher ne sont pas claires. Au lieu de cela, utilisez un "nonce": un grand nombre (128 bits) généré par un RNG de qualité cryptographique.

En outre, vous ne l'avez pas précisé, mais les communications entre l'utilisateur et les deux domaines, ainsi qu'entre les domaines eux-mêmes, doivent être sécurisées. Utilisez SSL pour authentifier les serveurs et garder le nonce confidentiel.

Answer 5

Qu'en est-il du référencement? Il semble que chaque demande avant que la connexion réussie soit redirigée vers un autre domaine et inversement. Je dirais que c'est très moche. Quels en-têtes devriez-vous envoyer? 301 à SSO puis 301 à la page d'origine? Alors, le moteur de recherche est-il "invité" à changer son index pour cette page deux fois?