Artikel
09/03/2015

Dieser Artikel wurde maschinell übersetzt.

Identitätsverbund

Passive Authentifizierung für ASP.NET mit WIF

Michele Leroux Leroux

Verbundsicherheit zielt stellen einen Mechanismus zum Einrichten von Vertrauensstellungen zwischen Domänen, damit Benutzer in Ihrer eigenen Domäne authentifizieren kann, während der Zugriff auf Anwendungen und Dienste, die in einer anderen Domäne gewährt wird. Dies ermöglicht Authentifizierungstechniken wie single Sign-On, erübrigt sich die Notwendigkeit zum Bereitstellen und Verwalten von doppelte Konten für Benutzer, Anwendungen und Domänen und deutlich senkt die Kosten für vertrauenswürdige Personen Anwendungen erweitern.

In einem Modell Verbundsicherheit eine Identity-Anbieter (IdP) führt die Authentifizierung und ein Security Token Service (STS) zum Problem Sicherheitstokens bereitstellt. Diese Tokens assert wiederum Informationen zu dem authentifizierten Benutzer: Ihre Identität und möglicherweise auch andere Informationen, z. B. Rollen und präzisere Zugriffsrechte. In einer verbundenen Welt diese Informationen als Ansprüche bezeichnet wird und Ansprüche-based Access Control ist ein Verbund Sicherheitsmodell von zentraler Bedeutung. In diesem Modell, Anwendungen und Diensten autorisieren des Zugriffs auf die Features und Funktionen, die basierend auf Ansprüche aus vertrauenswürdiger Aussteller (STS).

Plattformtools wie Windows Identity Foundation (WIF) erleichtern es sehr, diese Art von Identitätsverbund zu unterstützen. WIF ist eine Identität Modell-Framework zum Erstellen anspruchsbasierter Anwendungen und Dienste und für die Unterstützung von SOAP-basierten (aktiv) und Browser-basierte (passiv) Föderationsszenarios. Im Artikel “ Anspruchsbasierte Autorisierung mit WIF , ” in der November 2009-Ausgabe des MSDN Magazine Schwerpunkt WIF Windows Communication Foundation (WCF) verwendet werden. In diesem Artikel beschriebenen ich wie anspruchsbasierte Sicherheitsmodelle für WCF-Dienste implementieren und Identitätsverbund zu migrieren.

Der Schwerpunkt in diesem Artikel zur Nachverfolgung ich auf passiven Verbund. Ich wird erläutert den Ablauf der Kommunikation für passiven Verbund, zeigen Ihnen verschiedene Techniken zum Aktivieren der Föderation in Ihren ASP.NET-Anwendungen, anspruchsbasierte Autorisierungstechniken für ASP.NET diskutieren und sprechen Sie über die einzelnen anmelden und einzelne Abmeldung Szenarien. Dabei wird erläutert, die zugrunde liegenden WIF-Features und Komponenten, die passive Verbundszenarios unterstützen.

Grundlagen der passiven Föderation

Passive Verbundszenarios basieren auf der Spezifikation WS-Federation. Beschreibt, wie Sicherheitstokens anfordern und veröffentlichen, und erwerben Sie Metadatendokumente Föderation, was Herstellen von Vertrauensstellungen erleichtert. WS-Federation beschreibt außerdem die einzelnen Prozeduren für einmaliges Anmelden und Abmelden und zu weiteren Konzepten für Föderationen Implementierung.

Während der WS-Federation viele Details über die Föderation erläutert, sind Abschnitte für browserbasierte Föderation, die HTTP-GET und POST, leitet der Browser und Cookies zum Erreichen des Ziels verwenden.

Einige Aspekte der Nachrichtenübermittlung von passiven Verbund basieren eng auf die WS-Trust-Spezifikation. Passiven Verbund nutzt z. B. eine browserkompatible Form RST (Request Security Token) und RSTR (RST Response), wenn ein Sicherheitstoken eines STS angefordert wird. In den passiven Verbundszenario werde ich eine Anforderungsnachricht-Anmeldung und die Antwortnachricht RST-Antwort einen Anmeldenamen RST aufrufen. Die WS-Trust-Spezifikation befasst sich mit SOAP-basierten (active) Föderation, z. B. zwischen Windows-Clients und WCF-Dienste.

Abbildung 1 , ist einem einfachen passiven Verbundszenario dargestellt.

A Simple Passives Verbundszenario

Abbildung 1 A Simple Passives Verbundszenario

Benutzer an der Domäne authentifizieren und den Zugriff auf eine Webanwendung entsprechend Ihren Rollen erteilt werden. Die Teilnehmer dieses Authentifizierungsschema gehören der Benutzer (das Thema), einen Webbrowser (die anfordernde Person), eine ASP.NET-Anwendung (relying Party oder RP), eines IdP verantwortlich für die Benutzer innerhalb der Domäne authentifizieren und ein STS, der zu der Domäne des Benutzers (IP-STS) gehören. Eine Sequenz von Browser-Umleitungen wird sichergestellt, dass der Benutzer in Ihrer Domäne vor, um den Zugriff auf die RP authentifiziert wird.

Der Benutzer, der die RP-Anwendung aufruft (1) und auf Ihre IdP authentifizierten (2) werden umgeleitet wird. Wenn der Benutzer noch nicht bei der IdP authentifiziert wurde, können der IP-STS eine Herausforderung darstellen oder leiten Ihr zu einer Anmeldeseite Anmeldeinformationen (3) zu erfassen. Der Benutzer gibt seine Anmeldeinformationen (4) und von der IP-STS (5) authentifiziert wird. An dieser Stelle der IP-STS stellt ein Sicherheitstoken entsprechend auf die Anforderung-Anmeldung und die mit dem Token des Antwort auf die RP über Browser-Umleitung (6) bereitgestellt. Die RP verarbeitet das Sicherheitstoken und autorisiert Zugriff auf der Grundlage der Ansprüche er (7) führt. Wenn erfolgreich autorisiert ist, wird dem Benutzer angezeigt, mit der Seite, die er ursprünglich angefordert hat, und ein Sitzungscookie (8) zurückgegeben.

Implementieren diese passiven Verbundszenario mit WIF und ASP.NET umfasst nur wenige Schritte:

Richten Sie eine Vertrauensstellung zwischen der RP und IdP (IP-STS)
Aktivieren Sie für die ASP.NET-Anwendung passiven Verbund
Implementieren von Autorisierung überprüft zum Steuern des Zugriffs auf Anwendungsfeatures in den nächsten Abschnitten ich die WIF-Features, die passiven Verbund zu unterstützen, gehen Sie durch die Schritte zum Konfigurieren dieses einfache Szenarios und entdecken Sie weitere praktische Aspekte für dieses und andere Szenarien erläutert wird.

WIF-Features für die passive Föderation

