Authentification unique sur plusieurs domaines [fermé]


110

Notre société a plusieurs domaines mis en place avec un site Web hébergé sur chacun des domaines. À ce stade, chaque domaine a sa propre authentification qui se fait via des cookies.

Lorsqu'une personne connectée à un domaine a besoin d'accéder à tout ce qui se trouve à partir de l'autre, l'utilisateur doit se reconnecter en utilisant des informations d'identification différentes sur l'autre site Web, situé sur l'autre domaine.

Je pensais passer à l'authentification unique (SSO), afin d'éliminer ces tracas. J'apprécierais toute idée sur la manière dont cela pourrait être réalisé, car je n'ai aucune expérience à cet égard.

Merci.

Edit: Les sites Web sont un mélange de sites Internet (externes) et intranet (utilisés en interne au sein de l'entreprise).


Cela ressemble à un travail pour OpenID - mais n'autorisez que les identifiants de votre domaine de connexion.
Neall le

2
@Will Cette question n'est peut-être pas pour ce site Web du réseau SE, mais elle est définitivement constructive .
Binar Web

Les raisons de @BinarWeb Close ont évolué depuis 2008. À l'époque, c'était le choix le plus pertinent.

Réponses:


91

La solution SSO que j'ai implémentée ici fonctionne comme suit:

  1. Il existe un domaine maître, login.mydomain.com avec le script master_login.php qui gère les connexions.
  2. Chaque domaine client a le script client_login.php
  3. Tous les domaines ont une base de données de session utilisateur partagée.
  4. Lorsque le domaine client nécessite que l'utilisateur soit connecté, il redirige vers le domaine maître (login.mydomain.com/master_login.php). Si l'utilisateur ne s'est pas connecté au maître, il demande l'authentification de l'utilisateur (c'est-à-dire afficher la page de connexion). Une fois que l'utilisateur est authentifié, il crée une session dans une base de données. Si l'utilisateur est déjà authentifié, il recherche son identifiant de session dans la base de données.
  5. Le domaine maître revient au domaine client (client.mydomain.com/client_login.php) en passant l'ID de session.
  6. Le domaine client crée un cookie stockant l'ID de session du maître. Le client peut trouver l'utilisateur connecté en interrogeant la base de données partagée à l'aide de l'ID de session.

Remarques:

  • L'identifiant de session est un identifiant global unique généré avec l'algorithme de la RFC 4122
  • Le master_login.php ne redirigera que vers les domaines de sa liste blanche
  • Le maître et les clients peuvent être dans différents domaines de premier niveau. Par exemple. client1.abc.com, client2.xyz.com, login.mydomain.com

Cela ressemble à une bonne solution grom. Que stockez-vous dans la base de données? Est-ce (session_id, username, hashed_password)?
Jon M

3
Comment gérez-vous le cas où le domaine maître login.mydomain.com tombe en panne? La connexion est-elle impossible à ce stade?
jjxtra

3
Un organisme a produit des exemples de code ou un dépôt github?
Joshua F.Rountree

C'est ce que presque tous les protocoles SSO (par exemple SAML) spécifient, mais avec plus de sécurité contre les attaques de relecture et ainsi de suite.
cweiske

2
Et s'ils ne partagent pas la base de données des utilisateurs? Chaque application Web partenaire a sa propre base d'utilisateurs. Comment rencontrons-nous cela?
stuckedoverflow

33

Ne réinventez pas la roue. Il existe un certain nombre de packages SSO inter-domaines open source tels que JOSSO, OpenSSO, CAS, Shibboleth et autres. Si vous utilisez la technologie Microsoft partout (IIS, AD), vous pouvez utiliser la fédération Microsoft (ADFS) à la place.


4
Absolument - j'ai vu trop de gens déployer leurs propres solutions de sécurité pour découvrir qu'ils sont vulnérables aux replay, XSRF ou autres attaques

5
+1 Vous ne devriez [presque] jamais réinventer la roue de sécurité.
Mark E. Haase

13
OpenSSO est mort et JOSSO et CAS sont des solutions JAVA. Just an FYI
OneHoopyFrood

15

Dans quelle mesure les noms d'hôte sont-ils différents?

Ces hébergeurs peuvent partager des cookies:

  • mail.xyz.com
  • www.xyz.com
  • logon.xyz.com

Mais ceux-ci ne peuvent pas:

  • abc.com
  • xyz.com
  • www.tre.com

Dans le premier cas, vous pouvez utiliser une solution basée sur les cookies. Pensez GUID et une table de session de base de données.


2

Si vous utilisez Active Directory, chaque application peut utiliser AD pour l'authentification, la connexion peut alors être transparente.

Sinon, si les applications peuvent communiquer entre elles dans les coulisses, vous pouvez utiliser des sessionid et avoir une application gérant la génération d'identifiant pour toutes vos autres applications.


2
L'utilisateur n'est-il pas encore obligé de saisir son nom d'utilisateur et son mot de passe sur domain1.com et domain2.com et domain3.com lorsqu'il atterrit sur ces sites pour la première fois pour cette session?
HaBo
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.