Sind ADFS 2.0/SAML-Token in ASP.NET sticky?

Question

Wir führen eine ASP.NET 4.6-Anwendung mit ADFS 2.0. Die Konfiguration des ADFS-Teils web.config wurde mit FedUtil.exe erstellt.

Wir haben jetzt das Problem, dass eine zweite Instanz der Webanwendung immer noch denkt, dass der Benutzer nicht authentifiziert ist.

• Auth auf Server 1 funktioniert nur auf Server 1
• Auth auf Werke Server 2 nur auf dem Server 2

aber ..

• Auth auf Server 1 nicht erkannt werden, Server 2 und umgekehrt

In unserem Szenario würde nur eine klebrige Sitzung arbeiten in einer last-ausgeglichenen Umgebung. Ich denke, es ist wegen der Sessionmodule ist, die erforderlich ist:

<modules> 
     <add name="WSFederationAuthenticationModule" type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler" /> 
     <add name="SessionAuthenticationModule" type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler" /> 
    </modules> 

Bin ich richtig, dass die Sessionmodule speichert alle Daten des Auth * in einer Sitzung, so eine gemeinsame Sitzung nicht möglich sein würde, und wir gezwungen sind, zu verwenden, klebrige Sitzungen?

Würde IdentityServer3 oder IdentityServer4 dieses Problem lösen?

Answer 1

Es dass die Microsoft.Identity zu sein scheint, bietet keine SAML-Token ohne Sticky Sessions: https://leastprivilege.com/2012/07/12/machinekey-based-session-protection-for-wif/