Können Sie vor der Diskussion der Implementierung die Features der WIF speziell für Identitätsverbund in Ihren ASP.NET-Anwendungen nützlich zur Überprüfung anzeigen. WIF stellt zunächst die folgenden nützlichen HTTP-Module zur Verfügung:

WSFederationAuthenticationModule (FAM): Aktiviert die browserbasierte Föderation, Umleitung zu der entsprechenden STS für Authentifizierung und Tokenausstellung behandeln und verarbeiten die resultierende Anmelden als Antwort auf hydrate ausgestelltes Sicherheitstoken in eine ClaimsPrincipal für die Autorisierung verwendet werden. In dieser Unterrichtseinheit werden auch andere wichtige Föderation Nachrichten z. B. Abmeldung Anforderungen behandelt.
SessionAuthenticationModule (SAM): Verwaltet die authentifizierte Sitzung durch Generieren von das Sitzung Sicherheitstoken, das dem ClaimsPrincipal enthält, in ein Cookie zu schreiben, Verwaltung der Lebensdauer des Sitzungscookies und dem ClaimsPrincipal aus dem Cookie aktivieren, wenn es angezeigt wird. In diesem Modul verwaltet außerdem eine lokale token Sitzungscache.
ClaimsAuthorizatonModule: Stellt einen Erweiterungspunkt, eine benutzerdefinierte ClaimsAuthorizationManager installieren, die für die zentralisierte Zugriffsüberprüfungen nützlich sein können.
ClaimsPrincipalHttpModule: Erstellt eine ClaimsPrincipal über die Identität des aktuellen Benutzers an den Anforderungsthread angefügt. Darüber hinaus bietet einen Erweiterungspunkt, einen benutzerdefinierten ClaimsAuthenticationManager zu installieren, die nützlich für die Anpassung der ClaimsPrincipal an den Anforderungsthread angefügt werden können.

ClaimsPrincipalHttpModule eignet sich am besten für Anwendungen ohne passiven Verbund. Sie können es als ein nützliches Tool für die Implementierung ein anspruchsbasiertes Sicherheitsmodell in der ASP.NET-Anwendung vor dem zum Verschieben von passiven Verbund vorstellen. Ich erläutert diese Technik für WCF in meiner früheren Artikel.

Die anderen drei Module werden in der Regel zusammen für passiven Verbund verwendet – Obwohl ClaimsAuthorizationModule optional ist. Abbildung 2 wird dargestellt, wie diese Hauptmodule in der Anforderungspipeline und ihre Funktionen in einer typischen Verbundauthentifizierung Anforderung passen.

WIF-Komponenten und HTTP-Module beschäftigt Federation Passive

Abbildung 2 WIF-Komponenten und HTTP-Module beschäftigt Federation Passive

Halten Beachten Sie den Fluss der passiven Verbund von mit Abbildung 1, wenn der Benutzer auf eine geschützte Seite in die RP (1) zuerst durchsucht, wird der Zugriff auf die Anwendung verweigert. Die FAM nicht autorisierte Anforderungen verarbeitet, erzeugt die Meldung anmelden und leitet den Benutzer zu der IP-STS (2). Der IP-STS authentifiziert den Benutzer (3), eine Antwort anmelden, die das ausgestelltes Sicherheitstoken beinhaltet und leitet an die RP-Anwendung (4) erzeugt.

Die FAM verarbeitet die Antwort anmelden – sicher, dass die Antwort für den authentifizierten Benutzer ein gültiges Sicherheitstoken enthält – und hydrates ein ClaimsPrincipal aus der Anmelde-Antwort (5). Dadurch wird das Sicherheitsprinzipal für den Anforderungsthread und HttpContext festgelegt. Anschließend verwendet der FAM SAM um zu serialisieren, die während der Browsersitzung mit nachfolgenden Anforderungen präsentiert werden die Ansprüche Principal auf einem HTTP-Cookie (6). Wenn ClaimsAuthorizationModule installiert ist, wird aufgerufen der konfigurierten ClaimsAuthorization -Manager bereitstellt, für die Durchführung von globalen Zugriff (7) gegen die ClaimsPrincipal vor, um den Zugriff auf die angeforderte Ressource überprüft.

Nach die angeforderte Ressource gesendet wird, überprüft der IsInRole Zugriffssteuerung mit herkömmlichen ASP.NET-Anmeldesteuerelemente implementiert werden kann, und anderen benutzerdefinierter Code, der des Benutzers fragt Ansprüche (8).

Bei nachfolgenden Anforderungen wird das Sitzungstoken mit dem Cookie, das zuvor durch den SAM (9) geschriebenen dargestellt. Dieses Mal wird die Sicherheitskontenverwaltung beschäftigt, das Sitzungstoken zu überprüfen und aktivieren den Ansprüchen Principal aus dem Token (10). Ist nicht mit der FAM beschäftigt, sofern die Anforderung einer Anmeldung Antwort eine Abmeldung-Anforderung ist oder wenn der Zugriff verweigert wird, was passieren kann, wenn das Sitzungstoken nicht vorhanden ist oder ist abgelaufen.

Zusätzlich zu diesen Modulen sind zwei ASP.NET-Steuerelemente, die auch im passiven Verbund nützlich sind:

FederatedPassiveSignIn-Steuerelement: Kann anstelle der FAM verwendet werden, wenn die Anwendung auf alle nicht autorisierten Aufrufe zu einer Anmeldeseite, die dieses Steuerelement hostet umgeleitet, nur wenn Authentifizierung erforderlich ist. Dabei wird vorausgesetzt, der Benutzer wird mit dem Zeichen-Prozess interagieren – step-up Authentifizierungsverfahren, in dem der Benutzer aufgefordert, Anmeldeinformationen möglicherweise zusätzliche Anmeldeinformationen aus der ursprünglichen Anmeldung gemäß den Anforderungen der Anwendung für die, nützlich. Das Steuerelement behandelt Umleitung der STS, Verarbeitung der Antwort-Anmeldung beim Initialisieren des ClaimsPrincipal aus der Antwort und eine sichere Sitzung einrichten, durch den wirksamen Einsatz der Funktionen, die von der FAM und SAM verfügbar gemacht werden.
FederatedPassiveSignInStatus-Steuerelement: Dieses Steuerelement stellt eine interaktive Möglichkeit für den Benutzer zum Anmelden oder Abmelden von RP-Anwendung, einschließlich der Unterstützung für verbundene abmelden.

