Comment passez-vous une session authentifiée entre des domaines d'application

Question

Disons que vous avez les sites Web www.xyz.com et www.abc.com.

Disons qu'un utilisateur accède à www.abc.com et qu'il est authentifié via le fournisseur d'appartenance ASP .NET normal.

Ensuite, à partir de ce site, ils sont envoyés au site (redirection, lié, tout ce qui fonctionne) www.xyz.com et le but du site www.abc.com était de transmettre cet utilisateur à l'autre site sous le statut isAuthenticated, afin que le site www.xyz.com ne demande plus les identifiants de cet utilisateur.

De quoi aurait-il besoin pour que cela fonctionne? J'ai quelques contraintes à ce sujet, les bases de données des utilisateurs sont complètement séparées, ce n'est pas interne à une organisation, c'est comme si on passait de stackoverflow.com à google en tant qu'authentifié, c'est cette nature séparée. Un lien vers un article pertinent suffira.

Answer 1

Essayez d’utiliser FormAuthentication en définissant la section d’authentification web.config comme suit:

<authentication mode="Forms">
  <forms name=".ASPXAUTH" requireSSL="true" 
      protection="All" 
      enableCrossAppRedirects="true" />
</authentication>

Générez une clé machine. Exemple: Méthode la plus simple pour générer MachineKey - Trucs et astuces: ASP.NET, IIS ...

Lors de la publication dans une autre application, le ticket d'authentification est transmis sous forme de champ caché. Lors de la lecture du message de la première application, la deuxième application lira le ticket crypté et authentifiera l'utilisateur. Voici un exemple de la page qui passe qui poste le champ:

.aspx:

<form id="form1" runat="server">
  <div>
    <p><asp:Button ID="btnTransfer" runat="server" Text="Go" PostBackUrl="http://otherapp/" /></p>
    <input id="hdnStreetCred" runat="server" type="hidden" />
  </div>
</form>

code-behind:

protected void Page_Load(object sender, EventArgs e)
{
    FormsIdentity cIdentity = Page.User.Identity as FormsIdentity;
    if (cIdentity != null)
    {
        this.hdnStreetCred.ID = FormsAuthentication.FormsCookieName;
        this.hdnStreetCred.Value = FormsAuthentication.Encrypt(((FormsIdentity)User.Identity).Ticket);
    }
}

Reportez-vous également à la section relative à l'authentification par formulaire inter-applications du chapitre 5 de la présente livre de Wrox. Il recommande des réponses comme celles ci-dessus en plus de fournir une solution SSO homebrew.

Answer 2

Si vous utilisez le système d’appartenance intégré, vous pouvez effectuer une authentification entre sous-domaines avec une authentification de formulaire en utilisant certaines de ces méthodes dans chaque Web.config.

<authentication mode="Forms">
    <forms name=".ASPXAUTH" loginUrl="~/Login.aspx" path="/" 
                  protection="All" 
                  domain="datasharp.co.uk" 
                  enableCrossAppRedirects="true" />

</authentication>

Assurez-vous que le nom, le chemin, la protection et le domaine sont les mêmes dans tous les web.configs. Si les sites se trouvent sur des ordinateurs différents, vous devrez également vous assurer que les clés machineKey, de validation et de cryptage sont identiques.

Answer 3

Si vous stockez des sessions utilisateur dans la base de données, vous pouvez simplement vérifier l’existence du Guid dans la table des sessions, s’il existe déjà, puis l’utilisateur s’est déjà authentifié sur l’autre domaine. Pour que cela fonctionne, vous devez inclure le guide de session dans l'URL lorsque vous redirigez l'utilisateur vers un autre site Web.

Answer 4

Vous ne savez pas exactement ce que vous utiliseriez pour .NET, mais normalement j'utiliserais memcached dans une pile LAMP.

Answer 5

La résolution dépend du type d'application et de l'environnement dans lequel elle s'exécute. Par exemple. sur l'intranet avec le domaine NT, vous pouvez utiliser NTLM pour transmettre les informations d'identification Windows directement aux serveurs du périmètre de l'intranet sans qu'il soit nécessaire de dupliquer les sessions.

La procédure à suivre est généralement appelée connexion unique (voir Wikipedia ).

Answer 6

Il existe plusieurs approches à ce problème, qui est décrit comme "Signature unique entre domaines". L'article de Wikipédia auquel Matej a fait référence est particulièrement utile si vous recherchez une solution open source. Cependant, dans un environnement Windows, je pense que vous avez intérêt à utiliser l'une des deux approches suivantes:

1. Acheter un produit SSO commercial (tel que SiteMinder ou PingIdentity)
2. Utilisez la solution SSO interdomaine de MicroSoft, appelée ADFS - Services de fédération de répertoire actifs. (fédération est le terme utilisé pour coordonner le comportement de plusieurs domaines)

J'ai utilisé SiteMinder et cela fonctionne bien, mais c'est cher. Si vous êtes dans un environnement entièrement basé sur MicroSoft, je pense que ADFS est votre meilleur choix. Commencez par ce livre blanc ADFS .

Answer 7

Je voudrais utiliser quelque chose comme CAS:

[1]: http://www.ja-sig.org/products/ cas / CAS

Il s’agit d’un problème résolu qui ne vous recommande pas de lancer le vôtre.

Answer 8

Sinon, si vous souhaitez lancer le vôtre et que les sites en question ne se trouvent pas sur les mêmes serveurs ou n'ont pas accès à une base de données partagée (dans ce cas, reportez-vous aux réponses ci-dessus), vous pouvez placer un balise Web sur chacun des sites qui renverraient à l'autre site.

Placez une seule image de pixel (balise Web) sur le site A, qui appellerait le site B en passant par l'ID de l'utilisateur (crypté et horodaté). Cela créerait alors une nouvelle session utilisateur sur le site B pour l'utilisateur, qui serait définie comme étant connectée. Ensuite, lorsque l'utilisateur visiterait le site B, il serait déjà connecté.

Pour minimiser les appels, vous pouvez uniquement placer la balise Web sur la page d'accueil et / ou vous connecter aux pages de confirmation. J'ai utilisé cela avec succès dans le passé pour transmettre des informations entre sites partenaires.