Ordnungsgemäßes Festlegen des Ablaufdatums des Anmeldetokens für Benutzer von SharePoint 2010-SAML-Ansprüchen

Als ich mich kürzlich in die Funktionsweise des Ablaufs von Anmeldecookies einarbeitete, stieß ich auf ein ziemlich großes Problem.  Sobald Benutzer von SAML-Ansprüchen ihr Anmeldecookie von ADFS erhalten haben, erfolgte kein Timeout.  Das heißt, sie konnten den Browser schließen und einige Minuten oder sogar Stunden später wieder öffnen und direkt zur Website navigieren, ohne sich bei ADFS erneut authentifizieren zu müssen.  Darüber hinaus arbeiteten die Office 2010-Clientanwendungen wie gewohnt.  Schließlich konnte ich die Ursachen hierfür herausfinden, die ich in diesem Blog dokumentieren möchte.

Zunächst ganz kurz einige Hintergrundinformationen.  Wenn Sie zum ersten Mal zu einer mit SAML-Ansprüchen gesicherten SharePoint-Website navigieren, werden Sie aufgefordert, sich zu authentifizieren und Ansprüche zu beschaffen.  Ihr SAML-Identitätsanbieter (wird auch als IP-STS bezeichnet) erledigt das für Sie und leitet Sie wieder an SharePoint um.  Wenn SharePoint wieder geöffnet wird, wird ein FedAuth-Cookie erstellt, wodurch erkenntlich ist, dass sie authentifiziert wurden.  Um das Arbeiten des Endbenutzers zu vereinfachen, wird der Wert des FedAuth-Cookies in den lokalen Cookieordner geschrieben.   Wenn für nachfolgende Anforderungen dieser Website ein gültiges FedAuth-Cookie für die Website gefunden wird, wird das Cookie gelesen und der SharePoint-Inhalt wird ohne erneute Authentifizierung direkt angezeigt.  Dies kann für jene Benutzer, die an ADFS 1.x und SharePoint 2007 gewöhnt sind, ein bisschen überraschend sein, da in diesen Anwendungen alle Web-SSO-Cookies sitzungsbasiert waren und deshalb nicht auf dem Datenträger gespeichert wurden.  Beispielsweise wurde beim Schließen des Browsers das Cookie gelöscht, weshalb Sie sich jedes Mal erneut authentifizieren mussten, wenn Sie den Browser schlossen oder öffneten.  Das ist bei SharePoint 2010 nicht der Fall. 

UPDATE 1: Wir fanden heraus, wie der SharePoint-Sicherheitstokendienst (Security Token Service, STS) geändert werden muss, damit er wieder mit Sitzungscookies verwendet werden kann, wie dies bei SharePoint 2007 der Fall war. Hierzu ist der folgende PowerShell-Code erforderlich:

$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
iisreset

Anschließend wird kein FedAuth-Cookie mehr auf den Datenträger geschrieben. Zum Zurücksetzen auf das Standardverhalten führen Sie die Schritte einfach in umgekehrter Reihenfolge aus:

$sts.UseSessionCookies = $false
$sts.Update()
iisreset

Wie konfigurieren wir aber dieses Verhalten, um ein SAML-Token mit einer akzeptablen Lebensdauer zu erhalten?  Folgendes müssen Sie beachten:

  1. Die TokenLifetime-Eigenschaft kann mithilfe der vertrauenden Seite in ADFS festgelegt werden. Leider kann sie offenbar nur zum Erstellungszeitpunkt der vertrauenden Seite festgelegt werden. Dies ist problematisch, da Sie standardmäßig ein einmal vorhandenes Cookie sehr, sehr lange verwenden können (ich habe nicht getestet, wie lange es wirklich verwendet werden kann).

UPDATE 2: Rich Harrison war so freundlich, den folgenden Code zum Aktualisieren der TokenLifetime-Eigenschaft in ADFS für die vertrauende Seite bereitzustellen:

Set-ADFSRelyingPartyTrust -TargetName "SPS 2010 ADFS" -TokenLifetime 5
 
wobei "SPS 2010 ADFS" der Name der Vertrauensstellungsentität der vertrauenden Seite in AD FS 2.0 ist.

Wenn Sie also zum Erstellungszeitpunkt die TokenLifetime-Eigenschaft der vertrauenden Seite in ADFS festlegen möchten, müssen Sie dazu PowerShell verwenden. Ich habe das folgende einzeilige Skript zum Erstellen der vertrauenden Seite verwendet:

Add-ADFSRelyingPartyTrust -Name "FC1" -Identifier "https://fc1/_trust/" -WsFedEndpoint "https://fc1/_trust/" -TokenLifetime 2 -SignatureAlgorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1

Nachdem Sie die vertrauende Seite auf diese Weise erstellt haben, müssen Sie folgende Schritte manuell ausführen:

  1. Hinzufügen des Bereichs zur Liste der Bezeichner (z. B. urn:sharepoint:foo)
  2. Hinzufügen einer Ausstellungsautorisierungsregel, um den Zugriff auf alle Benutzer zu erlauben
  3. Hinzufügen einer Ausstellungstransformierungsregel zum Senden der E-Mail-Adresse und der Rollen

 

  1. Wenn Sie sich nun anzumelden versuchen, werden Sie wahrscheinlich feststellen, dass Sie nach der Authentifizierung bei ADFS in einer Endlosschleife zwischen SharePoint und ADFS gefangen sind. Die Überprüfung des Datenverkehrs in Fiddler zeigt, dass Sie erfolgreich bei ADFS authentifiziert werden, dass SharePoint wieder angezeigt und das FedAuth-Cookie erfolgreich ausgestellt wird, dass Sie zu /_trust/authenticate.aspx auf der SharePoint-Website umgeleitet werden, wodurch das FedAuth-Cookie gelöscht wird und Sie wieder zur ADFS-Website umgeleitet werden. Im Prinzip wechseln Sie ständig hin und her, bis der Vorgang von ADFS unterbrochen und eine Fehlermeldung angezeigt wird, dass die Clientbrowsersitzung 6 Anforderungen in den letzten 12 Sekunden ausgeführt hat. Das ergibt tatsächlich Sinn, denn der Wert von LogonTokenCacheExpirationWindow für den SharePoint-Sicherheitstokendienst beträgt standardmäßig 10 Minuten. Als ich beim Erstellen der vertrauenden Seite für die Tokengültigkeitsdauer in ADFS 2 Minuten festgelegt habe, war mit der Authentifizierung klar, dass das Cookie kürzer als der Wert von LogonTokenCacheExpirationWindow gültig ist. Deshalb musste ich mich erneut bei ADFS authentifizieren. Und so ging das hin und her. Zur Behebung dieses Problems müssen Sie lediglich für LogonTokenCacheExpirationWindow einen niedrigen Wert als für den SAML-Wert TokenLifetime festlegen. Anschließend können Sie sich bei der Website anmelden.  Es folgt ein Beispiel für die Festlegung von LogonTokenCacheExpirationWindow in SharePoint:

$sts = Get-SPSecurityTokenServiceConfig

$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)

$sts.Update()

Iisreset

 

Nachdem Sie diese Einstellungen ordnungsgemäß konfiguriert haben, läuft die Anmeldung für SAML-Benutzer ordnungsgemäß ab. Sie können 2 Minuten lang das Browserfenster öffnen und schließen und die Website erneut öffnen, ohne wieder an SharePoint umgeleitet zu werden. Nach Ablauf dieses Zeitraums müssen Sie sich jedoch wieder bei ADFS authentifizieren.

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users