Abbildung 3 wird veranschaulicht, wie den Kommunikationsfluss ändert sich, wenn das Steuerelement FederatedPassiveSignIn eingesetzt wird. Die Anwendung verwendet Formularauthentifizierung zum Schützen von Ressourcen und leiten auf der Anmeldeseite (1)-Steuerelement hostet. Der Benutzer FederatedPassiveSignIn-Steuerelement klickt (oder kann darauf automatisch umgeleitet werden), löst eine Umleitung auf den STS (2). Steuerelement-Seite empfängt die Antwort vom STS, abhängig von der FAM und das SAM zum Verarbeiten der Antwort-Anmeldung (3), hydrate Ansprüchen Principal und schreiben das Sitzungscookie (4). Wenn der Benutzer zur ursprünglich angeforderten Seite (5) umgeleitet wird, ist die Sicherheitskontenverwaltung überprüft das Sitzungscookie und hydrate des ClaimsPrincipal für die Anforderung beschäftigt. Zu diesem Zeitpunkt kann der ClaimsAuthorizationModule und dieser Seite Ihre Autorisierungsprüfungen wie dargestellt in Abbildung 2 durchführen.

passive Föderationen mit der FederatedPassive -Anmeldung Control

Abbildung 3 passive Föderationen mit der FederatedPassive -Anmeldung Control

Die FAM und die SAM benötigen die entsprechenden Security TokenHandler Typ zum Verarbeiten von eingehender Tokens. Beim Anmelden Antwort eintrifft, durchläuft der FAM SecurityTokenHandlerCollection Suche nach der richtigen Tokenhandler zum Lesen des XML-Tokens. In einem Verbundszenario wird dies in der Regel Saml11Security TokenHandler oder Saml2Security TokenHandler sein, obwohl andere Formate token eingesetzt werden, können wenn Sie benutzerdefinierte token Handler hinzufügen. Für die Sicherheitskontenverwaltung wird verwendet, um das Sitzungstoken das Sitzungscookie zugeordneten Prozess SessionSecurity TokenHandler.

Mehrere Konfigurationseinstellungen für Identität-Modell sind wichtig, um den Fluss der passiven Verbund – und die FAM und SAM und FederatedPassiveSignIn-Steuerelement nicht initialisiert werden (obwohl für letztere auch Eigenschaften von Visual Studio-Designer konfigurierbare verfügbar macht) verwendet werden. Programmgesteuert, stellen Sie eine Instanz des Service Konfigurations-Typ aus dem Namespace Microsoft.IdentityModel.Configuration oder deklarative Konfiguration im Abschnitt <microsoft.identityModel> angeben. Abbildung 4 zusammengefasst Identität Modell Einstellungen, von die viele in den nachfolgenden Abschnitten erläutert werden.

Abbildung 4 Zusammenfassung der Essential <microsoft.identityModel> Elemente

Abschnitt	Description
<issuerNameRegistry>	Eine Liste der vertrauenswürdigen Zertifikat Aussteller angeben. Diese Liste ist in erster Linie für die token Signatur überprüft wird, so dass Token signiert von nicht vertrauenswürdigen Zertifikate zurückgewiesen werden.
<audienceUris>	Geben Sie eine Liste der gültigen Zielgruppe URIs für eingehende SAML-Tokens. Können deaktiviert werden, um beliebigen URI ermöglichen jedoch nicht empfohlen.
<securityTokenHandlers>	Passen Sie Konfigurationseinstellungen für Tokenhandler, oder geben Sie benutzerdefinierte token Handler zu steuern, wie Token bestätigt, authentifiziert und serialisiert werden.
<maximumClockSkew>	Passen Sie die erlaubte Zeitdifferenz zwischen Token und Anwendungsservern token gültig. Die Neigung Standard beträgt 5 Minuten.
<certificateValidation>	Sie können steuern Sie, wie Zertifikate überprüft werden.
<serviceCertificate>	Geben Sie ein Dienstzertifikat für das Entschlüsseln von eingehender Tokens.
<claimsAuthenticationManager>	Geben Sie einen benutzerdefinierten Typ der ClaimsAuthenticationManager anpassen oder ersetzen Sie den Typ IClaimsPrincipal an den Anforderungsthread angefügt werden soll.
<claimsAuthorizationManager>	Geben Sie einen benutzerdefinierten Typ ClaimsAuthorizationManager zum Steuern des Zugriffs auf die Funktionalität aus eine zentrale Komponente.
<federatedAuthentication>	Angeben von passiven Verbund anwendungsspezifische Einstellungen.

Aktivieren der Föderation passive

WIF erleichtert die passiven Verbund für ASP.NET-Anwendungen zu konfigurieren. Ein STS sollten Föderation Metadaten (wie in der Spezifikation WS-Federation beschrieben) angeben und WIF liefert eine Föderation Utility (FedUtil.exe), die Metadaten für die Föderation zum Einrichten von Vertrauensstellungen zwischen eine RP und einem STS (neben anderen Funktionen nützlich, um beide aktiven und passiven Verbundszenarios verwendet). Sie können FedUtil von der Befehlszeile aus oder von Visual Studio aus aufrufen, indem Sie mit der rechten Maustaste auf das Projekt RP und Hinzufügen von STS-Verweis.

Die folgenden einfachen Schritte führen Sie mit dem Assistenten FedUtil:

Die erste Seite des Assistenten können Sie die Konfigurationsdatei geändert werden, durch den Assistenten und die RP Anwendungs-URI zu bestätigen.
Die zweite Seite-Anforderungen für den STS, mit denen die RP Vertrauensstellung einrichten, den Pfad zu der Föderation Metadaten-XML-Dokument.
Die dritte Seite ermöglicht Ihnen das Bereitstellen eines Zertifikats, das zum Entschlüsseln von Token verwendet werden.
Auf der letzte Seite zeigt eine Liste von Angeboten, die vom STS Ansprüche, die Sie verwenden können, z. B. planen, Entscheidungen hinsichtlich der Zugriffssteuerung.

Bei die Schritten des Assistenten abgeschlossen sind, ändert FedUtil das Projekt einen Verweis auf die Assembly Microsoft.IdentityModel hinzufügen. Es ändert auch die Web.config-Datei zum Installieren von FAM und SAM-Module und Identität Modell-Konfigurationseinstellungen für diese Module angeben. Die Anwendung wird jetzt unterstützt passiven Verbund und leitet nicht autorisierte Anforderungen an vertrauenswürdigen STS.

Es gibt eine Annahme hier, dass der STS Vorkenntnisse die RP hat, wird daher für authentifizierte Benutzer versuchen, Zugriff auf die RP-Token ausstellen und natürlich, dass der öffentliche Schlüssel die RP sind erfordert der STS zum Verschlüsseln von Token. Dies ist eine einfache Möglichkeit, Ihre ASP.NET-Anwendungen anfänglich für die Föderation eingerichtet werden. Natürlich ist es hilfreich um zu verstehen, wie dies völlig eingerichtet, für den Fall, dass Anpassungen erforderlich sind und wie die grundlegenden Einstellungen vom Assistenten aktiviert hinausgehen. Ich werde auf die “ völlig ” Ansatz von hier aus auf in konzentrieren.

