Comment authentifier les utilisateurs sur plusieurs domaines en utilisant ASP.NET et iframes?

Question

Je suis en train de créer un site ASP.NET pour un client qui souhaite rendre sa page de rapports disponible via IFRAME sur d'autres sites web de "revendeurs". Les sites Web revendeurs fournissent le même service avec différentes marques. Je dois éviter, là où je peux, de leur demander d'implémenter n'importe quel code sur leur serveur web pour l'activer - d'où l'utilisation des iframes.

Un utilisateur se connecterait au site Web du revendeur, chargerait une page contenant un iframe, qui à son tour chargerait le rapport sur le site principal. En tant que paramètres, nous enverrions l'identifiant du revendeur et son nom d'utilisateur.

Nous pouvons utiliser des certificats de serveur SSL, mais pas de connexion fédérée (comme OpenId) - un choix professionnel du client.

La question est de savoir comment le site principal vérifie que la page de rapport est réellement demandée par l'utilisateur qui a chargé la page à partir du revendeur. En d'autres termes, comment authentifier l'utilisateur sur plusieurs domaines, sans que le revendeur ne soit obligé d'implémenter le code.

Toute idée serait grandement appréciée!

Answer 1

Je ne vois pas de façon satisfaisante le faire sans mettre en œuvre un code sur le site revendeur. Au lieu de cela, je leur demanderais d'envoyer une demande HTTPS du serveur web du revendeur au serveur Web principal, en passant une clé secrète unique pour s'identifier, ainsi que le nom d'utilisateur de leur utilisateur connecté.

Une fois vérifiée sur le site primaire, cette clé servirait alors d'authentification pour le revendeur, et par extension, à son utilisateur connecté.

La réponse de cette requête contiendrait une chaîne de fragments html, que le revendeur peut injecter dans n'importe quelle page.

Ce fragment contiendrait une iframe, qui, à son tour, chargerait le rapport pour l'utilisateur connecté directement à partir du site principal, en utilisant son nom d'utilisateur. Ce contenu de rapport contiendrait une référence à une feuille de style spécifique au revendeur. Avec cette approche, je dirais que HTTPS n'est pas nécessaire dans le navigateur, puisque le revendeur et son utilisateur sont tous deux authentifiés, et que si ce processus est passé via HTTPS, nous pouvons supposer qu'il n'y a pas d'intrus.

Dans le cas où la clé secrète ou le mot de passe de l'utilisateur ont été compromis, HTTPS du navigateur ne ferait aucune différence de toute façon.

Answer 2

Il se peut que je manque quelque chose, mais si le client est authentifié par rapport à votre serveur, il sera toujours authentifié si vous l'affichez via un iframe. Par exemple, créez une page HTML sur votre serveur avec un cadre iFrame sur Gmail. Tant que vous êtes authentifié contre Gmail dans votre navigateur, vous verrez votre boîte de réception dans cette page ...

Answer 3

Votre forme de login peut employer le javascript pour publier le formulaire de connexion à un iframe caché (vous ne pouvez pas utiliser un XMLHTTPRequest en raison de problèmes de sécurité inter-domaines) pour chaque domaine pour lequel vous avez besoin d'une connexion. Assurez-vous de rediriger votre iframe vers le domaine d'origine ou vous ne pourrez pas extraire l'état de connexion de l'iframe en raison de la sécurité inter-domaines.

L'astuce finale pour le soutien IE est de retourner le bit mal et ajouter

P3P: CP="CAO PSA OUR" 

à vos en-têtes de réponse HTTP. Ce qui indique au navigateur "Je ne ferai rien de mal, d'honnête".

http://support.microsoft.com/kb/323752

http://www.w3.org/P3P/