2008-10-27 10 views
0

Je travaille sur un site qui est au cœur/maître d'un certain nombre de sites. Nous sommes également responsables de la gestion de l'authentification sur tous les sites sous la bannière de la marque.SSO entre ASP.NET, ASP et PHP

Le client souhaitait qu'une opération de connexion unique soit incluse. Par conséquent, si je devais me connecter à l'un des sites, je serais connecté à tous les sites. Nous gérons les connexions au site enfant en redirigeant vers le site principal (nôtre) et en exécutant le login.

Il a été décidé que l'authentification unique fonctionnerait en intégrant des balises d'image dans la page, puis en appelant une page sur chaque site enfant. Cela ouvrirait une session client sur leur site afin qu'ils puissent créer des cookies/faire ce qu'ils veulent gérer un login.

Cela fonctionne pour la plupart, il a été testé sur IE7, FF 2 & 3 et ils fonctionnent tous. Le navigateur de problème pour le moment est Safari (et Chrome). Bien que les images semblent charger dans la session client ne semble pas être ouvert, nous n'obtenons pas de cookies de l'ensemble des sites enfants. Le problème semble être les navigateurs basés sur WebKit avec Safari et Chrome étant le problème (je présume que konqueror peut subir le même sort mais pour l'instant je n'ai pas une installation de Linux à ma disposition). Est-ce que quelqu'un sait comment faire pour que Safari reconnaisse une balise d'image incorporée à un hôte externe comme ouvrant un contexte client? Ou quelqu'un peut-il fournir un meilleur moyen de faire l'authentification unique d'ASP.NET vers des sites qui ne sont pas ASP.NET?

Remarque: oui Je suis conscient qu'il existe des problèmes dans le concept SSO que nous avons fait jusqu'à présent en ce qui concerne la désactivation des images. La solution proposée n'était pas la mienne, je suis juste coincé avec ça.

Répondre

1

Il ressemble à Safari (sur mon OS X, au moins - ce qui devrait être les paramètres par défaut) et, je suppose que Chrome, ne permettent pas les cookies tiers par défaut.

Safari-> Préférences-> Sécurité-> Accepter les cookies:

o Toujours
o Ne
+ Provenant seulement des sites Naviguer vers

Il y a quelques AJAX hackery pour obtenir votre domaine de document régler le cookie, mais je ne pense pas que cela résoudra vraiment votre problème ici. Je pense que Safari interdit même aux iframes de configurer un cookie tiers, à moins que vous ne définissiez document.domain (bien que, si vous partagiez un domaine commun, vous pourriez probablement simplement définir le domaine des cookies et en finir avec tout). À court de window.open, ou une série de redirections, je ne peux pas vraiment penser à beaucoup de choses que vous pouvez faire pour contourner le problème cookie 3ème partie - donc je ferais probablement tomber l'astuce de l'image intégrée et commencer à partir de zéro .

+0

Doux, changer les préférences a fonctionné. Maintenant, nous avons juste besoin d'un moyen d'informer les utilisations de ce site –

3

La plupart des tâches SSO avec lesquelles j'ai travaillé utilisent un serveur d'authentification centralisé (CAS) et fonctionnent avec des tickets transmis via des paramètres de requête et des cookies.

L'idée de base est que si votre site ne détecte pas de ticket, il redirige vers votre site Web CAS. Le site Web effectue l'authentification, définit un cookie d'authentification et redirige vers votre site à l'aide d'un ticket unique à utilisation unique (en tant que paramètre de requête). Une fois redirigé, votre site détecte le ticket et effectue un rappel au serveur CAS pour racheter le ticket à l'aide d'une requête Web hors bande. Cette requête renvoie l'identifiant de l'utilisateur qui s'est connecté.Vous l'utilisez pour définir l'utilisateur authentifié dans votre application.

Le serveur CAS conserve la trace des applications autorisées à se connecter entre elles. Lorsqu'une requête d'authentification provient d'un site du pool SSO et que le ticket d'authentification correspond à un autre site du pool, le serveur CAO répond avec un ticket sans forcer la réauthentification. De cette façon, vos sites peuvent simplement se lier les uns aux autres sans aucune "magie" spéciale, juste en fonction du fait que le cookie CAS fera en sorte que l'utilisateur puisse contourner la réauthentification entre les sites apparentés.

+0

L'utilisation d'un CAS serait une bonne idée, quelque chose comme OpenID ou LiveID aurait été une bien meilleure idée, mais nous sommes dans cette voie et maintenant et nous sommes coincé avec les choix faits –

Questions connexes