Ohne FedUtil müssen Sie manuell einen Verweis auf die Assembly Microsoft.IdentityModel hinzufügen und die FAM und die SAM-Module zusammen mit den erforderlichen Identität Modell Einstellungen manuell zu konfigurieren. HTTP-Module werden zwei Abschnitte hinzugefügt: System.Web für Internet Information Services (IIS) 6 und System.Webserver für IIS 7. Angenommen, die Anwendung in IIS 7 gehostet wird, sind die WIF-Module wie folgt konfiguriert:

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

In der Standardeinstellung wird diese Konfiguration nur Ressourcen mit Erweiterungen, die explizit von der ASP.NET-Pipeline (.aspx, asax usw.) verarbeitet werden zugeordnete geschützt. Um zusätzliche Ressourcen mit Verbundauthentifizierung zu schützen, sollten Sie diese Erweiterungen an die Pipeline ASP.NET in IIS zuordnen, oder Sie können RunAllManagedModulesForAllRequests true in den Modulen festlegen (nur IIS 7) wie folgt festlegen:

<modules runAllManagedModulesForAllRequests="true">

Für die FAM in starten müssen Sie den Authentifizierungsmodus ASP.NET auf None festgelegt und verweigern anonymen Benutzern den Zugriff auf die Ressourcen der Anwendung:

<authentication mode="None" />

<authorization>
  <deny users="?" />
</authorization>

Beide Module Identitätseinstellungen der Modellkonfiguration in Abbildung 4 beschriebenen abhängen, ist ein typisches Beispiel für die in dargestellt Abbildung 5 . Die meisten dieser Einstellungen werden durch FedUtil, mit Ausnahme der CertificateValidation und ein paar der Einstellungen innerhalb FederatedAuthentication generiert. Empfehle ich in der Regel PeerTrust Zertifikat Überprüfung Modus – was bedeutet, dass Sie explizit alle vertrauenswürdigen Zertifikate hinzufügen, einschließlich der, die vertrauenswürdigen Aussteller TrustedPeople-Speicher des lokalen Computers.

Abbildung 5 Identity Modellkonfiguration für passive Föderation

<microsoft.identityModel>
  <service>
    <issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
      <trustedIssuers>
        <add thumbprint="EF38A0A6D1274766093D3D78BFE4ECA77C62D5C3" 
          name="http://localhost:60768/STS/" />
      </trustedIssuers>
    </issuerNameRegistry>
    <certificateValidation certificateValidationMode="PeerTrust" 
      revocationMode="Online" trustedStoreLocation="LocalMachine"/>
    <audienceUris>
      <add value="http://localhost:50652/ClaimsAwareWebSite2/" />
    </audienceUris>
    <federatedAuthentication>
      <wsFederation passiveRedirectEnabled="true" 
        issuer="http://localhost:60768/STS/" 
        realm="http://localhost:50652/ClaimsAwareWebSite2/" 
        requireHttps="true" />
      <cookieHandler requireSsl="true" name="FedAuth"  
        hideFromScript="true" path="/ClaimsAwareWebSite2" />
    </federatedAuthentication>
    <serviceCertificate>
      <certificateReference x509FindType="FindByThumbprint" 
        findValue="8A90354199D284FEDCBCBF1BBA81BA82F80690F2" 
        storeLocation="LocalMachine" storeName="My" />
    </serviceCertificate>
  </service>
 </microsoft.identityModel>

Sie sollten in der Regel benötigen HTTPS/SSL für passiven Verbund, b ausgestellte Token vor Man-in-the-Middle-Angriffen zu schützen und HTTPS/SSL für Sitzungscookies erforderlich. In der Standardeinstellung Cookies werden vom Skript ausgeblendet, aber es ist eine wichtige Einstellung, weshalb ich ihn aufrufen Abbildung 5 .

Für den Namen und Pfad des Cookies standardmäßig der Namen FedAuth, den Pfad zum Verzeichnis Anwendung. Es ist nützlich, um einen eindeutigen Namen für das Cookie angeben insbesondere, wenn viele RP-Anwendungen in der Projektmappe in die gleiche Domäne gemeinsam nutzen. Im Gegensatz dazu können Sie einen generischen Pfad angeben, wenn Sie Cookies für mehrere Anwendungen in der gleichen Domäne freigegeben werden.

Sie werden i. d. r. FedUtil verwenden, Konfigurieren von ASP.NET-Anwendungen für den passiven Verbund mit dem FAM und SAM und dann entsprechenden Einstellungen entsprechend den Anforderungen der Lösung optimieren. Sie können auch das Steuerelement PassiveFederationSignIn anstelle der FAM wie dargestellt in Abbildung 3 . Das Steuerelement kann entweder seine Einstellungen aus dem Abschnitt "microsoft.identityModel laden, oder legen Sie Eigenschaften direkt auf das Steuerelement.

Die Steuerelement-Methode ist nützlich, wenn Sie möchten, dass nicht autorisierte Anfragen zu einer Anmeldeseite umgeleitet werden, in denen der Benutzer explizit anmelden kann durch Klicken auf das Steuerelement, statt die automatische Umleitung der STS FAM. Wenn der Benutzer mehr als ein Identitätsprovider (home Realm) angehören kann, konnte auf der Anmeldeseite z. B. einen Mechanismus für die Person an Ihr Heimnetzwerk Realm vor zum Umleiten der STS bereitstellen. Privat Bereichserkennung erörtert kurz.

Passive Token-Ausgabe

Wie bereits erwähnt, benötigt passiven Verbund HTTP GET und POST und Browser Umleitungen, um die Kommunikation zwischen dem RP und STS zu vereinfachen. Abbildung 6 zeigt die primäre Anforderungsparameter Beteiligten in die Anmeldung Anforderung und -Anmeldung Antwort während dieses Vorgangs.

primäre anmelden Anforderung und Antwort-Parameter beteiligte in Anforderungen für passive Föderation

Abbildung 6 primäre anmelden Anforderung und Antwort-Parameter beteiligte in Anforderungen für passive Föderation

Der STS erhält die Anforderung anmelden, wird er überprüfen, ob Sie über die RP weiß, indem Sie den Parameter Wtrealm anhand seiner Liste von bekannten RP-Bereichen. Vermutlich werden der STS Kenntnisse der RP, die erforderliche token Ver-und alle Erwartungen in Bezug auf die gewünschte Ansprüche in das ausgestellte Token enthalten sein Zertifikat verfügen. Die RP kann darauf hinweisen, welche Ansprüche erforderlich ist, wenn den Parameter optional Wreq mit einer Anforderung vollständiger stellt zur Verfügung, und der STS optional berücksichtigen, die die Liste oder entscheiden autonom der Ansprüche zu gewähren, basierend auf dem authentifizierten Benutzer.

