(0) exportieren Drucken
Alle erweitern

Hinzufügen von einmaligem Anmelden zu einer Webanwendung mithilfe von Azure AD

Letzte Aktualisierung: Mai 2014

noteHinweis
Dieses Beispiel ist veraltet. Die Technologie sowie die Methoden und/oder Anweisungen zur Benutzeroberfläche wurden durch neuere Funktionen ersetzt. Unter WebApp-OpenIDConnect-DotNet finden Sie ein aktualisiertes Beispiel, in dem eine ähnliche Anwendung erstellt wird.

.

Diese exemplarische Vorgehensweise zeigt Ihnen, wie Azure AD zum Implementieren der einmaligen Webanmeldung in einer ASP.NET-Anwendung verwendet wird. In den Anweisungen wird hauptsächlich der Verzeichnismandant genutzt, der Ihrem Azure-Abonnement zugeordnet ist, da dieser im Hinblick auf Identitätsanbieter für Branchenanwendungen (LoB-Anwendungen) in Ihrer Organisation die optimale Wahl darstellt.

Eine Lösung für einmalige Webanmeldung umfasst normalerweise die Konfiguration einer Webanwendung zum Auslagern der Authentifizierungsfunktionen an eine externe Entität, die häufig als Identitätsanbieter (Identity Provider, IdP) bezeichnet wird. Konkret bedeutet dies, dass die Anwendung für das Weiterleiten nicht authentifizierter Anforderungen an den IdP gemäß einem Anmeldeprotokoll (z. B. SAML-P, WS-Verbund oder OpenID Connect) konfiguriert wird.

Die Autorisierungsstelle (oder der IdP) ist für die Authentifizierungserfahrung verantwortlich. Normalerweise muss die Webanwendung über einen Bereitstellungsvorgang bereits bekannt sein. Nach der erfolgreichen Authentifizierung wird der Browser zusammen mit einem Sicherheitstoken, das Informationen zum eingehenden Benutzer enthält, zurück an die Web-App geleitet. Die Anwendung überprüft das Token. Dies geschieht normalerweise über identitätsfähige Middleware. Wenn die Überprüfung erfolgreich ist, wird der Benutzer als authentifiziert betrachtet und angemeldet.

Diese allgemeine Beschreibung gilt auch für Azure AD. In diesem Dokument wird gezeigt, wie Sie Visual Studio 2012 und die WIF-Klassen (Windows Identity Foundation) in .NET Framework 4.5 zum Konfigurieren einer MVC 4-Anwendung für die Verwendung eines Webanmeldeprotokolls verwenden. Sie erfahren, wie dieselbe Anwendung in einem Azure AD-Mandanten bereitgestellt wird und wie die Anmeldeeinstellungen der Anwendung konfiguriert werden, um eine Verbindung mit diesem Mandanten herzustellen. Am Ende dieser Vorgehensweise verfügen Sie über eine funktionstüchtige Webanwendung, die vollständig für einmaliges Anmelden der Organisation konfiguriert ist.

Das Ziel dieser exemplarischen Vorgehensweise besteht darin, die Funktionsweise von Azure AD zu vermitteln: zu diesem Zweck ist mehr erforderlich als eine Anleitung zum Zusammenstellen der hier beschriebenen vereinfachten Lösung. Sie erhalten in diesem Dokument nicht nur konkrete Anweisungen zum Erstellen eines funktionsfähigen Beispiels, sondern erfahren auch etwas über die Artefakte und Konzepte, um Azure AD kennenzulernen und zu verstehen, wie Sie dessen Funktionen auch außerhalb des spezifischen, hier beschriebenen Szenarios nutzen können. Diese zusätzlichen Abschnitte, die als Hinweise formatiert sind, sind nicht unbedingt für das Ausführen der exemplarischen Vorgehensweise erforderlich. Wenn Sie jedoch daran interessiert sind, Azure AD in Ihren eigenen Lösungen zu verwenden, wird empfohlen, auch diese Hinweise zu lesen.

Dieser Lernprogrammteil dieses Dokuments ist in die folgenden Abschnitte unterteilt:

  • Voraussetzungen: In diesem Abschnitt werden alle Voraussetzungen aufgelistet, die erfüllt sein müssen, um die exemplarische Vorgehensweise abschließen zu können.

  • Lösungsarchitektur: Dieser Abschnitt bietet eine Einführung in Web-SSO-Lösungen für Brachenanwendungen (LoB-Anwendungen) auf Übersichtsebene. Die funktionalen Komponenten werden untersucht, die SSO ermöglichen, und das Einrichten des Gerüsts wird beschrieben, das Sie später anhand der Anweisungen in diesem Dokument ergänzen.

  • Arbeiten mit einem Azure AD-Verzeichnismandanten: In diesem Abschnitt werden Azure AD-Mandanten und die Funktionen vorgestellt, die im Szenario eine Rolle spielen. Außerdem werden die Hauptelemente im Abschnitt Active Directory des Azure-Verwaltungsportals kurz beschrieben.

  • Verbinden der Anwendung mit Azure AD: In diesem Abschnitt wird gezeigt, wie die Identitäts- und Zugriffstools für Visual Studio 2012 zum Aktivieren der einmaligen Webanmeldung in der MVC-Anwendung verwendet und die Authentifizierungseinstellungen an den ausgewählten, spezifischen Azure AD-Mandanten gebunden werden.

  • Erweiterte Themen: Dieser Abschnitt lässt die Grundlagen hinter sich und bietet vertiefende Informationen zu einigen Schlüsselthemen. Außerdem werden einige der weiteren Aufgaben behandelt, die Sie ggf. ausführen müssen, um Ihre Anwendung zu optimieren.

Die folgenden Voraussetzungen müssen erfüllt sein, um dieses Lernprogramm abzuschließen:

Wenn Sie Fragen haben oder Hilfe benötigen, lesen Sie Preparing for Azure AD Solutions and Scenarios.

Architektur einer Einzelinstanzanwendung

In dieser exemplarischen Vorgehensweise wird schwerpunktmäßig das folgende Szenario behandelt: Ein Entwickler verfügt über eine Webanwendung, die er in der Cloud bereitstellen möchte. Außerdem soll nur Benutzern eines Azure Active Directory-Mandanten der Zugriff gewährt werden. Er muss die folgenden Ausgaben ausführen, um dieses Ziel zu erreichen:

  1. Registrieren der Web-App in Ihrem Azure AD-Mandanten. Nachdem die App bekannt ist, akzeptiert Azure AD die Authentifizierungsanforderungen von Benutzern.

  2. Hinzufügen vorgeschalteter Komponenten zur App, damit Folgendes erreicht wird:

    1. Nicht authentifizierte Anforderungen können blockiert und an den richtigen Azure AD-Mandanten für die Benutzerauthentifizierung umgeleitet werden.

    2. Benutzer, die die Authentifizierung bei Azure AD ausgeführt haben, können erkannt werden, und ihnen kann der Zugriff erteilt werden.

Die Implementierung des ersten Schritts wird mithilfe des Azure-Verwaltungsportals ausgeführt. Sie erfahren, wie ein neuer Azure AD-Mandant innerhalb Ihres Azure-Abonnements bereitgestellt wird und wie die Funktionen des Azure AD-Verwaltungsportals zum Registrieren einer Anwendung verwendet werden.

Schritt 2 kann mithilfe einer Vielzahl von Protokollen auf hoher Ebene implementiert werden, die Authentifizierungsvorgänge über Organisationsgrenzen hinweg oder sogar das Internet erlauben.

Auf der .NET-Plattform läuft der zweite Schritt darauf hinaus, die Klassen zu konfigurieren, die in .NET für das Arbeiten mit anspruchsbasierten Identitäten und Verbundauthentifizierung integriert sind. Diese Klassen werden zusammen als WIF (Windows Identity Foundation) bezeichnet, und sie umfassen HTTP-Module und Konfigurationseinstellungen, die zum Hinzufügen der Abfangebene verwendet werden können, die die Umleitungs- und Authentifizierungsaufgaben ausführt, die in Schritt 2 vorgestellt werden. Visual Studio 2012 stellt Tools zur Verfügung, die Sie beim automatischen Konfigurieren von Web-Apps für die Verwendung von WIF zum Auslagern der Authentifizierung an externe Autorisierungsstellen unterstützen, die bestimmte SSO-Webprotokolle wie WS-Verbund unterstützen. In dieser exemplarischen Vorgehensweise erfahren Sie, wie solche Tools mit Azure AD verwendet werden.

Azure Active Directory ist der Dienst, der den Identitätsbackbone für Microsoft-Angebote wie Office 365 und Windows Intune bereitstellt. Wenn Sie diese Dienste abonnieren und den Verzeichnismandanten wiederverwenden möchten, der einem dieser Dienste zugeordnet ist, erstellen Sie ein neues Azure-Abonnement und verwenden die Funktion Benutzer hinzufügen, um einen Administrator aus diesem Mandanten hinzuzufügen. Diese exemplarische Vorgehensweise stellt keine ausführlichen Anweisungen zu diesem Vorgang zur Verfügung.

Jedes Abonnement verfügt über einen Azure AD-Mandanten und ein zugehöriges Verzeichnis. Wenn der Mandant automatisch generiert wurde, trägt das Verzeichnis den Namen Standardverzeichnis. Sie können diesen Namen jedoch ändern. In diesem Teil der exemplarischen Vorgehensweise fügen Sie dem Verzeichnis einen Benutzer und dann eine Anwendung hinzu.

Wenn ein Verzeichnismandant erstellt wird, wird er zu Speichern von Benutzern und Anmeldeinformationen in der Cloud konfiguriert. Ausführliche Anleitungen zum Integrieren Ihres Verzeichnismandanten in die lokale Bereitstellung von Windows Server Active Directory finden Sie unter Verzeichnisintegration.

Wenn Sie Fragen haben oder Hilfe benötigen, lesen Sie Preparing for Azure AD Solutions and Scenarios.

