web-dev-qa-db-fra.com

Connexion entre domaines - Comment connecter automatiquement un utilisateur lorsqu'il est transféré d'un domaine à un autre

Nous offrons un certain nombre de services en ligne. Nous sommes tenus de développer un système qui offre une expérience simple/rapide aux utilisateurs s'ils sont transférés d'un service (le domain1.com) vers un autre service (le domain2.com).

Existe-t-il un moyen sûr et sécurisé de se connecter automatiquement à un utilisateur une fois qu'il a été transféré au nouveau service?

Criez-moi si la solution ci-dessous est complètement précaire/erronée.

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 - ils reçoivent par e-mail un lien avec un hachage unique qui expire, qui leur permet de changer leur mot de passe.

Le domain1.com le site générerait un hachage unique et le stockerait dans une base de données avec le hachage lié à un utilisateur avec un champ datetime expirant.

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

domain2.com ferait ensuite une demande à domain1.com avec le hachage pour obtenir les informations sur l'utilisateur. domain1.com supprimerait alors le hachage de la base de données. domain2.com permettrait de connecter l'utilisateur et de définir des cookies, etc.

Quelque chose basé sur OpenID ou OAuth pourrait-il obtenir les mêmes résultats?

securityauthenticationdnssingle-sign-on
48
smashedmercury

Authentification unique (SSO) est conceptuellement assez simple.

  • L'utilisateur frappe domain1.com.
  • domain1.com voit qu'il n'y a pas de cookie de session.
  • domain1.com redirige vers sso.com
  • sso.com présente la page de connexion et prend les informations d'identification
  • sso.com définit un cookie de session pour l'utilisateur
  • sso.com puis redirige vers domain1 vers une URL spéciale (comme domain1.com/ssologin)
  • l'URL ssologin contient un paramètre qui est essentiellement "signé" par le sso.com. Il pourrait être aussi simple qu'une base64 de chiffrer l'identifiant de connexion à l'aide d'une clé secrète partagée.
  • domain1.com prend le jeton chiffré, le déchiffre, utilise le nouvel identifiant de connexion pour se connecter à l'utilisateur.
  • domain1 définit le cookie de session pour l'utilisateur.

Maintenant, le prochain cas.

  • L'utilisateur frappe domain2.com, qui suit domain1 et redirige vers sso.com
  • sso.com possède déjà un cookie pour l'utilisateur, donc ne présente pas la page de connexion
  • sso.com redirige vers domain2.com avec les informations cryptées
  • domain2.com connecte l'utilisateur.

Voilà les principes fondamentaux de la façon dont cela fonctionne. Vous pouvez le rendre plus robuste, plus riche en fonctionnalités (par exemple, c'est SSOn, mais pas SSOff, l'utilisateur peut se "déconnecter" de domain1, mais toujours connecté à domain2). Vous pouvez utiliser clés publiques pour signer les informations d'identification, vous pouvez avoir des demandes pour transférer plus d'informations (comme les droits d'autorisation, etc.) à partir du serveur SSO. Vous pouvez avoir une intégration plus intime, comme les domaines vérifiant régulièrement que l'utilisateur dispose toujours des droits du serveur SSO.

Mais la prise de contact avec les cookies via le navigateur à l'aide de redirections est le fondement clé sur lequel toutes ces solutions SSO sont basées.

124
Will Hartung

Si quelqu'un pouvait jouer l'homme au milieu et saisir ce hachage, serait-il capable de voler le transfert entre domaines? De toute évidence, il doit être généré et envoyé au client avant qu'il ne doive l'utiliser. Alors dites par exemple:

Je joue l'homme au milieu en espionnant Jack. Jack accède à domain1.com ce qui permet de préparer et de lui envoyer un hachage afin que lorsqu'il accède à domain2.com il peut envoyer ce hachage comme authentification. Lorsqu'il accède à domain1.com, sa demande me parvient, vous retournez la page, j'attrape le hachage et le laisse continuer. J'accède à domain2.com en utilisant le hachage, vous m'avez maintenant laissé entrer domain2.com et a supprimé le hachage. Il n'est pas plus sage jusqu'à ce qu'il tente de se connecter à domain2.com et apprend que ses informations d'identification ne sont plus valides.

Comment surmontez-vous cela?

8
BenAlabaster

Il ne servirait à rien d'utiliser SSL pour la connexion interdomaine à moins que vous n'utilisiez SSL pour toute la session. Il est tout aussi facile de voler un cookie de session que d'utiliser un hachage dans une URL. Quel est l'intérêt de masquer le hachage dans 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 une tout autre affaire, mais il serait inutile de ne crypter qu'une partie de la session.

7
Paul

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

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

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

6
erickson

Et le référencement? Il ressemble à chaque demande avant que la connexion réussie soit redirigée vers un autre domaine et vice-versa. Je dirais que c'est très moche. Quels en-têtes devez-vous envoyer? 301 vers SSO, puis revenir 301 à la page d'origine? Donc, le robot de recherche est "invité" à modifier son index pour cette page deux fois?

2
pixo