In einem einfachen Verbundszenario wie die in Abbildung 1 besteht einer einzelnen RP und einer einzelnen IP-STS für die Authentifizierung von Benutzern zuständig. Wenn der IP-STS authentifiziert Benutzer anhand einer Windows-Domäne, könnte er Rolle Ansprüche z. B. Admin, User oder Gast ausstellen. Wird davon ausgegangen, dass diese Rollen für die RP für die Autorisierung Bedeutung haben. Im nächsten Abschnitt wird angenommen, diese Rollen ausreichen und Autorisierungstechniken besprechen. Der folgende, dass ich Anspruchstransformation am die RP STS Ansprüche in etwas besser nutzen für die Autorisierung nach Bedarf konvertieren besprechen werden.

Anspruchsbasierte Autorisierung

Wie im vorherigen Artikel erwähnt, erwartet die rollenbasierte Sicherheit in .NET Framework, dass jedem Thread ein Sicherheitsprinzipal zugeordnet ist. Das Sicherheitsprinzipal anhand von IPrincipal, die Identität des authentifizierten Benutzers in einer IIdentity-Implementierung einschließt. WIF liefert ClaimsPrincipal und ClaimsIdentity Typen basierend auf IClaimsPrincipal und IClaimsIdentity (die letzten Endes von IPrincipal und IIdentity abgeleitet werden). Bei der Verarbeitung der FAM-Anmeldung-Antwort hydrates es eine ClaimsPrincipal für das ausgestelltes Sicherheitstoken. Die Sicherheitskontenverwaltung hydrates ebenso eine ClaimsPrincipal für das Sitzungscookie. Diese ClaimsPrincipal ist das Kernstück der WIF-Autorisierung für die ASP.NET-Anwendung.

Sie können eine der folgenden Vorgehensweisen zur Autorisierung verwenden:

Verwenden Sie standortspezifische Autorisierungseinstellungen zum Einschränken des Zugriffs auf Verzeichnisse oder einzelne Anwendungsressourcen.
Verwenden Sie zum Steuern des Zugriffs auf die Funktionalität ASP.NET-Anmeldesteuerelemente, wie z. B. das LoginView-Steuerelement.
Verwenden Sie ClaimsPrincipal, um dynamische IsInRole-Überprüfungen (z. B. dynamisch ausblenden oder Einblenden von UI-Elementen) durchführen.
Verwenden Sie den PrincipalPermission-Typ, um dynamische Berechtigungsanforderungen oder das PrincipalPermissionAttribute durchzuführen, wenn deklarative Berechtigungsanforderung auf eine bestimmte Methode geeignet scheint.
Bereitstellen einer benutzerdefinierten ClaimsAuthorizationManager Zugriff zentralisieren in einer einzelnen Komponente, sogar vor dem Laden der angeforderten Ressource überprüft.

Die ersten drei Optionen basieren auf der IsInRole-Methode, die von der ClaimsPrincipal-Typ verfügbar gemacht werden. Wählen Sie eine Rolle Anspruch Typ passt für die IsInRole-Prüfung, damit die richtigen Ansprüche für die Zugriffssteuerung verwendet werden. Der Standardtyp einer Rolle Anspruch für WIF ist:

https://schemas.microsoft.com/ws/2008/06/identity/claims/role

ClaimsPrincipal definierten Ansprüche enthält, entspricht der Anspruchstyp Rolle die Standardeinstellung. Später wird die Berechtigung Ansprüche im Kontext der Anspruchstransformation erläutert. Wenn diese verwendet werden, sollten Sie den Anspruchstyp Berechtigung als den Anspruchstyp Rolle angeben, so dass IsInRole wirksam werden.

Sie können den Zugriff auf bestimmte Seiten oder Verzeichnisse aus der Datei web.config Global steuern. Geben Sie im Stammverzeichnis Anwendung ein Location-Tag angeben des Pfades zu schützen, können eine Liste der zulässigen Rollen und anderen Benutzern den Zugang verweigern. Der folgende Code kann nur Administratoren Zugriff auf Dateien unterhalb des Verzeichnisses AdminOnly:

<location path="AdminOnly">
  <system.web>
    <authorization>
      <allow roles="Administrators" />
      <deny users="*"/>
    </authorization>
  </system.web>
</location>

Als Alternative können Sie eine web.config in einem Unterverzeichnis einfügen und Festlegen von Autorisierungsregeln. Die folgende Konfiguration im Verzeichnis AdminOnly platzieren, wird dasselbe Ergebnis erzielt:

<configuration>
  <system.web>
    <authorization >
      <allow roles="Administrators" />
      <deny users="*"/>
    </authorization>
  </system.web>
</configuration>

Nutzen Sie dynamisch ausblenden und Anzeigen von UI-Komponenten oder andernfalls steuern den Zugriff auf Funktionen auf einer Seite, Features der Steuerelemente, z. B. das LoginView-Rolle. Bevorzugen jedoch die meisten Entwickler explizit Steuerelement festgelegt, für eine präzisere Steuerung Eigenschaften für die Zugriffssteuerung, während die Seite geladen. Rufen Sie hierzu die IsInRole-Methode von Ansprüchen Principal verfügbar gemacht werden. Der aktuelle Principal kann über die statische Eigenschaft Thread.CurrentPrincipal wie folgt zugegriffen werden:

if (!Thread.CurrentPrincipal.IsInRole("Administrators"))
  throw new SecurityException("Access is denied.");

Abgesehen von expliziten IsInRole Überprüfungen zur Laufzeit können Sie auch schreiben klassische rollenbasierte Berechtigungsanforderungen mithilfe des Principals Permission-Typ. Sie initialisieren den Typ mit dem erforderlichen Rollenanspruch (der zweite Konstruktorparameter), und sobald "Demand" (Anfordern) aufgerufen wird, wird die "IsInRole"-Methode des aktuellen Prinzipals aufgerufen. Wenn der Anspruch nicht gefunden wird, wird eine Ausnahme ausgelöst:

PrincipalPermission p = 
  new PrincipalPermission("", "Administrators");
p.Demand();

Dieser Ansatz eignet sich für die Ablehnung einer Anforderung mit einer Ausnahme, wenn die entsprechenden Rollen nicht vorhanden sind.

Es ist auch hilfreich, um Autorisierungsüberprüfungen für alle angeforderten Ressourcen zu zentralisieren. In manchen Fällen ist eine Zugangssteuerungsrichtlinie – z. B. Regeln, die in einer Datenbank gespeichert, können Sie eine zentrale Komponente diesen Regeln zur Steuerung des Zugriffs auf die Features und Funktionen zu lesen. Dafür bietet WIF eine ClaimsAuthorizationManager-Komponente, die Sie erweitern können. Zurückrufen von meiner früheren Artikel, diese Art von benutzerdefinierten Komponente in der Identitätsabschnitt Modell konfigurieren können:

<microsoft.identityModel>
  <service>
    <!--other settings-->
    <claimsAuthorizationManager 
      type="CustomClaimsAuthorizationManager"/>
  </service>
</microsoft.identityModel>

Abbildung 7 veranschaulicht eine benutzerdefinierte ClaimsAuthorizationManager, das das Vorhandensein des Anspruchs Namen überprüft, und gibt an, ob die angeforderte Ressource innerhalb des Verzeichnisses AdminsOnly ist der Rollenanspruch Administratoren benötigt.

Abbildung 7 Benutzerdefinierte "ClaimsAuthorizationManager"-Implementierung

public class CustomClaimsAuthorizationManager: 
  ClaimsAuthorizationManager {

  public CustomClaimsAuthorizationManager()
  { }

  public override bool CheckAccess(
    AuthorizationContext context) {

    ClaimsIdentity claimsIdentity = 
      context.Principal.Identity as ClaimsIdentity;
    if (claimsIdentity.Claims.Where(
      x => x.ClaimType == ClaimTypes.Name).Count() <= 0)
      throw new SecurityException("Access is denied.");
        
    IEnumerable<Claim> resourceClaims = 
      context.Resource.Where(x=>x.ClaimType==ClaimTypes.Name);
    if (resourceClaims.Count() > 0) {
      foreach (Claim c in resourceClaims) {
        if (c.Value.Contains("\AdminOnly") && 
          !context.Principal.IsInRole("Administrators"))
          throw new SecurityException("Access is denied.");
      }
    }

    return true;
  }
}

Die CustomClaimsAuthorizationManager überschreibt Check Zugriff auf diese Funktionalität bereitstellen. Diese Methode stellt einen AuthorizationContext-Parameter Informationen zur Aktivität Anforderung stellt (für passiven Verbund Dies ist ein HTTP-Verb z. B. GET oder POST), der angeforderten Ressource (URI) und Ansprüche Principal, die noch nicht an den Anforderungsthread angefügt ist.

Anspruchstransformation

Häufig sind die Ansprüche, die von der IP-STS ausgestellt werden, zwar hilfreich für die Beschreibung des authentifizierten Benutzers nicht relevant für die Autorisierungsanforderungen die RP. Es ist nicht die IdP Auftrag zu wissen, welche Art von Rollen, Berechtigungen oder andere fein abgestufte Artefakt für die Autorisierung bei einzelnen RP erforderlich ist. Ist die IdP Auftrag Ansprüche, die der Identität Anbieter Domäne relevanten Ansprüche zu gewähren, die über den authentifizierten Benutzer die IdP bestätigen kann.

Die RP müssen als solche möglicherweise vom IP-STS Ansprüche in etwas mehr relevant für die Autorisierung zu transformieren. Dies impliziert, dass die RP (z. B. von User Name oder UPN) die Identität des Benutzers zuordnen kann, um einen Satz von Ansprüchen RP. Der IP-STS gewährt standardmäßig Rolle Ansprüche vorausgesetzt, Abbildung 8 Listen ein möglicher Satz von Berechtigungen vorgibt, dass die RP ausstellen kann auf Grundlage jeder eingehenden Rollenanspruch. Der Anspruchstyp Berechtigung möglicherweise einen benutzerdefinierten Anspruchstyp durch die RP definiert sind, wie z. B.:

urn:ClaimsAwareWebSite/2010/01/claims/permission

Eine benutzerdefinierte ClaimsAuthenticationManager ist ein guter Ausgangspunkt, um eingehende IP-STS Ansprüche zu transformieren. Sie können eine benutzerdefinierte ClaimsAuthenticationManager durch Hinzufügen der Folgendes Abschnitt microsoft.identityModel installieren:

<microsoft.identityModel>
  <service>
    <!--other settings-->
    <claimsAuthenticationManager 
      type="CustomClaimsAuthenticationManager"/>
  </service>
</microsoft.identityModel>

Abbildung 9 zeigt ein Beispiel des CustomClaimsAuthenticationManager, die eingehende Rolle Ansprüche vom IP-STS in Ansprüche über die Berechtigung, die relevant für die RP gewährt umwandelt.

Abbildung 8 Transformieren von Rolle Berechtigungen Ansprüche an die RP vorgibt

Rolle anfordern	Berechtigung Ansprüchen
Administratoren	Erstellen, lesen, aktualisieren, löschen
Benutzer	Erstellen, lesen, aktualisieren
Gast	Read

Abbildung 9 benutzerdefinierte Ansprüche Transformation auf die RP

public class CustomClaimsAuthenticationManager: 
  ClaimsAuthenticationManager {

  public CustomClaimsAuthenticationManager() { }

  public override IClaimsPrincipal Authenticate(
    string resourceName, IClaimsPrincipal incomingPrincipal) {

    IClaimsPrincipal cp = incomingPrincipal;
    ClaimsIdentityCollection claimsIds = 
      new ClaimsIdentityCollection();

    if (incomingPrincipal != null && 
      incomingPrincipal.Identity.IsAuthenticated == true) {

      ClaimsIdentity newClaimsId = new ClaimsIdentity(
        "CustomClaimsAuthenticationManager", ClaimTypes.Name, 
        "urn:ClaimsAwareWebSite/2010/01/claims/permission");

      ClaimsIdentity claimsId = 
        incomingPrincipal.Identity as ClaimsIdentity;
      foreach (Claim c in claimsId.Claims)
        newClaimsId.Claims.Add(new Claim(
          c.ClaimType, c.Value, c.ValueType, 
          "CustomClaimsAuthenticationManager", c.Issuer));

      if (incomingPrincipal.IsInRole("Administrators")) {
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Create"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Read"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Update"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Delete"));
      }

      else if (incomingPrincipal.IsInRole("Users")) {
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Create"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Read"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Update"));
      }

      else {
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Read"));
      }

      claimsIds.Add(newClaimsId);
      cp = new ClaimsPrincipal(claimsIds);
    }

    return cp;
  }
}

Für die Überprüfung von IsInRole (wie weiter oben beschrieben) arbeiten, erforderlich den Anspruchstyp Berechtigungen wie die Rolle behaupten Typ. Abbildung 9 ist dies angegeben, wenn das ClaimsIdentity konstruiert wird, da die RP das ClaimsIdentity erstellt.

In dem Fall, in dem eingehende SAML-Tokens die Quelle der Ansprüche sind, können Sie den Rolle Ansprüche Typ für die SecurityTokenHandler bereitstellen. Der folgende Code veranschaulicht, wie deklarativ konfiguriert die Saml11SecurityTokenHandler den Anspruchstyp Berechtigung verwenden, wie die Rolle behaupten Typ:

<microsoft.identityModel>
  <service>
    <!--other settings-->
    <securityTokenHandlers>
      <remove type="Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
      <add type="Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
        <samlSecurityTokenRequirement >
          <roleClaimType 
            value= "urn:ClaimsAwareWebSite/2010/01/claims/permission"/>
        </samlSecurityTokenRequirement>
      </add>
    </securityTokenHandlers>
  </service>