Die Azure AD-Szenarien und -Lösungen (und diese Codebeispiele und Beispielanwendungen) erfordern ein Benutzerkonto in der Domäne Ihres Azure Active Directory. Wenn Sie versuchen, sich bei der Anmeldung mit einem Microsoft-Konto anzumelden (z. B. einem Hotmail.com-, Live.com- oder Outlook.com-Konto) tritt bei der Anmeldung ein Fehler auf. Wenn in Ihrer Active Directory-Domäne bereits ein Benutzer mit einem Konto vorhanden ist (z. B. ein Konto Benutzer@Contoso.onmicrosoft.com), können Sie dieses für die Anmeldung in diesem Szenario verwenden. Andernfalls müssen Sie einen neuen Benutzer erstellen.

  1. Navigieren Sie zum Microsoft Azure-Verwaltungsportal (https://manage.WindowsAzure.com), melden Sie sich an, und klicken Sie dann auf Active Directory. (Hinweis für die Fehlerbehebung: Das Element "Active Directory" fehlt oder ist nicht verfügbar)

  2. Wenn Ihr Verzeichnis den Namen "Standardverzeichnis" trägt, fügen Sie ein Verzeichnis hinzu, z. B. "ContosoEngineering". Klicken Sie zum Hinzufügen eines Verzeichnisses unten auf der Active Directory-Seite auf Hinzufügen, und befolgen Sie dann die Anweisungen, um ein neues Verzeichnis hinzuzufügen.

  3. Doppelklicken Sie auf das Verzeichnis, und klicken Sie dann auf Domänen. Wenn Sie Ihre Benutzerkonten erstellen, verwenden Sie den Domänennamen, der auf der Seite angezeigt wird. Wenn Ihre Domänen z. B. den Namen ContosoEngineering@onmicrosoft.com trägt, erstellen Sie Benutzernamen in dieser Domäne, z. B. Test@ContosoEngineering@onmicrosoft.com.

  4. Klicken Sie zum Erstellen eines Benutzerkontos in der Domäne auf Benutzer. (Wenn keine Registerkarte Benutzer angezeigt wird, doppelklicken Sie auf den Verzeichnisnamen. Eine Registerkarte Benutzer wird auf jeder verzeichnisspezifischen Seite angezeigt.) Klicken Sie unten auf der Seite auf Benutzer hinzufügen.

  5. Wählen Sie Neuer Benutzer in Ihrer Organisation aus. Fügen Sie den Benutzer Ihrer neuen Domäne hinzu (z. B. Test@ContosoEngineering.onmicrosoft.com), und klicken Sie dann unten auf der Seite auf das Häkchen.

    Eingeben des Benutzernamens und der Domäne
  6. Weisen Sie dem Benutzer auf der Seite Benutzerprofil eine Organisationsrolle zu. Für Testzwecke sollten idealerweise mindestens ein Benutzer in der globalen Administratorrolle und eine Benutzer in der Benutzerrolle vorhanden sein.

    Eingeben der Benutzerrolle

Im letzten Schritt wird im Azure-Verwaltungsportal ein temporäres Kennwort generiert, das der Benutzer bei der ersten Anmeldung verwendet. Nachdem die erste Anmeldung abgeschlossen ist, muss der Benutzer das temporäre Kennwort ändern. Sie müssen das temporäre Kennwort unbedingt speichern, weil es zum Testen des Szenarios verwendet wird.

An diesem Punkt verfügen Sie über einen Verzeichnismandanten mit einem gültigen Benutzer, für den eine Authentifizierungsautorisierungsstelle in diesem Szenario für einmalige Webanmeldung bereitgestellt werden soll.

Vorübergehendes Kennwort

  1. Sie beginnen das Projekt mit der Anwendungsbereitstellung. Öffnen Sie Visual Studio, klicken Sie auf Neues Projekt, und wählen Sie dann ASP.NET MVC 4-Webanwendung aus. Wählen Sie im Fenster Neues ASP.NET MVC 4-Projekt die Option Intranetanwendung aus, stellen Sie sicher, dass das Ansichtsmodul auf Razor festgelegt ist, und klicken Sie dann auf OK. In dieser exemplarischen Vorgehensweise wird ExpenseReport als Projektname verwendet.

    noteHinweis
    Diese exemplarische Vorgehensweise setzt voraus, dass Ihre Visual Studio-Installation mit den Standardeinstellungen konfiguriert ist. Wenn Sie grundlegende Konfigurationseinstellungen geändert haben (z. B. den Speicherort, an dem Webanwendungen zur Entwicklungszeit gehostet werden), müssen Sie die Anweisungen entsprechend anpassen.



    Neues Projekt in Visual Studio

    Sie können die Anweisungen in dieser exemplarischen Vorgehensweise auf beliebige vorhandene VS 2012-Webanwendungen oder MVC- oder Web Forms anwenden, wenn keine Programmlogik verwendet wird, die die ASP.NET-Anforderungsverarbeitungspipeline erheblich ändert. Aus Gründen der Einfachheit erstellen Sie hier jedoch ein ganz neues Projekt.

    noteHinweis
    Diese exemplarische Vorgehensweise stellt ausführliche Anweisungen zum Einrichten eines .NET-Projekts zur Verfügung. Die gleichen Ergebnisse können jedoch auch für andere Plattformen und Programmierumgebungen erzielt werden. Azure AD verwendet offene Protokolle für die Webanmeldungsfunktionen. Alle gängigen Plattformen stellen Bibliotheken und Tools zur Verfügung, die solche Protokolle unterstützen. Die Details der einzelnen Schritte müssen gemäß der Syntax und den Vorgehensweisen jeder Programmierumgebung angepasst werden. Die grobe Unterteilung der einzelnen Aufgaben ist jedoch allgemein gültig.

    Visual Studio erstellt ein neues MVC-Projekt für Sie, das bereits für die Ausführung unter IIS Express konfiguriert ist. Sie fügen diesem Projekt keine weiteren Funktionen hinzu, weil die Standardeinstellungen bereits ausreichend sind, um das Hinzufügen von Webanmeldung zu zeigen. Die einzige Ausnahme ist der Endpunkt, der von der Anwendung verwendet wird. Visual Studio konfiguriert Ihre Anwendung standardmäßig so, dass Inhalte mithilfe von HTTP bereitgestellt werden. Diese Vorgehensweise eignet sich jedoch nicht zum Einrichten sicherer Sitzungen, weil die Kommunikation nicht geschützt wäre und potenzielle Angreifer Cookies und Token stehlen könnten. Während der Entwicklungsphase ist dies nicht zwingend erforderlich, da Azure die Verwendung von HTTPS nicht strikt durchsetzt. Dennoch ist es eine bewährte Methode.

  2. Mit IIS Express ist die Aktivierung von HTTPS direkt aus Visual Studio sehr einfach. Wählen Sie Ihr Projekt im Projektmappen-Explorer aus, und legen Sie dann im Bereich Eigenschaften die Option SSL aktiviert auf True fest.

    Die SSL-URL, die zuvor leer war, zeigt nun eine neue Adresse an. Wählen Sie diese aus, und kopieren Sie sie in die Zwischenablage.



    Kopieren der SSL-URL

  3. Nun müssen Sie Visual Studio informieren, dass während des Debugvorgangs immer der HTTPS-Endpunkt verwendet werden soll. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt, und wählen Sie dann Eigenschaften aus. Klicken Sie auf der linken Seite auf die Registerkarte Web, führen Sie einen Bildlauf nach unten bis zur Option Lokalen IIS-Webserver verwenden aus, und fügen Sie dann die HTTPS-URL in das Feld Projekt-URL ein. Speichern Sie die Einstellungen (STRG+S), und schließen Sie dann die Registerkarte Eigenschaften.



    Ändern der Projekt-URL

    Sie verfügen jetzt über eine Anwendung, die so konfiguriert werden kann, dass sie Azure AD für die Anmeldung nutzt. Im nächsten Schritt informieren Sie Ihren Azure AD-Mandanten über diese spezielle App.

  1. Minimieren Sie Visual Studio, und navigieren Sie zurück zur Registerkarte Active Directory im Azure-Verwaltungsportal. An früherer Stelle in dieser exemplarischen Vorgehensweise haben Sie im Bereich Benutzer gearbeitet, jetzt verwenden Sie den Bereich Anwendungen. Klicken Sie oben auf der Seite auf Anwendungen.



    Integrierte Anwendungen

    In diesem Bereich werden die Anwendungen aufgelistet, die in Ihrem Mandanten registriert sind. Eine Anwendung gilt in einem Mandanten als registriert, wenn Folgendes zutrifft:

    • Für die Anwendung ist einen Eintrag im Verzeichnis vorhanden, der ihre Hauptmerkmale beschreibt: Name, zugehörige Endpunkte usw. Ausführliche Informationen folgen später.

    • Der Anwendung wurden Berechtigungen zum Ausführen eines Vorgangs im aktuellen Verzeichnismandanten erteilt. Diese Vorgänge reichen von der Anforderung eines Anmeldetokens bis hin zur Abfrage des Verzeichnisses. Ausführliche Informationen folgen auch hier später.

    ImportantWichtig
    Eine Anwendung kann die Vorteile von Azure AD erst nutzen, nachdem sie registriert wurde. Dies gilt aus Sicherheitsgründen (nur Apps, die der Administrator genehmigt, sollten zulässig sein) und aus praktischen Erwägungen (die Interaktion mit Azure AD bedingt die Verwendung bestimmter offener Protokolle, die ihrerseits Kenntnis der Schlüsselparameter erfordern, die die App beschreiben).

  2. Da dieser Verzeichnismandant soeben ganz neu erstellt wurde, ist die Liste der registrierten Anwendungen noch leer. Der erste Eintrag erfolgt tatsächlich für die Anwendung, die Sie soeben in Visual Studio erstellt haben. Dieser Abschnitt beschäftigt sich ausschließlich mit der Registrierung als App.

    Da dies die erste App ist, beginnen Sie, indem Sie auf der Befehlsleiste des Azure-Verwaltungsportals am unteren Bildschirmrand auf die Schaltfläche Hinzufügen klicken. Der folgende Bildschirm wird angezeigt:



    Erzählen Sie uns von Ihrer Anwendung.

    Die Registrierung einer App über das Azure-Verwaltungsportal ist wie ein klassischer Assistent aufgebaut. In den Folgebildschirme wird die Erfassung der erforderlichen Informationen gemäß Ihrer Auswahl gegliedert.

    Die Abbildung oben zeigt den ersten solchen Bildschirm. Die angebotenen Optionen sind klar strukturiert:

    • Anzeigename: Der hier eingegebene Text wird als lesbarer Name für die Anwendung verwendet, wenn ein Benutzer – sei es ein Administrator, der die Liste der registrierten Apps verwaltet, oder ein Kunde, der Verzeichniszugriff auf die App erteilt – die Anwendung verwalten muss. Weitere Informationen zu diesem Thema finden Sie im Dokument Entwickeln mehrinstanzenfähiger Webanwendungen mit Azure AD.

    • Zugriffstyp: Mithilfe dieser Sammlung von Optionsfeldern können Sie angeben, welche Vorgänge die App im Verzeichnismandanten ausführen darf. Für den Zweck dieses Lernprogramms, dessen Ziel es ist, die Konfiguration von Webanmeldung mit Ihrer App zu vereinfachen, ist die Option Einmaliges Anmelden die richtige Auswahl.

      noteHinweis
      Andere Dokumente behandeln das Thema der Anwendungsberechtigungen ausführlicher. Hier werden nur kurz die zugrunde liegenden Prinzipien für den Fall erläutert, dass Sie wissen möchten, was im Hintergrund geschieht.

      Azure AD stellt Anwendungen mithilfe einer Entität namens ServicePrincipal dar. Wie schon der Name besagt, sind diese Prinzipale analog zu den besser bekannten Benutzerprinzipalen zu sehen, dienen jedoch zur Beschreibung von Anwendungen.

      Der Vorgang der Registrierung einer Anwendung ist tatsächlich das Erstellen eines ServicePrincipals für die Anwendung im Mandanten der Verzeichnisinstanz, auf die die App Zugriff besitzen soll.

      Die Zugriffsebene, die einer bestimmten Anwendung erteilt werden sollte, wird durch die Rollen bestimmt, zu denen der entsprechende ServicePrincipal gehört. Wenn Sie die Zugriffsebenen Lese- und Schreibzugriff auswählen (in dieser exemplarischen Vorgehensweise nicht erforderlich), würden im Registrierungsvorgang weitere Schritte hinzugefügt, um weitere Informationen zu erfassen, z. B. welche Schlüssel für die Authentifizierung beim Ausführen solcher Abfragen verwendet werden sollen. In diesem Fall würden die Schlüssel ebenfalls im ServicePrincipal gespeichert, der die Anwendung beschreibt. Weitere Informationen dazu finden Sie im Thema Verwenden der Graph-API zum Abfragen von Azure AD.

      Die Berechtigungen, die durch die Anwendungsregistrierung erteilt werden, sind nur beim Zugriff auf das Verzeichnis selbst wirksam. Sie bestimmen nicht die Zugriffsrichtlinien für andere Azure-Ressourcen wie z. B. SQL Azure-Datenbanken, Abschnitte des Verwaltungsportals usw.

  3. Nachdem Sie den Namen der Anwendung eingegeben und den Zugriffstyp Eimaliges Anmelden ausgewählt haben, klicken Sie auf den Pfeil in der unteren rechten Ecke, um zum nächsten Bildschirm zu navigieren.

    Anwendungseigenschaften Auf diesem Bildschirm werden vom Azure-Verwaltungsportal wichtige Informationen gesammelt, die der Dienst zum Steuern des Anmeldeprotokollflusses benötigt. Folgendes müssen Sie eingeben:

    • App-URL: Dieser Parameter stellt den address Ihrer Webanwendung dar. In diesem Beispiel entspricht die Adresse https://localhost:44341/ – der Adresse, die IIS Express Ihrer Anwendung zugewiesen hat. Wenn Sie die Anweisungen bis jetzt genau befolgt haben, sollten diese Adresse noch in der Zwischenablage vorhanden sein und kann nun eingefügt werden. Der Wert, den Sie eingeben, ist für die Dauer der Entwicklungsphase gültig. Sobald Sie Ihre Anwendung in der Zielstaging- oder Produktionsumgebung bereitstellen, müssen Sie das Verwaltungsportal erneut besuchen und die Adresse so ändern, dass sie mit dem Speicherort der neuen Anwendung übereinstimmt. Später in dieser exemplarischen Vorgehensweise wird erläutert, wie dieser Vorgang ausgeführt wird.

      WarningWarnung
      Azure AD muss die Adresse Ihrer Anwendung bekannt sein, damit der Datenfluss nach der erfolgreichen Authentifizierung eines Benutzers auf den Seiten von Azure AD zurück an Ihre Anwendung geleitet werden kann.

      Es ist zwingend erforderlich, diese Adresse im Vorfeld anzugeben. Wenn Azure AD Authentifizierungsflüsse an beliebige Adressen umleiten würde, könnten Angreifer auf einfache Weise Authentifizierungsflüsse missbrauchen und Token stehlen. Durch die Registrierung der URL Ihrer Anwendung im Vorfeld wird garantiert, dass die Authentifizierungstoken, die für Ihre App bestimmt sind, auch nur an Ihre App gesendet werden.

    • APP-ID-URI: Dieser Parameter stellt den identifier Ihrer Webanwendung dar. Azure AD verwendet diesen Wert zum Anmeldezeitpunkt, um zu bestimmen, dass die Authentifizierungsanforderung einem Benutzer den Zugriff auf diese bestimmte Anwendung – unter allen registrierten Anwendungen – ermöglichen soll, damit die richtigen Einstellungen angewendet werden können.

    noteHinweis
    Der APP-ID-URI muss innerhalb des Verzeichnismandanten eindeutig sein. Ein gut geeigneter Standardwert ist der Wert APP-URL selbst. Mit dieser Strategie ist die Eindeutigkeitseinschränkung jedoch nicht immer einfach zu erfüllen. Bei der Entwicklung der App in lokalen Hostumgebungen (z. B. IIS Express und dem Azure-Fabric-Emulator) werden tendenziell eingeschränkte Adressbereiche generiert, die von mehreren Entwicklern oder sogar mehreren Projekten desselben Entwicklers wiederverwendet werden. Eine mögliche Strategie besteht im Anfügen von Elementen an den Wert APP-URI als Unterscheidungskennzeichen.

    Beachten Sie außerdem Folgendes: Der APP-ID-URI ist ein URI und muss als solcher keinem adressierbaren Netzwerkendpunkt entsprechen. Dies bedeutet, dass Sie eine Angabe auswählen können, die nichts mit der APP-URL zu tun hat. Obwohl Sie in diesem Lernprogramm mit einer ganz neuen Anwendung arbeiten, registrieren Sie gelegentlich vorhandene Anwendungen, die ggf. bereits einen eigenen APP-ID-URI besitzen (im hier verwendeten Anmeldeprotokoll WS-Verbund wird der APP-ID-URI als realm bezeichnet), und in diesem Fall möchten Sie ihn wahrscheinlich hier verwenden. Im Thema Entwickeln mehrinstanzenfähiger Webanwendungen mit Azure AD werden einige zusätzliche Einschränkungen beschrieben, die durch Mehrinstanzenfähigkeit entstehen.

  4. Nachdem Sie die APP-URL und den APP-ID-URI eingegeben haben, können Sie auf die Schaltfläche in der unteren rechten Ecke klicken.

    Schnellstart Dies schließt den Registrierungsvorgang ab. Für Ihre App ist nun ein eigener Eintrag im Verzeichnismandanten vorhanden, und Azure AD ist bereit, die Webauthentifizierung dafür auszuführen.

    Der Bildschirm, der Sie über die erfolgreiche Registrierung informiert, stellt die Informationen zur Verfügung, die Sie für Ihre Webanwendung konfigurieren müssen, damit Azure AD für die Anmeldung verwendet wird. Insbesondere Insbesondere der Abschnitt Einmaliges Anmelden mit Azure AD aktivieren enthält einige Einstellungen, die Sie in Visual Studio einfügen müssen.

    Lassen Sie Ihren Browser auf dieser Seite geöffnet, und wechseln Sie für die nächste Aufgabe in dieser exemplarischen Vorgehensweise zurück zu Visual Studio.

Da Azure AD nun bereit ist, Authentifizierungstoken für Ihre Anwendung auszustellen, besteht der letzte Schritt zum Aktivieren der Webanmeldung im Konfigurieren der Anwendung für die Verarbeitung von Anforderungen mit dem richtigen Authentifizierungsprotokoll. Durch diese Protokollerzwingung wird es der Anwendung ermöglicht, Azure AD – und insbesondere Ihren Verzeichnismandanten – aufzurufen, um die Benutzerauthentifizierung am Anfang der Arbeitssitzung eines Benutzers mit der App zu übernehmen.

Es ist wichtig, einige der Hintergrundinformationen zu Authentifizierungsmechanismen zu verstehen, wenn Sie Webanmeldungsprotokolle verwenden. Weitere Details finden Sie im Abschnitt mit den erweiterten Informationen.

Die Projektvorlage, die ausgewählt wurde, ist die MVC 4-Intranetanwendung. Diese Vorlage verwendet normalerweise integrierte Windows-Authentifizierung, um sicherzustellen, dass der Benutzer der App authentifiziert ist. Dieser Mechanismus greift auf Netzwerkebene: Er wird auf alle im Intranet veröffentlichten Dienste angewendet, ohne dass der Anwendung selbst Authentifizierungsprogrammlogik hinzugefügt werden muss.

Wenn Sie eine Anwendung außerhalb Ihres Intranets bereitstellen (wie es bei Cloud-Apps der Fall ist), können Sie sich nicht mehr auf Authentifizierung auf Netzwerkebene verlassen. Die am häufigsten verwendete Strategie für die Ausführung der Authentifizierung in diesen Fällen beinhaltet das Hinzufügen von Middleware vor Ihrer Anwendung, die die erforderliche Authentifizierungsprüfung auf höherer Ebene ausführt. Diese zusätzliche Ebene kann nicht authentifizierte Anforderungen abfangen, Authentifizierungsprotokolle erzwingen, Benutzer für die Authentifizierung außerhalb der Anwendung weiterleiten, Informationen zum authentifizierten Benutzer an die App zurückgeben, Sitzungen verwalten und im Allgemeinen alle Aufgaben übernehmen, die für die Zugriffssteuerung erforderlich sind.

Diese Strategie wird in der Branche konsistent auf alle Plattformen, Entwicklungsstacks und Anmeldeprotokolle angewendet. Die übertragenen Daten und das Programmiermodell sind unterschiedlich, das allgemeine Muster bleibt jedoch größtenteils gleich.

In dieser exemplarischen Vorgehensweise verbinden Sie die Anwendung über das WS-Verbund-Protokoll mit Azure AD. Dies ist nur eines der Verfahren zum Implementieren von Web-SSO. SAML-P ist die andere häufig gewählte Methode.

.NET Framework 4.5 bietet systemeigene Unterstützung für WS-Verbund. Alle Klassen, die zum Erzwingen des Protokollflusses, zum Ausführen der Authentifizierung und zum Verarbeiten von Sitzungen im Kontext von ASP.NET-Anwendungen erforderlich sind, sind bereits integriert.

In aller Kürze: .NET 4.5 bietet eine Sammlung von HttpModules, die in der HTTP-Pipeline der Anwendung instanziiert werden. Diese Module verweisen auf bekannte Konfigurationsabschnitte, die die Protokollkoordinaten der Anwendung und der Authentifizierungsstelle (in diesem Fall Ihr Azure AD-Mandant) enthalten. Wenn Anforderungen eingehen, untersuchen die Module diese und erzwingen das jeweilige Authentifizierungsprotokoll. Wenn eine nicht authentifizierte Anforderung empfangen wird, lesen die Module z. B. die Koordinaten des Azure AD-Mandanten aus der Konfigurationsdatei, verwenden diese zum Generieren einer WS-Verbund-Anmeldenachricht und verwenden sie dann zum automatischen Umleiten des Benutzers für die Authentifizierung bei Azure AD.

noteHinweis
Die Untermenge der Klassen in .NET Framework 4.5, die für Aufgaben reserviert sind, die anspruchsbasierte Identität betreffen, ist unter dem Namen Windows Identity Foundation (WIF) bekannt. Anwendungen für frühere Versionen des Frameworks (3.5 und 4.0) können die in dieser exemplarischen Vorgehensweise beschriebenen Schritte ebenfalls implementieren, indem eine frühere Version von WIF genutzt wird, die out-of-band als eigenständige Bibliothek veröffentlicht wurde (Download hier). Beachten Sie jedoch, das die schrittweisen Anleitungen voneinander abweichen, da die beiden Versionen nicht vollständig kompatibel sind (die Klassen befinden sich in verschiedenen Namespaces), und dass Tooling für verschiedene Visual Studio-Versionen (2008 und 2010, Download hier) verwendet werden muss.

Visual Studio 2012 stellt Point-and-Click-Tools zur Verfügung, die Sie beim Konfigurieren von Anwendungen für die Verwendung von WS-Verbund für Webanmeldung verwenden können. Sie können die Benutzeroberfläche des Tools zum Bereitstellen einiger Schlüsselinformationen zur Autorisierungsstelle verwenden, der für die Authentifizierung vertraut werden soll, und das Tool gibt dann die entsprechenden Konfigurationseinträge aus. In dieser exemplarischen Vorgehensweise müssen Sie nur sehr wenig Code schreiben, da das Tooling dem meisten Code automatisch für Sie generiert.

  1. Da Sie nun wissen, wie Webanmeldung implementiert wird, verwenden Sie das Identitäts- und Zugriffstool zum Konfigurieren Ihrer Anwendung. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt Ihrer Anwendung, und klicken Sie dann im Kontextmenü auf Identität und Zugriff.

    Identität und Zugriff Visual Studio zeigt das unten abgebildete Dialogfeld an.

    Identität und Zugriffsanbieter Sie führen sämtliche Aufgaben auf der Registerkarte Anbieter aus, die hier gezeigt wird. In dieser exemplarischen Vorgehensweise ignorieren Sie alle Optionen, die für die aktuelle Aufgabe nicht erforderlich sind.

  2. Das Tool listet verschiedene Typen von Autorisierungsstellen auf, die Sie zum Auslagern der Authentifizierung verwenden können. In diesem besonderen Fall möchten Sie einen Geschäftsidentitätsanbieter verwenden. Klicken Sie auf den entsprechenden Eintrag (zweite Option von oben).

    Konfigurieren von Identität und Zugriff Wenn Sie die Option auswählen, werden die entsprechenden Elemente der Benutzeroberfläche im Bereich darunter angezeigt. Die Informationen, die von diesen Steuerelementen angefordert werden, stimmen genau mit den Einträgen überein, die am Ende des Anwendungsregistrierungsvorgangs angezeigt werden, der weiter oben beschrieben wurde. Folgendes müssen Sie von unten nach oben eingeben:

    • Geben Sie den APP-ID-URI (Bereich) Ihrer Anwendung ein. Dies ist der Bezeichner Ihrer Anwendung, den Sie während der Registrierung definiert haben. Wechseln Sie zurück in das Browserfenster, das das Verwaltungsportal anzeigt, kopieren Sie den entsprechenden Wert aus dem Feld Code mit Ihrem App-ID-URI aktualisieren, und fügen Sie ihn dann hier ein.

    • Geben Sie den Pfad zum STS-Metadatendokument ein: Das "STS-Metadatendokument" ist eine Datei, die eine maschinenlesbare Beschreibung der Autorisierungsstelle enthält, mit der Sie eine Verbindung herstellen möchten. Das Tool ruft Informationen aus dieser Datei ab, um den Wert von Parametern zu ermitteln, die für den Anmeldedatenfluss wesentlich sind (weitere Details finden Sie weiter unten). Jeder Azure AD-Mandant macht ein solches Dokument verfügbar. Der Speicherort wird am Ende des Registrierungsvorgangs bereitgestellt. Wechseln Sie zum Verwaltungsportal, kopieren Sie den entsprechenden Wert von der Anwendungsregistrierungsseite, wechseln Sie zurück zum Tool, und fügen Sie den Pfad dann in dieses Feld ein.

      noteHinweis
      Wenn Sie den Pfad zum Metadatendokument in das Textfeld eingeben, zeigt das Tool eine Warnung an, dass ein Zertifikat ungültig ist. Dies ist der Fall, weil das Metadatendokument mit einem selbstsignierenden Zertifikat signiert ist, und sollte kein Problem darstellen.

    Klicken Sie auf OK. Das Tool liest die Koordinaten der Autorisierungsstelle (die Adresse der für die Anmeldung zu verwendenden Endpunkte, das für die Überprüfung der Signatur von Authentifizierungstoken zu verwendende X.509-Zertifikat, das Format und die Version der ausgestellten Authentifizierungstoken usw.) aus dem angegebenen Metadatendokument und verwendet diese Informationen dann, um die Einträge zu generieren und der Datei web.config hinzuzufügen, die zum Verbinden der Anwendung mit Azure AD erforderlich sind.

In der folgenden Liste werden die Haupteinträge beschrieben, die das Tool der Datei web.config hinzufügt. Eine ausführlichere Beschreibung finden Sie im erweiterten Abschnitt des Dokuments.

  • <section>-Einträge für "system.identityModel" und "system.identityModel.services": Diese sind erforderlich, damit die Konfigurationsdatei die identitätsspezifischen Konfigurationseinstellungen versteht.

  • <authorization>-Einstellungen in <system.web>: Das Tool ändert automatisch die vorhandenen ASP.NET-Authentifizierungseinstellungen, damit jede Anforderung an die App authentifiziert werden muss. Dies erzwingt ein Verhalten, das als "Blanketweiterleitung" bezeichnet wird. Dabei wird jede nicht authentifizierte Anforderung an die Authentifizierungsautorisierungsstelle weitergeleitet (anstatt Teile der App nicht authentifizierten Benutzern zur Verfügung zu stellen). Ein solches Verhalten ist in Branchenanwendungen (LoB-Anwendungen) das Standardverhalten, weil die Authentifizierung häufig still erfolgt, wenn der Benutzer bereits an der Autorisierungsstelle angemeldet ist. Wenn der Entwickler dieses Verhalten ändern möchte, um Authentifizierungsanforderungen fallweise bereitzustellen, kann er einfach die <authorization>-Einstellungen entsprechend ändern.

  • "WSFederationAuthenticationModule" (FAM) und "SessionAuthenticationModule" (SAM) in <system.webServer/modules>: Diese Einträge fügen die HttpModules in der HTTP-Pipeline der Anwendung hinzu, die die Verwendung von WS-Verbund für die Authentifizierung erzwingen. FAM ist das Modul, das für die Protokollerzwingung verantwortlich ist. Die Hauptdatenflüsse, für die das Modul verantwortlich ist, sind Anmeldeanforderungen, Tokenüberprüfung und Abmeldeverwaltung. SAM verarbeitet Sitzungen. Das Modul generiert insbesondere Sitzungscookies, überprüft diese und erzwingt ihr Vorhandensein bei jeder Anforderung, verwaltet die Länge der Sitzung usw. Das Verhalten wird vom unten beschriebenen Konfigurationselement gesteuert.

  • Abschnitt <system.identitymodel/identityConfiguration>: Dieses Element bestimmt das Verhalten der App während der Authentifizierungsphase. Beispiel: Im Unterelement ValidatingIssuerNameRegistry wird die Liste der Autorisierungsstellen gespeichert, denen hinsichtlich der Bereitstellung von Authentifizierungsdiensten vertraut wird, indem ihre Namen und die zum Signieren verwendeten Zertifikate aufgezeichnet werden.

  • Abschnitt <system.identitymodel.services/federationConfiguration>: Dieser Abschnitt stellt die Koordinaten zur Verfügung, die zum Steuern von WS-Verbund-Datenflüssen erforderlich sind: die Adresse der Autorisierungsstelle, die für Anmeldeanforderungen verwendet wird, den Bezeichner der App selbst, der in Anforderungen eingeschlossen werden soll usw.

Die automatisch generierte Konfigurationsdatei ist alles, was Sie benötigen, um Azure AD für die Webanmeldung nutzen zu können. Sie müssen keinen authentifizierungsspezifischen Code in der Anwendung selbst schreiben. Wenn Sie auf Informationen der Benutzeridentität zugreifen möchten, geschieht dies ganz einfach durch Abfragen der Ansprüche im aktuellen Prinzipal. Angenommen, Sie möchten z. B. auf den Vor- und Nachnamen Ihres aktuellen Benutzers zugreifen. Dies kann mithilfe des folgenden Codes geschehen, ohne dass Sie wissen müssen, wie die Authentifizierung stattgefunden hat:

//...
using System.Security.Claims;

namespace ExpenseReport.Controllers
{
  public class HomeController : Controller
  {
    public ActionResult Index()
    {            
      ClaimsPrincipal cp = ClaimsPrincipal.Current;
      string fullname = 
             string.Format("{0} {1}", cp.FindFirst(ClaimTypes.GivenName).Value,
             cp.FindFirst(ClaimTypes.Surname).Value);
      ViewBag.Message = string.Format("Dear {0}, welcome to the Expense Note App", 
                        fullname);
      return View();
     }
//...

Ab .NET 4.5 wird jede Identität in .NET durch einen ClaimsPrincipal dargestellt. In diesem Fall wurde der aktuelle ClaimsPrincipal während der Überprüfung eines Authentifizierungstokens erstellt, das durch Azure AD generiert und vom Benutzer zum Anmeldezeitpunkt bereitgestellt wurde.

Jeder ClaimsPrincipal enthält eine Auflistung von Ansprüchen – Attribute, die den aktuellen Benutzer als durch die Autorisierungsstelle bestätigt beschreiben, die ihn authentifiziert hat. In dieser exemplarischen Vorgehensweise sind die Ansprüche im Prinzipal diejenigen, die im Token durch Azure Active Directory ausgestellt wurden. Eine vollständige Liste der verfügbaren Ansprüche finden Sie in der Onlinedokumentation.

Azure AD stellt eine feste Sammlung von Ansprüchen für die authentifizierten Benutzer aus. Im Folgenden finden Sie eine Kurzübersicht aller Ansprüche, die Sie von Azure AD erwarten können. Eine vollständige Beschreibung ist in der Dokumentation enthalten.

 

Typ Wert im Beispiel Beschreibung

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

S40rgb3XjhFTv6EQTETkEzcgVmToHKRkZUIsJlmLdVc

Eindeutiger, unveränderlicher, nicht wiederverwendbarer, geleiteter Bezeichner des authentifizierten Benutzers für die aktuelle Anwendung.

http://schemas.microsoft.com/identity/claims/objectidentifier

528b2ac2-aa9c-45e1-88d4-959b53bc7dd0

Der Bezeichner für den Benutzer im Verzeichnis. Nützlich bei Verzeichnisabfragen zum Benutzer.

http://schemas.microsoft.com/identity/claims/tenantid

cab1a5ac-f33b-45fa-9bf5-f37db0fed422

Der Bezeichner des Verzeichnismandanten.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

John

Der Vorname des Benutzers.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

user@test04-realm2

Der UPN des Benutzers.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Doe

Der Nachname des Benutzers.

http://schemas.microsoft.org/identity/claims/identityprovider

https://sts.windows.net/cab1a5ac-f33b-45fa-9bf5-f37db0fed422/

Der Bezeichner der Autorisierungsstelle, die den Benutzer authentifiziert hat, wie im Webanmeldungsprotokoll angegeben (in diesem Fall WS_Verbund).

An diesem Punkt verfügt Ihre Anwendung über alle Komponenten, um die Webanmeldung bei Azure AD zu veranschaulichen. Sie ist jedoch noch nicht vollständig. Sie möchten noch mindestens zwei wichtige Funktionen hinzufügen: Unterstützung für Abmeldung und automatische Aktualisierung der Protokollkoordinaten der Autorisierungsstelle.

In den nächsten beiden Abschnitten wird ausführlich beschrieben, wie diese beiden Funktionen hinzugefügt werden. Es wird empfohlen, diese Abschnitte ebenfalls durchzuarbeiten, bevor Sie sich mit dem Abschnitt "Ausführen Ihrer App" beschäftigen.

Die zurzeit verwendeten Webanmeldungsprotokolle enthalten häufig Möglichkeiten zum Ausführen verteilter Abmeldevorgänge. Dabei handelt es sich um Datenflüsse, in denen nicht nur die aktuelle Anwendung die aktuelle Sitzung des Benutzers abbricht, sondern auch der Autorisierungsstelle signalisiert, dass ein Abmeldebefehl an alle anderen Sitzungen der Anwendung verteilt werden soll, die ggf. von der gleichen Autorisierungsstelle eingerichtet wurden. WS-Verbund stellt dabei keine Ausnahme dar. Das Protokoll bietet einen vollständigen Abmeldedatenfluss, der im WIF-Objektmodell vollständig implementiert ist. In diesem Unterabschnitt wird beschrieben, wie der Beispielanwendung verteilte Abmeldefunktionen hinzugefügt werden. Im Wesentlichen müssen die richtigen Funktionen in die Benutzeroberfläche eingebunden werden, um den Abmeldefluss auszulösen, und es muss eine geeignete Abmeldenachricht generiert werden, die an den Azure AD-Mandanten gesendet wird.

  1. Beginnen Sie, indem Sie der Anwendung einen SignOut-Controller hinzufügen. Suchen Sie zu diesem Zweck im Projektmappen-Explorer unter dem Projekt einfach nach dem Ordner Controller, klicken Sie mit der rechten Maustaste auf den Ordner, wählen Sie Hinzufügen aus, und klicken Sie dann auf Controller. Weisen Sie den Namen SignOutController zu, wählen Sie Leerer MVC-Controller (dies ist normalerweise die Standardeinstellung) aus, und klicken Sie dann auf Hinzufügen.

  2. Sie müssen Klassen aus einigen neuen Assemblys verwenden, daher müssen Sie Verweise auf diese Klassen hinzufügen. Klicken Sie zu diesem Zweck im Projektmappen-Explorer mit der rechten Maustaste auf den Knoten Verweise, wählen Sie Verweis hinzufügen aus, geben Sie system.identitymodel.services in in das Feld Assemblys suchen ein, und wählen Sie dann die entsprechende Assembly aus der Hauptliste aus. Klicken Sie auf OK.

  3. Verwenden Sie nun erneut die soeben erstellte Datei SignOutController.cs. Fügen Sie den using-Direktiven die folgenden Einträge hinzu:

    using System.IdentityModel.Services;
    using System.IdentityModel.Services.Configuration;
    
    Ändern Sie nun die Implementierung der Klasse SignOutController wie folgt:

    public ActionResult Index()
    {
        return View("SignOut");
    }
    
    public void SignOut()
    {
         WsFederationConfiguration fc = 
                FederatedAuthentication.FederationConfiguration.WsFederationConfiguration;
    
         string request = System.Web.HttpContext.Current.Request.Url.ToString();
         string wreply = request.Substring(0, request.Length - 7);
    
         SignOutRequestMessage soMessage = 
                         new SignOutRequestMessage(new Uri(fc.Issuer), wreply);
         soMessage.SetParameter("wtrealm", fc.Realm);
    
         FederatedAuthentication.SessionAuthenticationModule.SignOut();
         Response.Redirect(soMessage.WriteQueryString());
    } 
    
    
    Im Folgenden finden Sie eine kurze Erläuterung, was der Code bewirkt.

    • Die erste Methode Index() verarbeitet Anforderungen der Form https://localhost:44341/SignOut. Dies ist die Adresse einer Ansicht, die Sie in der exemplarischen Vorgehensweise wenige Schritte später hinzufügen. Der Zweck besteht darin, eine erfolgreiche Abmeldung zu signalisieren. Sie verwenden diese Adresse in der nächsten Methode.

    • Die Methode SignOut() verarbeitet Anforderungen der Form https://localhost:44341/SignOut/SignOut und enthält die Hauptprogrammlogik für die Abmeldung.

    • Die erste Zeile ruft das Objekt ab, das WIF zum Nachverfolgen der WS-Verbund-Einstellungen in der Datei web.config verwendet. Sie benötigen dieses Objekt, um eine Abmeldenachricht zu erstellen, die an die aktuelle Anwendung angepasst ist.

      noteHinweis
      Das Verweisen auf Konfigurationswerte (im Gegensatz zur Hartcodierung von Werten oder zum Abrufen aus benutzerdefinierten Repositorys) ist normalerweise empfehlenswert, weil der Code auf diese Weise adaptiv und an die restlichen Protokolleinstellungen angeglichen wird. Die Programmlogik bleibt funktionsfähig – unabhängig davon, wie viele Einstellungen vor und nach der Bereitstellung in der Konfigurationsdatei geändert werden.

    • Die zweite und die dritte Zeile erstellen die Rücksendeadresse, die die Autorisierungsstelle am Ende des Abmeldedatenflusses verwenden soll. Diese Adresse soll auf die zuvor erwähnte Ansicht verweisen. Der Code ruft also die URL der aktuellen Anforderung ab und entfernt die nachgestellte Angabe "SignOut". Durch das Ableiten der Adresse aus der Anforderung wird garantiert, dass sie ordnungsgemäß für den Client aufgelöst wird. Würde die Adresse aus der Hostingebene abgerufen, könnte dies ggf. zu internen Portproblemen beim Verwenden des Lastenausgleichsmoduls führen.

    • Die vierte Zeile verwendet WIF zum Erstellen einer WS-Verbund-Abmeldenachricht. Dabei werden die URL der Autorisierungsstelle und die Rücksendeadresse übergeben, die eine Zeile zuvor definiert wurden. Sie könnten die Nachricht auf einfache Weise auch direkt im Übertragungsformat erstellen. Wenn Sie das WIF-Objektmodell verwenden, schreiben Sie jedoch präziseren Code und können den größten Teil der Syntaxdetails ignorieren. Wenn es Sie interessiert, wie eine Abmeldenachricht aussieht, sollten Sie eine HTTP-Ablaufverfolgung erfassen, wenn Sie die App in einem späteren Abschnitt ausführen, oder lesen Sie die hier aufgeführte Spezifikation.

    • Die vierte Zeile fügt der Nachricht den Bezeichner der aktuellen App hinzu, der im Attribut realm des <wsFederation>-Konfigurationselements aufgezeichnet wurde.

    • Die fünfte Zeile verwendet SAM (weiter oben in den Erläuterungen zur automatisch generierten Konfiguration beschrieben), um die lokale Sitzung zu bereinigen. Dies beinhaltet das Löschen des Sitzungscookies, das zum Anmeldezeitpunkt generiert wurde, sowie die Bereinigung aller lokalen Ressourcen, die ggf. erforderlich ist.

      noteHinweis
      Die hier gezeigte Beispielanwendung führt nur wenige Aufgaben aus, Ihre echten Anwendungen weisen jedoch ggf. Ressourcen während der Sitzung eines Benutzers zu. Wenn dies der Fall ist, können Sie die SAM-Ereignisse SigningOut und SignedOut nutzen, indem Sie entsprechende Ereignishandler in der Datei Global.asax hinzufügen, um die Ressourcen zu bereinigen, die beim Schließen einer Sitzung entfernt werden sollten.

Die hier verwendete Ansicht ist sehr einfach: Wie bereits erwähnt, soll sie nur einen sinnvollen Rückkehrpunkt für den Abmeldedatenfluss bereitstellen.

  1. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf den Knoten Ansichten, und fügen Sie dann einen Ordner SignOut hinzu.

  2. Fügen Sie in diesem Ordner eine Ansicht hinzu, indem Sie mit der rechten Maustaste auf den Ordner klicken und dann auf Hinzufügen und Ansicht klicken. Nennen Sie die neue Ansicht ebenfalls SignOut. Fügen Sie Platzhalterdarstellungscode in die Ansichtsdatei (SignOut.cshtml) ein, um anzugeben, dass die Abmeldung stattgefunden hat. Beispiel:

    @{
        ViewBag.Title = "SignOut";
    }
    
    <h2>You have successfully signed out</h2>
    
  3. Sie erinnern sich sicher an den früheren Abschnitt, in die die Anwendung konfiguriert wurde, um die Authentifizierung über Blanketweiterleitungen auszuführen. Dies bedeutet Folgendes: Wenn Sie versuchen, nach einer erfolgreichen Abmeldung erneut auf diese Ansicht zuzugreifen (wie Sie es sollten), werden Sie sofort zu Azure AD umgeleitet, um sich erneut anzumelden. Damit dieses Verhalten verhindert wird, können Sie das Element <location> in der Datei web.config verwenden, um eine Ausnahme für die Authentifizierungsrichtlinie zu erstellen.

    Suchen Sie nach dem ersten Vorkommen des Elements <system.web>, und fügen Sie unmittelbar darüber den folgenden Codeausschnitt ein:

      <location path="SignOut">
        <system.web>
          <authorization>
            <allow users="*" />
          </authorization>
        </system.web>
      </location>
    
    
    Auf diese Weise wird ASP.NET informiert, dass auf den SignOut-Pfad durch beliebige Benutzer (auch durch nicht authentifizierte Benutzer) zugegriffen werden kann. Durch diese Konfiguration wird es möglich, dass diese Ansicht in Ihrem Browser auch nach einer erfolgreichen Abmeldung angezeigt wird.

  1. Die App besitzt jetzt eine Abmeldefunktion. Sie müssen diese Funktion jetzt nur noch in der Benutzeroberfläche sichtbar machen. Zu diesem Zweck kann ein sehr einfaches Verfahren verwendet werden: Öffnen Sie _layout.cshtml aus dem Pfad Views\Shared im Projektmappen-Explorer. Suchen Sie nach der Zeichenfolge "Hello", um den Code zu ermitteln, der das Rendern der Anmeldeinformationen oben im typischen MVC 4-Layout übernimmt, und ändern Sie dann den Anmeldeabschnitt wie folgt:

    <section id="login">
      @if (Request.IsAuthenticated)
      {  
        <text> Hello, <span class="username">@User.Identity.Name</span>! 
      @Html.ActionLink("Signout","SignOut", "SignOut")</text>
      }
      else {
        <text>  You are not authenticated </text>
      }
    </section> 
    
    

Nun wird rechts neben dem Begrüßungstext für den angemeldeten Benutzer ein Abmeldebefehl hinzugefügt. Somit kann eine Abmeldeaktion von jeder Ansicht aus ausgelöst werden.

Durch das Identitäts- und Zugriffstool wurde die Anwendung so konfiguriert, dass sie Token von Ihrem ausgewählten Azure AD-Mandanten akzeptiert. Zu diesem Zweck wurden die erforderlichen Protokollkoordinaten zum Herstellen einer Verbindung mit den gewünschten Azure AD-Endpunkten in der Datei web.config zwischengespeichert. Außerdem wurden Schlüsselinformationen gespeichert, die bei der Authentifizierung verwendet wurden, um zu überprüfen, ob das eingehende Token tatsächlich von Ihrem Azure AD-Mandanten stammte: der Ausstellername, der Ihren Mandanten darstellt, und der öffentliche Schlüssel (in Form eines X.509-Zertifikats), der zum Überprüfen der Signatur des Tokens verwendet werden soll.

Die regelmäßige Erneuerung kryptografischer Schlüssel ist eine bewährte Sicherheitsmethode. Dies gilt auch für Azure AD-Signaturschlüssel: In festen Zeitintervallen werden die alten Schlüssel zurückgezogen, und neue Schlüssel nehmen ihren Platz in der Signaturlogik des Ausstellers sowie im Metadatendokument Ihres Mandanten ein. In Notfällen können Schlüssel auch außerhalb dieser Zyklen ggf. ohne Vorwarnung erneuert werden.

Bei jedem Rollover des Signaturschlüssels müssen Ihre Anwendungseinstellungen entsprechend geändert werden. Gemäß dem bis jetzt in dieser exemplarischen Vorgehensweise gezeigten Ansatz würde dies bedeuten, das Tool erneut auszuführen, um das neue Metadatendokument zu lesen und die Einträge in der Datei web.config zu aktualisieren.

Damit die Ausfallzeiten verringert werden, empfiehlt es sich, selbstheilende Programmlogik direkt in der Anwendung hinzuzufügen, damit das Metadatendokument programmgesteuert verarbeitet und eine Reaktion auf Schlüsselrollover erfolgen kann, ohne dass ein Operator eingreifen muss. Unten finden Sie ein Beispiel für die Implementierung einer solchen Funktion.

  1. Verwenden Sie den Projektmappen-Explorer wie an früherer Stelle in diesem Dokument beschrieben, um einen Verweis auf die Assembly System.IdentityModel hinzuzufügen.

  2. Fügen Sie der Datei Global.asax. die folgenden using-Direktiven hinzu:

    using System.Configuration;
    using System.IdentityModel.Tokens;
    
    
  3. Fügen Sie der Datei Global.asax dann die folgende Methode hinzu:

    //...
    protected void RefreshValidationSettings()
    {
        string configPath = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Web.config";
        string metadataAddress = 
                      ConfigurationManager.AppSettings["ida:FederationMetadataLocation"];
        ValidatingIssuerNameRegistry.WriteToConfig(metadataAddress, configPath);
    }
    
    
    Die Programmlogik ist hier sehr einfach. ValidatingIssuerNameRegistry ist die Klasse, die vom Identitäts- und Zugriffstool zum Aufzeichnen von Informationen zu den vertrauenswürdigen Autorisierungsstellen und den Schlüsseln, die zum Überprüfen der von ihnen ausgestellten Token verwendet werden sollen, verwendet wird. WriteToConfig ist eine statische Methode, die die Ausstellereinstellungen aus einem Metadatendokument liest (in diesem Fall erfolgt der Abruf aus der Konfigurationsdatei, in der sie bei der ersten Ausführung des Tools durch die zweite Zeile der Methode gespeichert wurden) und zum Erstellen oder Aktualisieren des entsprechenden Konfigurationsabschnitts der Datei im angegebenen Pfad (aus der aktuellen AppDomain in der ersten Zeile der Methode erstellt) verwendet.

  4. Rufen Sie die Methode zum Einfügen von RefreshValidationSettings() in den Lebenszyklus der Anwendung aus Application_Start() wie unten gezeigt auf.

    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
    
        WebApiConfig.Register(GlobalConfiguration.Configuration);
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        RefreshValidationSettings();
    }
    
    Wenn Sie RefreshValidationSettings aus Application_Start aufrufen, wird garantiert, dass die Datei web.config zu einem sicheren Zeitpunkt geändert wird. Würde dies später im Lebenszyklus der Anwendung geschehen, riskieren Sie das Auslösen einer Aktualisierung.

ImportantWichtig
Sie müssen einige zusätzliche Vorsichtsmaßnahmen beim automatischen Aktualisieren der Überprüfungsschlüssel aus der Anwendung anwenden. Die größte Bedrohung, die Sie vermeiden müssen, ist DNS-Hijacking. Dabei verwendet ein Angreifer Schadsoftware, um Sie an ein böswilliges Metadatendokument zu verweisen. Ihre App wird dann dazu verleitet, den falschen Schlüsseln zu vertrauen.

Wenn Sie die .NET-Standardeinstellungen für die Verarbeitung von HTTP-Anforderungen nicht außer Kraft setzen, wird das oben beschriebene Szenario bereits aufgrund der Tatsache verhindert, dass Metadatendokumente an HTTPS-Endpunkten gehostet werden. Durch DNS-Hijacking können Anforderungen an einen böswilligen Endpunkt weitergeleitet werden. Ein solcher Endpunkt kann jedoch die HTTPS-Serverüberprüfung nicht bestehen: Da er nicht Besitzer der Domäne ist, auf der Metadatendokumente gehostet werden, kann der Angreifer kein ausgestelltes Zertifikat für diese abrufen. Der Client ist daher in der Lage, ein Problem mit dem Server zu erkennen, und kann die falsche Weiterleitung vermeiden.

Unter bestimmten Umständen ist es in einigen Entwicklungsszenarien erforderlich, die HTTPS-Überprüfung zu deaktivieren (normalerweise geschieht dies über die Klasse ServicePoint). Wenn Sie die in diesem Abschnitt gezeigte Programmlogik für automatische Metadatenaktualisierung verwenden, müssen Sie die HTTPS-Überprüfungseinstellungen unter allen Umständen wiederherstellen, bevor Sie Ihre Anwendung in einer Produktionsumgebung bereitstellen.

  1. Sie sind nun endlich in der Lage, die Anwendung in Aktion zu erleben. Drücken Sie F5: Es wird ein Browserfenster geöffnet und versucht, auf die URL zuzugreifen, die in den Projekteinstellungen im Abschnitt "Erstellen einer MVC-App" angegeben wurde.

    Zuerst wird ein Zertifikatfehler angezeigt. Dies ist erwartetes Verhalten. Klicken Sie auf Laden dieser Website fortsetzen (nicht empfohlen). Sie sollten diesen Fehler in einer Produktionsanwendung nicht ignorieren. Für die Zwecke dieser exemplarischen Vorgehensweise ist er jedoch akzeptabel.

    CertificateError Wenn Sie die Adressleiste beobachten, bemerken Sie, dass für einen kurzen Moment die URL der App angezeigt wird. Das FAM-Modul vor der App erkennt den Aufruf jedoch sofort als nicht authentifiziert, liest die entsprechenden Anweisungen aus der Konfigurationsdatei und löst die Anmeldeumleitung an Azure AD aus. Die URL-Adressleiste wird durch eine Adressleiste der Autorisierungsstelle ersetzt, und der Benutzer wird aufgefordert, sich über die Benutzeroberfläche von Azure AD zu authentifizieren.

    noteHinweis
    Das neue Benutzerkonto, das Sie zuvor erstellt haben, kann nicht zum Verwalten Ihres Azure-Abonnement verwendet werden, wenn Sie sich ursprünglich mit einem Microsoft-Konto beim Verwaltungsportal angemeldet haben. Wenn Sie versuchen, zurück zum Verwaltungsportal zu navigieren, nachdem Sie sich bei der Anwendung als neuer Benutzer angemeldet haben, wird eine Fehlermeldung angezeigt. Sie müssen sich stattdessen am Verwaltungsportal mithilfe des Kontos anmelden, das Sie zum Erstellen des Verzeichnismandanten verwendet haben. Wenn Sie sich ursprünglich mit einem Azure AD-Konto beim Verwaltungsportal angemeldet haben und dem neuen Benutzer, den Sie zuvor erstellt haben, die globale Administratorrolle zugewiesen wurde, kann dieser neue Benutzer Ihr Azure-Abonnement verwalten.

    Anmelden bei AAD
  2. Geben Sie die Anmeldeinformationen des Benutzers ein, den Sie im Azure-Mandanten im ersten Abschnitt der exemplarischen Vorgehensweise erstellt haben. Klicken Sie auf die Schaltfläche Anmelden.

    Wahrscheinlich erinnern Sie sich daran, dass dem Benutzer bei dessen Erstellung im Azure AD-Mandanten vom Verwaltungsportal ein temporäres Kennwort zugewiesen wurde. Sie müssen sich mithilfe dieses Kennworts authentifizieren. Da ein solches Kennwort jedoch nur temporär ist, werden Sie bei dieser ersten Anmeldung aufgefordert, ein ordnungsgemäßes Benutzerkennwort auszuwählen, bevor Sie den Authentifizierungsvorgang fortsetzen können. Sobald dies geschehen ist, wird der normale Anmeldedatenfluss für die App wiederhergestellt.

    Startseite der Anwendung Im Verlauf der erfolgreichen Authentifizierung verarbeitet WIF die Ansprüche aus dem eingehenden Authentifizierungstoken, die ihrerseits von dem einfachen Anzeigecode verwendet werden, der im Home-Controller hinzugefügt wurde. Vom jetzigen Zeitpunkt an können Sie durch die Website navigieren, ohne sich erneut authentifizieren zu müssen: Jedes Postback enthält das Sitzungscookie, das vom SAM-Modul verarbeitet wird.

  3. Wenn Sie beobachten möchten, was geschieht, wenn Sie die Sitzung beenden, klicken Sie auf den Abmeldelink in der oberen rechten Ecke. Sie bemerken die Weiterleitungen, die zuvor im Code festgelegt wurden. Schließlich gelangen Sie zu der unten abgebildeten Ansicht.

    Abmelden Wenn Sie bestätigen möchten, dass Sie tatsächlich abgemeldet sind, klicken Sie auf ein beliebiges anderes Element der Benutzeroberfläche: De Authentifizierungszyklus wird erneut eingeleitet.

In der exemplarischen Vorgehensweise dieses Dokuments wurden die wesentlichen Schritte erläutert, die Sie ausführen müssen, um Ihrer Webanwendung Webanmeldung hinzuzufügen. Dieser Abschnitt lässt die Grundlagen hinter sich und bietet vertiefende Informationen zu einigen Schlüsselthemen. Außerdem werden einige der weiteren Aufgaben behandelt, die Sie ggf. ausführen müssen, um Ihre Anwendung zu optimieren.

In diesem Abschnitt erfahren Sie, wie die Anwendungseinstellungen geändert werden, damit die Anwendung auf Azure-Websites bereitgestellt und ausgeführt werden kann. Die Anwendung bleibt in großen Teilen unverändert. Sie müssen nur Vorkehrungen für die neue Adresse Ihrer App und die Sitzungsverwaltung treffen.

Für diesen Teil des Dokuments benötigen Sie eine Azure-Website, auf der die Bereitstellung Ihrer Anwendung erfolgen kann. Wenn Ihnen bereits eine Website zur Verfügung steht, können Sie diese verwenden. Ist dies nicht der Fall, erfahren Sie in diesem Dokument, wie eine Azure-Website erstellt und veröffentlicht wird. Wenn Sie das Lernprogramm in diesem Dokument ausführen, unterbrechen Sie den Vorgang, nachdem Sie das Veröffentlichungsprofil heruntergeladen haben. Einige Dinge müssen angepasst werden, bevor die Anwendung bereitgestellt werden kann.

Anpassen der Anwendungseinstellungen im Azure-Verwaltungsportal

Wenn Sie an den Abschnitt zur Anwendungsregistrierung zurückdenken, erinnern Sie sich, dass ein Schlüsselparameter, durch den Ihre Anwendung in der Benutzeroberfläche von Azure AD definiert wird, die URL der Anwendung selbst ist. Bei den bisher beschriebenen Schritten der exemplarischen Vorgehensweise wurde von einer lokalen Installation von IIS Express als Speicherort der Anwendung ausgegangen. Eine Bereitstellung auf Azure-Websites bedeutet jedoch, dass sich die URL der Anwendung ändert und dass dies in den Einstellungen in Azure AD berücksichtigt werden muss.

  1. Navigieren Sie zurück zum Verwaltungsportal; wählen Sie die Registerkarte Active Directory auf der linken Seite aus, klicken Sie auf Ihren Verzeichnismandanten, wählen Sie die Überschrift Anwendungen aus, und klicken Sie dann auf den Eintrag, der der Anwendung entspricht, mit der Sie gearbeitet haben. Klicken Sie auf die Überschrift Konfigurieren. Sie gelangen zu einem Bildschirm, auf dem Sie die Einstellungen der Anwendung ändern können, die Sie zum Erstellungszeitpunkt eingegeben haben. Ignorieren Sie für dieses Lernprogramm die oberen Bereiche des Bildschirms, und führen Sie einen Bildlauf nach unten zum Abschnitt für einmaliges Anmelden aus.

    Einmaliges Anmelden
  2. Suchen Sie nach dem Textfeld ANTWORT-URL, und geben Sie die Adresse Ihrer Azure-Zielwebsite ein (z. B. https://aadga.windowsazure.net/). Bei erfolgreicher Authentifizierung gibt Azure AD nun Token an den Speicherort der Azure-Website zurück (und nicht mehr an den bei der Entwicklung verwendeten Speicherort, den Sie in früheren Schritten verwendet haben). Nachdem Sie den Wert aktualisiert haben, klicken Sie auf der Befehlsleiste unten im Bildschirm auf SPEICHERN.

noteHinweis
Ggf. ist Ihnen aufgefallen, dass der APP-ID-URI noch den auf dem lokalen Host basierenden Wert verwendet, den Sie in einem früheren Schritt dieses Dokuments erstellt haben.

Unter technischen Gesichtspunkten funktioniert für die hier behandelten Apps ein beliebiger Wert, solange der Bezeichner im URI-Format vorliegt und eindeutig für alle Apps im aktuellen Verzeichnismandanten ist. Aus diesem Grund beziehen sich die Hauptanweisungen nicht auf das Aktualisieren dieses Werts.

Aus Gründen der Verwaltbarkeit möchten Sie jedoch ggf. den APP-ID-URI so ändern, dass er einen Wert aufweist, der besser für Ihre Anwendung geeignet ist. Ein typisches Beispiel wäre eine Ableitung aus dem Antwort-URL-Wert.

Beachten Sie, dass umfangreichere Änderungen an der App vor der Bereitstellung anstehen, wenn Sie den APP-ID-URI-Wert ändern. Ausführliche Informationen folgen später.

Vorbereiten der Anwendung für die Ausführung auf Azure-Websites

Der größte Teil der Webanmeldungskonfiguration ist bereit für die Cloud. Sie müssen nur eine Änderung anwenden, die aufgrund von Funktionen der Azure-Websites erforderlich ist.

Der Vorgang der Webanmeldung führt zur Erstellung eines Sitzungscookies, das bei jeder Anforderung ab der Authentifizierung gesendet wird. Das Sitzungscookie wird von der WIF-Middleware erstellt und standardmäßig über DPAPI signiert und verschlüsselt (in diesem Dokument finden Sie Hintergrundinformationen), um einen Missbrauch durch den Client zu verhindern (z. B. das Ändern der Liste der Ansprüche, um eine Rechteerhöhung zu erreichen). IIS-Einstellungen auf den Azure-Websites verhindern jedoch, dass DPAPI zum Schutz von Sitzungen verwendet wird. Daher muss der Schutz des zugehörigen Cookies durch WIF geändert werden. .NET Framework 4.5 bietet ein integrierte Alternative, die den MachineKey (hier dokumentiert) nutzt und auf Azure-Websites problemlos funktioniert.

Durch das Identitäts- und Zugriffstool ist diese Änderung sehr einfach.

  1. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt, wählen Sie Identität und Zugriff aus, und klicken Sie dann auf die Registerkarte Konfiguration. Der angezeigte Bildschirm ähnelt dem folgenden Screenshot:

    Identität und Zugriff – Azure-Websites
  2. Aktivieren Sie einfach die Option Webfarmbereite Cookies aktivieren, und klicken Sie dann auf OK. Das Tool übernimmt das Hinzufügen der erforderlichen Elemente in der Datei web.config (ersetzen Sie in der Praxis die Standardklasse SessionSecurityTokenHandler durch MachineKeySessionSecurityTokenHandler), um MachineKey als Schutzmethode für Cookies zu verwenden.

    noteHinweis
    Wenn Sie im vorherigen Schritt den APP-ID-URI im Azure-Verwaltungsportal geändert haben, können Sie diese Benutzeroberfläche verwenden, um diese Änderungen einfach auf Ihr Projekt anzuwenden. Fügen Sie einfach den APP-ID-URI-Wert in die beiden Textfelder ein, und klicken Sie dann auf OK. Das Tool wendet diese Änderungen an den richtigen Stellen in der Konfigurationsdatei an.

    Optional können Sie ggf. benutzerdefinierte ASP.NET-Fehlernachrichten vorübergehend deaktivieren, indem Sie den Eintrag <customErrors mode="Off" /> im Abschnitt <system.web> der Datei web.config einfügen. Dies unterstützt Sie bei der Problembehandlung, wenn zum Zeitpunkt der Bereitstellung Probleme auftreten. Stellen Sie jedoch unbedingt sicher, Fehlernachrichten erneut zu aktivieren, bevor Sie mit der Produktion beginnen. Angreifer könnten die ausführlichen Fehlernachrichten verwenden, um Schwachstellen in Ihrer App zu erkennen. customError verhindert dies.

Dies ist alles, was zum Vorbereiten der Anwendung für die Ausführung als Azure-Website erforderlich ist. Verwenden Sie Ihre Veröffentlichungseinstellungen, um die Anwendung bereitzustellen. Öffnen Sie dann einen Browser, navigieren Sie zur Adresse azurewebsite.net Ihrer App, und verwenden Sie dann die gleiche Verfahren, die im Abschnitt zum Testen der App der exemplarischen Vorgehensweise beschrieben wurden. Da Sie die gesamte benutzerdefinierte Programmlogik so entworfen haben, dass sie speicherortunabhängig ist, können Sie die gleichen Vorgänge ausführen, die Sie lokal verwendet haben.

Das Identitäts- und Zugriffstool generiert automatisch die Konfigurationseinstellungen, die zur Integration der App in den Azure AD-Mandanten über das WS-Verbund-Protokoll erforderlich sind. Im bestmöglichen Fall bekommen Sie diese Einstellungen niemals zu Gesicht. Unter bestimmten Umständen möchten Sie jedoch ggf. das Standardverhalten ändern, oder Sie müssen ein Problem beheben. In diesen Fällen müssen Sie sich einen Weg durch die WIF-Konfigurationseinstellungen bahnen.

Die für den Webanmeldevorgang verwendeten WIF-Klassen und die -Methode sind in MSDN vollständig dokumentiert. Hier finden Sie eine mit Anmerkungen versehene Version der Datei web.config, nachdem das Identitäts- und Zugriffstool die Datei geändert hat. Der Einfachheit halber wurden auch die Änderungen berücksichtigt, die im Abschnitt zur Veröffentlichung auf Azure-Websites ausgeführt wurden.

noteHinweis
Aus Gründen der Klarheit enthält dieses Dokument den vollständigen Quellcode der Datei Web.config. Nur die für WIF relevanten Abschnitte wurden jedoch mit Anmerkungen versehen.

<?xml version="1.0" encoding="utf-8"?>
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->
<configuration>
  <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />

Keine Kommentare zur oben abgebildeten Konfigurationsdatei.

<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
    <section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

In der oben abgebildeten Konfigurationsdatei lädt dieser Bereich die Klassen, die ASP.NET benötigt, um die Konfigurationsabschnitte zu lesen und zu interpretieren, die von WIF zum Modellieren des WS-Verbund-Datenflusses und der Authentifizierungseinstellungen verwendet werden.

  </configSections>
  <appSettings>
    <add key="webpages:Version" value="2.0.0.0" />
    <add key="webpages:Enabled" value="false" />
    <add key="PreserveLoginUrl" value="true" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />

Keine Kommentare zur oben abgebildeten Konfigurationsdatei.

    <add key="ida:FederationMetadataLocation" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/federationmetadata/2007-06/federationmetadata.xml" />
    <add key="ida:Issuer" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" />
    <add key="ida:ProviderSelection" value="productionSTS" />
  </appSettings>

Für die oben abgebildete Konfigurationsdatei werden diese appSettings-Einträge vom Identitäts- und Zugriffstool aufgezeichnet, um wichtige Einstellungen nachzuverfolgen (etwa die Adresse des Metadatendokuments, das im Abschnitt zum Schlüsselrollover verwendet wurde), die nicht an anderer Stelle gespeichert werden.

  <location path="FederationMetadata">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
  <location path="SignOut">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

In der oben abgebildeten Konfigurationsdatei schaffen diese zwei <location>-Elemente zwei Bereiche in der Webanwendung, auf die ohne Authentifizierungsanforderungen zugegriffen werden kann (siehe unten). Der Abschnitt FederationMetadata wird vom Identitäts- und Zugriffstool erstellt. Das Tool erstellt ein Metadatendokument, das die Anwendung beschreibt. Dieses kann von Autorisierungsstellen zum Bereitstellen der App verwendet werden. Sie haben den Abschnitt SignOut selbst als Teil der Anweisungen zum Implementieren von Webabmeldung hinzugefügt.

  <system.web>
    <authentication mode="None" />
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" requestValidationMode="4.5" />
    <!--Commented by Identity and Access VS Package-->
    <!--<authentication mode="Windows" />-->
    <authorization>
      <deny users="?" />
    </authorization>

Für die oben abgebildete Konfigurationsdatei legt das Identitäts- und Zugriffstool standardmäßig die ASP.NET-Authentifizierungs- und Autorisierungseinstellungen so fest, dass für jeden Teil der Web-App (Ausnahmen siehe oben) Benutzer authentifiziert sein müssen, bevor Anforderungen ausgeführt werden. Diese Vorgehensweise ist im Allgemeinen für Branchenanwendungen angemessen. Entwickler möchten jedoch unter bestimmten Umständen ggf. Bereiche schaffen, auf die anonym zugegriffen werden kann. Wenn dies bei Ihnen der Fall ist, ändern Sie die Einstellungen hier entsprechend.

    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Optimization" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
    <customErrors mode="Off" />
    <machineKey decryptionKey="998D0533DD570FDCA86A945893F0B2BFC0E1F3645E148F35" validationKey="E739C2EA4B4470820308DA71D81160F22C0D9CD3C97709CB0679E55FDCC2D35B35563D56102F254FB4908644ECB53B3898948F54AAC4A5F0C44754A5A997B79A" />
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <handlers>
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>

Keine Kommentare zur oben abgebildeten Konfigurationsdatei.

    <modules>
      <remove name="FormsAuthentication" />
      <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
      <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
    </modules>
  </system.webServer>

Für die oben abgebildete Konfigurationsdatei fügen die Einträge in diesem Abschnitt die HTTPModules in die SP.NET-Pipeline ein, die das Kernprotokoll und die Sitzungsverarbeitungsfunktionen implementieren. WSFederationAuthenticationModule (FAM) setzt WS-Verbund durch, indem eingehende Token überprüft und Anmeldenachrichten gemäß den Spezifikationen des Protokolls generiert werden. SessionAuthenticationModule (SAM) erstellt und überprüft Sitzungscookies zusammen mit FAM.

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-1.3.0.0" newVersion="1.3.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
      <parameters>
        <parameter value="v11.0" />
      </parameters>
    </defaultConnectionFactory>
  </entityFramework>

Keine Kommentare zur oben abgebildeten Konfigurationsdatei.

  <system.identityModel>
    <identityConfiguration>
      <audienceUris>
        <add value="https://localhost:44342/ShiungZZZ" />
      </audienceUris>

Für die oben abgebildete Konfigurationsdatei bildet <system.identityModel> einen Wrapper für alle Einstellungen, die für WIF-Klassen spezifisch sind. Das erste untergeordnete Element (IdentityConfiguration) stellt eine protokollunabhängige Beschreibung des Verhaltens der Anwendung zur Verfügung. Die Liste AudienceUris stellt alle Werte zur Verfügung, die WIF als akzeptable Bereiche in eingehenden Token für die aktuellen Anwendungen betrachtet. Normalerweise entsprechen diese dem Bereich (oder in Azure AD-Terminologie dem APP-ID-URI) der Anwendung. Ein eingehendes Token muss deklarieren, dass sein beabsichtigter Empfänger einer der hier aufgelisteten Werte ist. Wenn dies nicht der Fall ist, geht WIF davon aus, dass es sich um ein gestohlenes Token handelt, und weist den Aufruf zurück.

           
      <issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
        <authority name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/">
          <keys>
            <add thumbprint="3A38FA984E8560F19AADC9F86FE9594BB6AD049B" />
          </keys>
          <validIssuers>
            <add name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/" />
          </validIssuers>
        </authority>
      </issuerNameRegistry>

Für die oben abgebildete Konfigurationsdatei enthält das Element ValidatingIssuerNameRegistry die Liste der akzeptablen Ausstellername-/Signaturüberprüfungs-Schlüsseltupel. In dieser exemplarischen Vorgehensweise spiegeln die Einstellungen die Ihrem Azure AD-Mandanten zugeordneten Werte wider. Dieses Element garantiert, dass kein anderer Aussteller (einschließlich anderer Azure AD-Mandanten im Besitz von anderen Unternehmen) Zugriff auf Ihre Anwendung erlangen kann.

<certificateValidation certificateValidationMode="None">
      </certificateValidation>

Für die oben abgebildete Konfigurationsdatei deaktiviert dieses Element die Zertifikatüberprüfung in der WIF-Pipeline. Diese Maßnahme ist für Azure AD erforderlich, weil ein selbstsigniertes Zertifikat verwendet wird. Da das Zertifikat selbst nicht im lokalen Zertifikatspeicher installiert wird, würde eine Ketten- oder Peerüberprüfung zu einem Fehler führen. Beachten Sie, dass dies die Sicherheit für die Azure AD-Authentifizierung nicht wirklich verringert, weil ValidatingIssuerNameRegistry garantiert, dass das richtige Zertifikat verwendet wird. Wenn Sie jedoch WIF in der gleichen App verwenden, um anderen Ausstellern zu vertrauen, sollten Sie berücksichtigen, dass diese Einstellungen auch auf diese erweitert werden.

      <securityTokenHandlers>
        <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      </securityTokenHandlers>
    </identityConfiguration>

Dieser Abschnitt erlaubt die Bearbeitung der Auflistung von Klassen, die WIF für die Verarbeitung eingehender Sicherheitstoken (die so genannten Tokenhandler) verwendet. Er kann verwendet werden, um das Verhalten einzelner Handler zu beeinflussen oder Handlertypen hinzuzufügen bzw. zu entfernen. In diesem Fall hat das Tool den Standardsitzungshandler (der auf DPAPI basiert und für Azure-Websites nicht funktioniert) entfernt und durch einen Handler ersetzt, der den MachineKey unterstützt.

  </system.identityModel>
  <system.identityModel.services>
    <federationConfiguration>
      <cookieHandler requireSsl="false" />
      <wsFederation passiveRedirectEnabled="true" issuer="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" realm="https://localhost:44342/ExpenseReport" requireHttps="false" />
    </federationConfiguration>
  </system.identityModel.services>
</configuration>

Für die oben abgebildete Konfigurationsdatei wird <system.identityModel.services> zum Speichern von für WS-Verbund spezifischen Koordinaten verwendet.

Insbesondere das Element wsFederation wird hier zum Aufzeichnen des WS-Verbund-Anmeldeendpunkts Ihres Azure AD-Mandanten verwendet. Der Bereich (APP-ID-URI) der App, der zum Anmeldezeitpunkt als Bezeichner gesendet werden soll, und andere Flags, die das lokale Verhalten von WIF beeinflussen (z. B. 401-Fehler aus der App), sollten immer eine Anmeldenachricht an die Autorisierungsstelle auslösen (passiveRedirectEnabled) oder angeben, ob Transaktionen für unzulässiges HTTP zulässig sind.

Dieses Element kann zum Angeben zahlreicher weiterer Protokollparameter verwendet werden. Dies sind nur die absoluten Mindestangaben, damit der Anmeldedatenfluss funktioniert.

Dieses Dokument konzentriert sich auf eine recht eng definierte Aufgabe: das Verbinden einer .NET-Anwendung mit Azure AD zum Ausführen der Webanmeldung über WS-Verbund. Es sind zahlreiche weitere Szenarien denkbar, für die Sie Lösungen mithilfe einer Vielzahl offener Protokolle schaffen können. Dabei können beliebige Programmierstacks auf allen modernen Plattformen nutzen oder direkt auf Protokollebene im Netzwerk arbeiten.

Im Abschnitt zum Bereitstellen der App für Azure haben Sie gesehen, dass das Verwaltungsportal Ihnen die Möglichkeit bietet, zahlreiche weitere Aspekte der Registrierungseinstellungen Ihrer Anwendung zu ändern. Sie lernen die meisten dieser zusätzlichen Steuerelemente in der nächsten exemplarischen Vorgehensweise aus dieser Serie kennen. Hier wird nur kurz erläutert, wie Sie die benötigten Informationen abrufen können, wenn Sie sich dafür entscheiden, mit Azure AD für die Webanmeldung oder einen der anderen unterstützten Datenflüsse auf der Protokollebene zu interagieren.

  1. Öffnen Sie das Azure-Verwaltungsportal in einem Browserfenster, und navigieren Sie dann zur Überschrift Anwendungen im Abschnitt Azure AD. Sie werden bemerken, dass die Befehlsleiste unten auf dem Bildschirm einen Eintrag enthält: Endpunkte anzeigen. Klicken Sie darauf.

    Anwendungsendpunkte Im Dialogfeld werden alle Endpunkte aufgelistet, die Sie zum programmgesteuerten Interagieren mit dem Azure AD-Mandanten verwenden können. Im Folgenden finden Sie eine kurze Erläuterung aller Einträge:

    • Verbundmetadatendokument: Der Speicherort des Metadatendokuments, im dem der Azure AD-Mandant als eine Autorisierungsstelle für die Webanmeldung beschrieben wird. Wie Sie in dieser exemplarischen Vorgehensweise im Abschnitt zum automatischen Aktualisieren von Schlüsseln gesehen haben, enthält dieses Dokument die Koordinaten von WS-Verbund-Metadaten. Außerdem enthält es die SAML-Protokollmetadaten im gleichen Paket. Weitere Informationen finden Sie unter Federation Metadata.

    • Endpunkt für WS-Verbund-Anmeldung: Der Einstiegspunkt für alle WS-Verbund-Transaktionen. Dies ist der Endpunkt, den Sie in dieser exemplarischen Vorgehensweise für die Anmelde- und Abmeldedatenflüsse verwendet haben. Weitere Informationen finden Sie unter WS-Federation Endpoint URL.

    • Endpunkt für SAML-P-Anmeldung: Der Endpunkt, der für die Implementierung von Anmeldedatenflüssen im SAML-Protokoll verwendet wird. Weitere Informationen finden Sie unter SAML Protocol Metadata and Endpoints.

    • Endpunkt für SAML-P-Abmeldung: Der Endpunkt, der für die Implementierung von Abmeldedatenflüssen im SAML-Protokoll verwendet wird. Weitere Informationen finden Sie unter SAML Protocol Metadata and Endpoints.

    • Azure AD Graph-Endpunkt: Abfragen zum Abrufen von Verzeichnisinformationen, die im aktuellen Azure AD-Mandanten gespeichert sind, müssen mithilfe der Graph-API-Syntax an diesen Endpunkt adressiert werden. Weitere Informationen finden Sie unter Verwenden der Graph-API zum Abfragen von Azure AD.

    • Endpunkt für OAuth2-Token: Dieser Endpunkt wird für den Authentifizierungsdatenfluss zwischen Servern verwendet. Er kann z. B. zum Abrufen von Zugriffstoken zum Aufrufen des Graph-Endpunkts verwendet werden. Weitere Informationen finden Sie unter OAuth 2.0 (Preview Version).

Community-Beiträge

Anzeigen:
© 2014 Microsoft