web-dev-qa-db-fra.com

Comment configurer une connexion unique pour plusieurs domaines?

J'ai mis en place une connexion unique pour deux de nos sites qui vivent sur le même domaine: a.domain.com et b.domain.com

Je l'ai fait via des cookies, mais ils dépendent du domaine. Et - comme il est écrit dans le Grand Livre - maintenant la nécessité d'une connexion unique sur différents domaines a soulevé sa tête laide :) Je suis sûr à 99% que je peux oublier d'utiliser OpenId (ils n'aiment pas les services externes ici, je ne pouvais même pas les amener à accepter reCaptcha )

Je voudrais pouvoir identifier quelqu'un sur différents sites Web (a.domain.com, b.anotherdomain.com, etc.). Quels sont les moyens recommandés pour configurer/gérer l'authentification unique sur plusieurs domaines? Y a-t-il des problèmes de sécurité spécifiques que je devrais connaître avant de rédiger une proposition?

authenticationauthenticationsso
21
samy

La manière dont l'authentification unique a été implémentée pour le Stack Exchange Network est très intéressante. Il utilise HTML 5 Local Storage . Selon la prise en charge du navigateur dont vous avez besoin, vous pouvez peut-être utiliser une méthode similaire.

Vous pouvez consulter l'article de blog stackoverflow Global Network Auto Login pour plus de détails.

16
Mark Davidson

Vous n'êtes pas obligé d'utiliser un service externe pour OpenId. Vous pouvez héberger un serveur OpenId en interne et l'utiliser pour votre SSO. Cela vous permettrait de tirer parti du code open source et de tout le travail effectué pour sécuriser OpenId.

PS: OpenId peut être utilisé pour avoir une identité unique utilisée par de nombreux sites mais vous devez toujours vous connecter "manuellement" sur chaque domaine.

5
Olivier Lalonde

Deux bons protocoles pour cela sont OAuth (http://en.wikipedia.org/wiki/OAuth) et SAML. Vous pouvez exécuter votre propre site "fournisseur d'identité", en utilisant OpenID ou une autre authentification approches.

5
nealmcb

Peut-être que ADFSv2 (téléchargement gratuit pour Windows 2008R2) vous aidera avec le cookie de domaine commun. Voici un extrait du web.config situé dans C:\inetpub\adfs\ls que vous devrez configurer pour obtenir l'effet souhaité.

  <!--
    Common domain cookie. A common domain cookie stores a list of recently visited Claims Providers 
    (also called Identity Providers), as described in Section 4.3.1 of Profiles for the OASIS Security 
    Assertion Markup Language (SAML) V2.0. It is recommended that you enable common domain cookies by 
    including the <commonDomainCookie> element in the web.config file.

      1.The writer attribute of the <commonDomainCookie> element specifies the address of the writer 
      service that a Claims Provider uses to set the common domain cookie once it has authenticated a user.
      This address should be a valid URL.
      2.The reader attribute of the the <commonDomainCookie> element specifies the address of the reader
      service that a claims-aware service (also called a Service Provider) uses to get the list of Claims
      Providers that it should present to the user. This address should be a valid URL.

      The following configuration enables the use of common domain cookies and specifies writer and reader 
      services as described previously. 

      A common Domain Cookie is named "_saml_idp" in 4.3.1 http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
      Space delimited URI encoded

      RULES:
      Must be secure
      Must have path = /
      Must be leading period as in .domain.com 
      Can be session or persistant
      All providers should be configured similarly
      TODO-->
    <commonDomainCookie writer="" reader="" />
2
goodguys_activate

Beaucoup de bonnes réponses ici.
Voici quelques bonnes solutions:

  • OpenId
  • OAuth
  • SAML
  • ADFS
  • Stockage local

Bien que je ne pense pas que ces éléments soient vraiment triviaux à mettre en œuvre, sans en apprendre un peu plus à leur sujet.

Mieux encore serait de mettre en œuvre un produit Web-SSO approprié - bien qu'il semble de votre question que ce ne soit pas une option (bien que je vous exhorte à reconsidérer et à essayer de convaincre vos supérieurs).

Une solution assez simpliste que j'ai vue, et en fait, certains produits Web-SSO utilisent également cette astuce (notez que je ne recommande pas nécessairement cette approche dans toutes les situations, voir ci-dessous):
Avoir un troisième domaine "d'authentification" qui émet un "cookie d'identité" (après authentification de l'utilisateur). Les sites Web sur d'autres domaines peuvent soumettre une simple demande POST au domaine d'authentification, qui comprendra bien sûr le cookie de l'utilisateur pour ce domaine . La réponse retournée indiquerait essentiellement le domaine d'origine, si l'utilisateur est authentifié et si nécessaire quelle est son identité.
Si l'utilisateur n'est pas encore authentifié - il sera redirigé vers une page du domaine d'authentification pour soumettre son mot de passe, etc.

Bien que cela soit assez simple à configurer, notez qu'il existe des défis pour le rendre réellement sécurisé.
Par exemple, tel que défini, tout le site Web peut récupérer votre identité. En outre, le site Web de confiance peut être "trompé" en modifiant la réponse retournée.
Bien sûr, la façon la plus simple de résoudre ces problèmes est - vous l'aurez deviné - SAML/OpenId/etc.

1
AviD

Je viens de m'inscrire, mais je trouve étonnant que vous n'ayez pas trouvé de réponse ailleurs. Comme vous l'avez déjà découvert, vous ne pouvez pas transmettre de jetons d'authentification de substitution à l'aide de cookies.

Vous n'avez fourni aucun détail sur la manière dont l'authentification de votre site actuel est implémentée ni sur les outils dont vous disposez pour programmer les sites. Mais je suppose que le mécanisme d'authentification est écrit dans un langage qui s'exécute sur le serveur Web et utilise un cookie pour garder une trace de la session.

Dans ce cas, vous avez déjà du code sur chaque URL qui nécessite une authentification pour vérifier si la session a été authentifiée, puis effectuez l'action appropriée - en exécutant la demande ou en redirigeant vers une page de connexion. Tout ce que vous devez faire est de gérer le scénario où il n'y a pas de session authentifiée et où une variable chiffrée est passée dans l'URL (c'est-à-dire comme un GET). Vous déchiffrez la valeur, vérifiez sa validité et créez une session à ce stade. Ensuite, sur votre page de connexion, après une connexion réussie, vous redirigez, en ajoutant la paire clé/valeur appropriée à l'URL.

C'est un bref aperçu - il y a quelques ajustements auxquels vous devez penser (par exemple, voulez-vous que les mêmes données de session soient partagées sur tous les sites, voulez-vous relier la session pour différentes sessions pour vous assurer qu'elle n'expire pas côté serveur) et vous devez également réfléchir à la façon dont vous empêchez les attaques de relecture (par exemple, y compris un TTL dans la charge utile chiffrée, y compris un défi généré de manière aléatoire, mais méfiez-vous de l'utilisation de l'adresse IP du client).

Étant donné que vous ne chiffrez/déchiffrez que du côté serveur, le chiffrement symétrique est adéquat.

0
symcbean