</microsoft.identityModel>

SAML-token-Handler haben einen Abschnitt SamlSecurityTokenRequirement, können Sie eine Einstellung für den Namen bereitstellen und Rolle behaupten Typ zusammen mit anderen Einstellungen im Zusammenhang mit der Zertifikatsüberprüfung und Windows-Token.

Home Realm Discovery

Ich haben bisher auf einem einfachen Verbundszenario mit einer einzigen IP-STS konzentriert. Es wird davon ausgegangen, dass die RP immer eine bestimmte IP-STS zum Authentifizieren der Benutzer umleitet.

In der Welt der Föderation kann die RP jedoch mehrere token Aussteller aus mehreren Domänen vertrauen. Eine neue Herausforderung stellt sich selbst in diesem Fall, da die RP entscheiden muss, welche die IP-STS zu authentifizieren, sollten Benutzer, die Zugriff auf Ressourcen anfordern. Die Domäne, an die Benutzer zu authentifizieren, wird als home Realm des Benutzers bezeichnet, und daher ist dieser Vorgang home Realm Discovery bezeichnet.

Es gibt eine Reihe von Mechanismen, die eine Anwendung zu Hause Bereichserkennung verwenden kann:

Wie im aktuellen Beispiel home Realm in bekannt ist werden Anforderungen für erweiterte und in diesem Fall immer zu einer bestimmten IP-STS umgeleitet.
Benutzer können auf die RP aus einem anderen Portal durchsuchen, die eine Abfragezeichenfolge an die home Realm für Benutzer von diesem Portal bereitstellen können.
Die RP erfordern, dass Benutzer Land auf einen bestimmten Eintrittsseite für jeden privaten Bereich. Die Detailseite konnte einen bestimmten privaten Bereich angenommen.
Die RP kann den privaten Bereich durch die IP-Adresse der Anforderung oder einige andere Heuristik ermitteln können.
Wenn die RP home-Bereich aus einem der oben genannten Methoden nicht ermitteln kann, kann es eine Benutzeroberfläche darstellen, in dem der Benutzer den privaten Bereich auswählen oder enthalten Informationen, die die RP, dies zu ermitteln kann.
Die RP Informationskarten unterstützt, kann die ausgewählte Smartcard-Authentifizierung zum entsprechenden privaten Bereichsnamen mit aktiven Föderation Laufwerk.
Die WS-Federation beschreibt kurz, wie eine Discovery-Dienst zum Auflösen von home Realm implementiert werden kann, aber es ist nicht klar definierten Spezifikation für diese.

Das Ziel ist unabhängig davon, wie die home Realm erkannt wird leiten Sie den Benutzer mit der richtigen IP-STS zu authentifizieren. Es gibt einige mögliche Szenarios. In einem Szenario müssen die RP des Ausstellers URI dynamisch festlegen, sodass die Anforderung-Anmeldung an der richtigen IP-STS gesendet wird. In diesem Fall muss die RP alle vertrauenswürdigen IP-STS im Abschnitt TrustedIssuers z. B. auflisten:

<trustedIssuers>
  <add thumbprint="6b887123330ae8d26c3e2ea3bb7a489fd609a076" 
    name="IP1" />
  <add thumbprint="d5bf17e2bf84cf2b35a86ea967ebab838d3d0747" 
    name="IP2" />
</trustedIssuers>

Darüber hinaus können Sie überschreiben verfügbar gemacht werden, indem die FAM RedirectingToIdentityProvider-Ereignis und mit relevanten Heuristik, den entsprechenden URI für den STS bestimmen. Platzieren Sie hierzu den folgenden Code in der Global.asax-Implementierung:

void WSFederationAuthenticationModule_RedirectingToIdentityProvider(
  object sender, RedirectingToIdentityProviderEventArgs e) {
  if (e.SignInRequestMessage.RequestUrl.Contains(
    "IP1RealmEntry.aspx")) {
    e.SignInRequestMessage.BaseUri = 
      new Uri("https://localhost/IP1/STS/Default.aspx");
  }
  else if (e.SignInRequestMessage.RequestUrl.Contains(
    "IP2RealmEntry.aspx")) {
    e.SignInRequestMessage.BaseUri = new Uri(
       "https://localhost/IP2/STS/Default.aspx");
  }
}

Andere Szenarios umfasst mit der Anforderung-Anmeldung auf dem primären STS den home Realm-Parameter (Whr) übergeben wird. Die RP, z. B. eine Ressource STS (R-STS oder RP-STS) verantwortlich für die Anspruchstransformation möglicherweise. Vertrauensstellungen mit anderen IdPs hat, jedoch die RP-STS nicht authentifizieren von Benutzern, die (es ist kein IdP).

Die RP besitzt eine Vertrauensstellung mit dem RP-STS und wird von der RP-STS ausgestellten Token immer berücksichtigt. Die RP-STS ist verantwortlich für das Umleiten an das richtige IdP für jede Anforderung. Der RP-STS der richtigen IP-STS umleiten an wie im oben beschriebenen Code bestimmen können, aber eine weitere Option ist für die RP, um Informationen zu den privaten Bereich, dies im privaten Bereich Parameter übergeben, um die RP-STS bereitzustellen. In diesem Fall legt die RP dynamisch home Realm-Parameter:

void WSFederationAuthenticationModule_RedirectingToIdentityProvider(
  object sender, RedirectingToIdentityProviderEventArgs e) {
  if (e.SignInRequestMessage.RequestUrl.Contains(
    "IP1RealmEntry.aspx")) {
    e.SignInRequestMessage.HomeRealm = 
      "https://localhost/IP1/STS/Default.aspx";
  }
  else if (e.SignInRequestMessage.RequestUrl.Contains(
    "IP2RealmEntry.aspx")) {
    e.SignInRequestMessage.HomeRealm = 
      "https://localhost/IP2/STS/Default.aspx";
  }
}

Die RP-STS verwendet diesen Parameter an die korrekte IP-STS umleiten und transformiert anschließend vom IP-STS Ansprüche in Ansprüche für die RP relevant.

Single Sign-On und eine Abmeldung

Einmaliges Anmelden und Abmelden einzelne sind wichtige Teile der Föderation. Einmaliges Anmelden ist eine Funktion, die authentifizierte Benutzer mehrere RP-Anwendungen zugreifen, während Sie nur einmal authentifizieren kann. Einzelne abmelden, erleichtert wie er sagt, die Abmeldung aus allen RP-Anwendungen und alle relevanten STS-Kette mit einer Anforderung.

In einer einfachen Föderation dargestellt Szenario, in Abbildung 1 , der Benutzer authentifiziert sich der IP-STS und an die RP basierend auf dem ausgestelltes Sicherheitstoken autorisiert ist. Post-Authentication, hat der Benutzer einen Sitzungscookie für den STS und einen weiteren für die RP. Jetzt, wenn der Benutzer ein anderes RP aufruft, wird er umgeleitet, auf der IP-STS für die Authentifizierung – vorausgesetzt, beide Anwendungen RP derselben IP-STS vertrauen. Da der Benutzer bereits eine Sitzung mit der IP-STS verfügt, werden der STS Token ohne Aufforderung zur Eingabe der Anmeldeinformationen für die zweite RP ausstellen. Der Benutzer hat Zugriff auf die zweite RP jetzt und verfügt über einen neues Sitzungscookie für die zweite RP.

Wie ich bereits erwähnt habe, gibt WIF SAM das Sitzungscookie für authentifizierte Benutzer zu schreiben. Standardmäßig wird das Sitzungscookie für die Anwendung relative Adresse für die Domäne ausgestellt und seine Basisnamen ist FedAuth. Da föderativen Sitzungscookies groß sein können, ist das Token in der Regel in zwei (oder mehr) Cookies unterteilt: FedAuth FedAuth1, und So weiter.

Wenn Sie mehrere Anwendungen in der gleichen Domäne als Teil der Verbundszenario Hosten des Standardverhaltens wäre, dass der Browser Cookies FedAuth für jede RP verfügt (siehe Abbildung 10 ). Der Browser sendet nur diese die Domäne und den Pfad für die Anforderung zugeordneten Cookies.

Sitzungscookies zugeordnete einzelnen RP und der STS

Abbildung 10 Sitzungscookies zugeordnete einzelnen RP und der STS

Dieses Standardverhalten ist normalerweise kein Problem, aber manchmal ist es erforderlich, geben Sie einen eindeutigen Namen für jede Sitzungscookie von pro Anwendung – insbesondere, wenn Sie in derselben Domäne gehostet werden. Oder mehrere Anwendungen in der gleichen Domäne einen Sitzungscookie freigeben können in diesem Fall legen den Cookiepfad auf “ / ”.

Wenn das Sitzungscookie abläuft, der Browser wird aus dem Cache entfernt, und der Benutzer wieder zu der STS für die Authentifizierung umgeleitet wird. Das ausgestellte Token zugeordneten das Sitzungscookie abgelaufen ist, werden separat WIF der STS für ein neues Token umgeleitet.

Abmeldung explizitere wird – in der Regel durch den Benutzer gesteuert. Einzelne ist Abmeldung eine optionale Funktion der WS-Federation-Spezifikation, die vorschlägt, der STS auch andere Anwendungen RP benachrichtigen sollte für die es Token der Abmeldung Anforderung ausgegeben hat. Auf diese Weise wird das Sitzungscookie für alle Anwendungen entfernt, der Benutzer während der Sitzung anmelden, aufgerufen. In einem komplexeren Szenario, in dem mehrere STSs beteiligt sind, sollten der primäre STS Abmeldung Anforderung empfangen auch andere STSs auf dasselbe benachrichtigen.

Zum Zweck der Diskussion werde ich mich konzentrieren auf, wie Sie auf die RP föderativen einzelne Abmeldung erleichtern soll. Sie können FederatedPassiveSignInStatus-Steuerelement auf einer beliebigen Seite platzieren, von denen Sie unterstützen möchten, anmelden und Abmelden und zeigt das Steuerelement seinen Zustand automatisch. Einmal angemeldet-in das Steuerelement stellt eine Verknüpfung, Schaltfläche oder das Symbol abmelden.

Wenn Sie auf das Steuerelement klicken, verarbeitet es nach der Eigenschaft SignOutAction Abmeldung der aktualisieren, umleiten, RedirectToLoginPage oder FederatedPassiveSignOut sein kann. Die ersten drei das Sitzungscookie für die Anwendung zu löschen, aber nicht der STS der Abmeldung Anforderung zu benachrichtigen. Wenn Sie die Einstellung FederatedPassiveSignOut auswählen, wird das Steuerelement SignOut auf WSFederationAuthenticationModule aufrufen. Dadurch wird sichergestellt, dass für die Anwendung verbundenen Sitzungscookies entfernt werden. Darüber hinaus wird eine Abmeldung Anforderung an den STS gesendet:

GET https://localhost/IP1/STS?wa=wsignout1.0

Wenn Sie das Steuerelement FederatedPassiveSignInStatus nicht verwenden, können Sie direkt WSFederationAuthenticationModule.SignOut auslösen, eine Umleitung auf den STS die Abmeldung Anforderung aufrufen.

Einzelne impliziert abmelden, aus der alle Anwendungen der Benutzer er mit Ihrem Verbundidentität angemeldet ist bei angemeldet. Der STS unterstützt dies, sollten Sie eine Liste der RP-Anwendungen enthalten der Benutzer angemeldet während Ihre Sitzung und das Problem eine Bereinigung Anforderung auf einzelnen RP beim Abmelden im Zusammenschluss angefordert wird:

GET https://localhost/ClaimsAwareWebSite?wa=wsignoutcleanup1.0

In komplexen Szenarien soll derselben Cleanup-Anforderung an eine beliebige andere STS in der verbundenen Sitzung gesendet werden. Zu diesem Zweck müsste der STS Kenntnisse des Cleanup-URIS für die einzelnen RP und STS haben. Zur Unterstützung von einzelnen abmelden, die RP diese Bereinigung Anforderungen verarbeiten sollte. Die FAM, und das Steuerelement FederatedPassiveSignInStatus unterstützt. Wenn Sie die FAM verwenden, kann die Bereinigung Anforderung zum an die RP-URI gebucht werden und die FAM verarbeitet die Anforderung und alle Sitzungscookies bereinigen. Wenn Sie FederatedPassiveSignInStatus-Steuerelement verwenden, muss die Bereinigung Anforderung einer Seite gebucht werden, die das Steuerelement enthält.

In der Tat ist die Spezifikation WS-Federation nicht zum Implementieren von einzelnen abmelden und Bereinigungen Verhalten außerhalb der empfohlenen Abfragezeichenfolgen und Kommunikationsflusses detailliert. Es ist nicht leicht zu garantieren, einzelne Abmeldung wird effektiv über alle Föderationspartner Folglich werden, aber bei der Umgebung und möchten erreichen dieses Ziels ist in der Tat möglich.

Michele Leroux Bustamante ist leitender Architekt bei IDesign (idesign.net) und für die Sicherheit-Architekt bei BiTKOO (bitkoo.com ). Er ist auch ein regionalen Microsoft-Director für San Diego und Microsoft MVP für verbundene Systeme. Besuchen Sie Ihren Blog unter dasblonde.net-.

Dank an den folgenden technischen Experten für die Überprüfung der in diesem Artikel: Govind Ramanathan

Share via