Freigeben über

  • Artikel

Dieser Artikel wurde maschinell übersetzt.

AD FS 2.0 in Identitätslösungen

Verwenden von Active Directory Federation Services 2.0 in Identitätslösungen

Zulfiqar Ahmed

Downloaden des Codebeispiels

Als Entwickler kennen Sie wahrscheinlich etwas über Windows Identity Foundation (WIF), früher “ Geneva Framework ” ein, die eine leistungsfähige API Ansprüche-Anwendungen aktivieren und zum Erstellen von benutzerdefinierten Sicherheits-token Diensten bereitstellt. Vielleicht ist Ihnen weniger vertraut Active Directory Federation Services Version 2.0 (AD FS 2.0), ursprünglich code benannten “ Geneva Server, ” die eine Föderation für Unternehmen und Single-Sign-on (SSO) Lösung darstellt. AD FS 2.0 ist eine Weiterentwicklung der Active Directory-EA 1.0 und sowohl aktiv (WS-Trust) als auch passive Szenarien (WS-Federation und SAML 2.0) unterstützt.

In diesem Artikel ich einen Überblick über AD FS 2.0 starten und geben Sie dann einen Einblick in wie Entwickler AD FS 2.0 in Ihre Identität Lösungen verwenden können. Der Fokus befindet sich auf die Funktionalität Tokenausstellung AD FS 2.0, basierend auf der Beta 2-Version. Wie Sie von Abbildung 1 sehen können, diese Tokenausstellung ist nur ein kleiner Teil des AD FS 2.0, aber es ist eines von besonderem Interesse für .NET Entwickler in Richtung Verbundidentität verschieben. Architektonisch, AD FS 2.0 baut auf WIF und Windows Communication Foundation (WCF), also wenn Sie mit diesen Technologien vertraut sind, Sie sollten fühlen rechten zu Hause mit AD FS 2.0.


Abbildung 1 Architektur von AD FS 2.0

Überblick über AD FS 2.0

Auf einer hohen Ebene ist AD FS 2.0 eine Auflistung der Dienste in Abbildung 2 dargestellt.

Den Kern von AD FS 2.0 ist ein Sicherheitstokendienst (STS), die Active Directory als Identitätsspeicher verwendet und Lightweight Directory Access Protocol (LDAP), SQL oder einem benutzerdefinierten Speicher als ein Attribut Speicher verwendet. Der STS in AD FS 2.0 können Ausstellung von Sicherheitstoken an den Aufrufer über verschiedene Protokolle, einschließlich WS-Trust, WS-Federation und Security Assertion Markup Language (SAML) 2.0. Der STS AD FS 2.0 unterstützt auch SAML 1.1 sowohl SAML 2.0 token Formate.

AD FS 2.0 ist eine saubere Trennung zwischen Wire-Protokolle und der Mechanismus für die interne Tokenausstellung entwickelt. Unterschiedliche Wire-Protokolle werden umgewandelt in ein standardisiertes Objektmodell am Eingang des Systems während intern AD FS 2.0 das gleiche Objektmodell für jedes Protokoll verwendet. Diese Trennung ermöglicht AD FS 2.0 zu einer sauberen Erweiterungsmodell, unabhängig von der die Feinheiten der verschiedenen Draht Protokolle bieten. Weitere Details zu Active Directory wird im AD FS 2.0 SDK vor dem RTM von eine EA-2.0-Erweiterbarkeit bereitgestellt.


Abbildung 2 AD FS 2.0-Komponenten

AD FS 2.0 als eine Identity-Dienstanbieter

Sie können AD FS 2.0 in mehreren allgemeinen Szenarien verwenden. Das einfachste und verbreitetste Szenario ist AD FS 2.0 als Identitätsprovider zu verwenden, so dass er es verwaltet SAML-Token für die Identitäten ausstellen kann. Hierzu muss eine neue relying Party erstellt werden. Eine relying Party in AD FS 2.0 ist eine Darstellung einer Anwendung (einer Website oder einen Webdienst) und enthält alle sicherheitsrelevante Informationen, wie z. B. Verschlüsselungszertifikat, Transformation Regeln usw. vorgibt.

Eine Relying Party einrichten

Einrichten einer neuen relying Party über AD FS 2.0 ist einfach. Sie können den Assistenten zum Hinzufügen von Relying Party zugreifen, über den Knoten Gruppenrichtlinie des Active Directory EA 2.0-Konsole. Einmal muss vorhanden, Sie oder Ihr Systemadministrator an die entsprechenden Datenquellen in der Datenquelle auswählen Seite des Assistenten, der angezeigt wird, im Abbildung 3 .


Abbildung 3 Relying Webpart Assistent zum Hinzufügen von Select Data Source-Seite von

Die ersten beiden Optionen ermöglichen es Ihnen, automatisch die relying Party, die Verwendung von Metadaten für Föderation konfigurieren. Wenn Sie Zugriff auf die relying Party Föderation Metadaten in einem Netzwerk oder in einer lokalen Datei haben, wählen Sie eine dieser beiden Optionen weil Sie weniger fehleranfällig, Sie den gesamten Prozess automatisieren und Sie Auto-Update Wenn Sie alle Details der relying Party in der Zukunft ändern. Diese Optionen sind eine wesentliche Verbesserung über AD FS 1.0, nicht bei solchen automatisierten Prozesse zur Verfügung stehen.

Die dritte Option erfordert, dass Sie die Konfigurationsdetails manuell eingeben. Verwenden Sie diese Option nur, wenn Sie keinen Zugriff auf Metadaten für die Föderation oder die Details der relying Party-Konfiguration gesteuert werden soll.

Hierbei ist es hilfreich, über die Option “ relying Party-Konfiguration manuell geben ” ausführen, damit Sie alle Schritte sehen können, die erforderlich sind, können Sie eine neue relying Party einrichten. In the next few pages of the wizard, you’ll be asked to choose a profile—choose AD FS 2.0 Profile if you want to support both browser-based and WCF-based clients or AD FS 1.x Profile if you only need AD FS 1.x interoperability and don’t support active (WCF, CardSpace) clients; configure the certificate that is used to encrypt the token so that only the relying party with the corresponding private key can decrypt and use the issued token; and configure the identifier that will be used to identify this relying party in all token issuance requests.

Wenn Sie den Assistenten zum Hinzufügen von Relying Party abgeschlossen haben, wird ein Tool Regeln-Editor geöffnet. In diesem Tool können Sie Ansprüche Ausstellungs- und Transformation Regeln konfiguriert. Abbildung 4 zeigt der Regel-Editor so konfiguriert, dass ein Token mit einen einzelnen Anspruch ausstellen, dessen Wert aus dem Hauptmenü Attribut Speicher abgerufen werden. Beachten Sie, dass das DisplayName-Attribut zugeordnet ist auf den Anspruch Given Name. AD FS 2.0 führt eine neue, textbezogene domänenspezifischen Sprache, die es Ihnen ermöglicht, einfache Regeln für das Ableiten der Prozess des Ansprüche Ausstellungs- und Transformation definieren. Jede Regel besteht aus einer Bedingung und einem Aktion und enden, wie in [c] = > ein; – mit einem Semikolon. Die Transformationslogik besteht aus einer Reihe von Regeln, die während der Tokenausstellung sequenziell ausführen. In Abbildung 4 bietet die Registerkarte einfache Ansicht eine Benutzeroberfläche für diese Regeln definieren. Die Registerkarte Ansicht Advanced können Sie direkt mit der domänenspezifischen Sprache Autor Regeln.


Abbildung 4 Regeln-Editor-Tool

In diesem Beispiel wurde veranschaulicht, wie einfach es ist eine vertrauenswürdige relying Party in AD FS 2.0 zu konfigurieren. Zu diesem Zeitpunkt Wenn AD FS 2.0 eine Tokenausstellung-Anforderung empfängt, extrahiert einen Bezeichner aus der Wire-Protokoll (z. B. das AppliesTo-Element im Fall von WS-Trust) und verwendet es zum Nachschlagen einer relying Party Ziel. Sobald eine relying Party gefunden wurde, werden die im Assistenten angegebenen Einstellungen verwendet, um die Logik Tokenausstellung abgeleitet werden.

Nun betrachten let’s wie Sie WCF verwenden können, um ein Token für diese relying Party aus AD FS 2.0 anzufordern.

Anfordern eines Tokens, die mit WCF

Es gibt zwei Optionen für die Interaktion mit AD FS 2.0 STS mithilfe von WCF:

  • Erwerben Sie explizit ein Token, die als eine WS-Trust-Client fungiert
  • Konfigurieren Sie einen WCF-Client so, dass die Infrastruktur implizit ein Token als Teil des Aufrufs erhält

In der expliziten Option bietet die WSTrustClient-Klasse eine einfache und direkte API auf Anforderung Tokens von einem STS unter Verwendung des WS-Trust-Protokolls, wie hier gezeigt.

string baseUri = "https://bccoss.com/";

WindowsWSTrustBinding binding = new WindowsWSTrustBinding(SecurityMode.Transport);

WSTrustClient tokenClient = new WSTrustClient(binding,
    new EndpointAddress(baseUri + "Trust/2005/WindowsTransport/"),
    TrustVersion.WSTrustFeb2005,
    new ClientCredentials());

//create a token issuance issuance
RequestSecurityToken rst =
    new RequestSecurityToken(WSTrustFeb2005Constants.RequestTypes.Issue);
//Relying Party’s identifier
rst.AppliesTo = new EndpointAddress("http://local.zamd.net/");
//call ADFS STS
SecurityToken token = tokenClient.Issue(rst);

Dieser Code fordert ein Token mithilfe der Windows-Authentifizierung mit Transportsicherheit. Wie Sie, im expliziten Modus sehen können erhalten Sie Zugriff auf das raw-Token, die Sie verwenden können, um Dienste zu einem späteren Zeitpunkt aufrufen. Z. B. in eine intelligente Clientanwendung Sie möglicherweise erwerben Token für verschiedene Dienste zur Anwendung beim Start oder Anmeldung Zeit, in einem token Cache zu speichern und dann während der gesamten Lebensdauer der Anwendung verwenden, um verschiedene Back-End-Dienste aufrufen. Darüber hinaus in einem Szenario, in denen viele Dienste in der gleichen logischen Sicherheitsgrenze Freigabe dasselbe Zertifikat Live, können Sie den expliziten Modus erwerben ein einzelnes Token und dann verwenden Sie diese Option, wenn diese Dienste aufrufen.

 In einer Testumgebung, in der Sie Zugriff auf die relying Party privaten Schlüssel, in der Regel haben können Sie den folgenden Code, um eine SAML-Assertion aus das zurückgegebene Token zu extrahieren.

//Private Key certificate of RP (local.zamd.net)
X509Certificate2 rpCertificate = new X509Certificate2("zamd.net.pfx", "pwd");
string assertion = Util.ExtractSAMLAssertion(token, rpCertificate);

<saml:Attribute AttributeName="givenname" AttributeNamespace="https://schemas.xmlsoap.org/ws/2005/05/identity/claims">
    <saml:AttributeValue>Zulfiqar Ahmed</saml:AttributeValue>
</saml:Attribute>

Das SAML-Token enthält nur die Ansprüche, die für diese bestimmten relying Party konfiguriert. Finden Sie unter wieder Abbildung 4 , die zeigt, wie diese relying Party Ausgabe Token konfiguriert wurde, um ein einzelnes Attribut zurück. Sie können die relying Party-Konfiguration weitere Ansprüche in der Ausgabe eingeschlossen bearbeiten, und Sie sollten sehen alle hier wiedergegeben. Sie können auch Ansprüche Richtlinie Sprache verwenden, direkt um umfangreiche Transformation und Filterlogik zu definieren.

Die WSTrustClient-API sowohl die neuen WSTrust Bindungen sind Teil der WIF, so dass für den vorangehenden Code funktioniert, WIF auf dem Client installiert werden muss. Können Sie auch die WCF-API direkt auf um ein Token, aber der Einfachheit explizit zu erwerben und Einfachheit der Verwendung WIF-Angebote kann eine Aufgabe aus der Vorgangsliste aus.

Im Code im Abbildung 5 IssuedSecurityTokenProvider entspricht der WCF WSTrustClient und wird normalerweise verwendet von WsFederationBinding beim Anfordern von Tokens in Ihrem Auftrag. Da es sich um eine öffentliche API handelt, können Sie es in Ihrem Code verwenden, die Sie Zugriff auf eine unformatierte Token benötigen sollten. Die CustomBinding entspricht dem WindowsWSTrustBinding zur Verfügung.

Abbildung 5 verwenden IssuedSecurityTokenProvider Zugriff auf einen RAW Token

sstring baseUri = "https://bccoss.com/";

//Limited edition of WSTrustClient:)
IssuedSecurityTokenProvider provider = new IssuedSecurityTokenProvider();
provider.SecurityTokenSerializer = new WSSecurityTokenSerializer();

//Relying Party's identifier
provider.TargetAddress = new EndpointAddress(new Uri("http://local.zamd.net"));
provider.IssuerAddress = new EndpointAddress(new Uri(baseUri + "Trust/2005/WindowsTransport/"));

provider.SecurityAlgorithmSuite = SecurityAlgorithmSuite.Basic256;
provider.MessageSecurityVersion = MessageSecurityVersion.
WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10;

HttpsTransportBindingElement tbe = new HttpsTransportBindingElement();
tbe.AuthenticationScheme = AuthenticationSchemes.Negotiate;
CustomBinding stsBinding = new CustomBinding(tbe);

provider.IssuerBinding = stsBinding;
provider.Open();
//Request a token from ADFS STS
SecurityToken issuedToken = provider.GetToken(TimeSpan.FromSeconds(30));

Die implizite Option können Sie in der standard-WsFederationHttpBinding, in dem Fall die WCF-Infrastruktur transparent erhält das Token und sendet Sie an den Dienst als Teil des Aufrufs. Immer dann, wenn Sie einen neuen WCF-Proxy zu erstellen und, verwenden um einen Dienst aufrufen, wird die Infrastruktur für Sie ein neues Token abgerufen. Natürlich wäre dies in einigen Szenarios übertrieben. Der Code in Abbildung 6 konfiguriert eine fiktive EmployeeService Tokens von AD FS 2.0 erforderlich ist.

Abbildung 6 Using WsFederationHttpBindingto ein Token implizit einlesen

<system.serviceModel>
  <services>
    <service name="EmployeeService.EmployeeService">
      <endpoint address="http://localhost:9990/ES"
        binding="ws2007FederationHttpBinding"
        contract="EmployeeServiceContract.IEmployeeService"
        bindingConfiguration="adfsFed"/>
    </service>
  </services>
  <bindings>
    <ws2007FederationHttpBinding>
      <binding name="adfsFed">
        <security mode="Message">
          <message negotiateServiceCredential="false" >
            <issuer address="https://bccoss.com/Trust13/KerberosMixed"
               binding="customBinding" bindingConfiguration="MixedKerberos"/>
          </message>
        </security>
      </binding>
     </ws2007FederationHttpBinding>
     <customBinding>
       <binding name="MixedKerberos">
         <security authenticationMode="KerberosOverTransport"/>
         <httpsTransport/>
       </binding>
     </customBinding>
   </bindings>
</system.serviceModel>
Zuordnen von AD FS 2.0 Konzepte zu WCF

Die wichtigsten Verantwortlichkeiten des AD FS 2.0 ist für authentifizierte Benutzer Token ausstellen. Benutzer können mithilfe unterschiedlicher Authentifizierungsmechanismen (z. B. Windows-Authentifizierung) authentifiziert werden. Sie können alle unterstützten Authentifizierungsmechanismen anzeigen, indem Sie den Knoten Endpunkte in der Verwaltungskonsole auswählen.

Sie sehen zwei vertraut WCF-Sicherheitskonzepte als Spaltenüberschriften innerhalb des Knotens Endpunkte:

  • Typ der Authentifizierung ist die AD FS 2.0 entspricht der Terminologie der WCF-ClientCredentialType.
  • Sicherheit-Modus zur Auswahl stehen, Transport, Message oder gemischt. Gemischte entspricht der AD FS 2.0 von WCF-TransportWithMessageCredentials.

Verschiedene Kombinationen der beiden folgenden Werte sind mit andere Endpunkten ausgesetzt, und wählen Sie einen bestimmten Endpunkt basierend auf Ihren Anforderungen für die Authentifizierung. Wenn Sie sich mit Benutzername/Kennwort authentifizieren müssen, würden Sie den Kennwort löschen Authentifizierung Endpunkt auswählen.

Für AD FS 2.0 STS, Zuordnen von diesen Konzepten wieder zu Adresse, Bindung und Vertrag (ABC) in WCF erhalten Sie die folgenden Entsprechungen:

  • Adresse = AD FS-2.0-Basisadresse + des Endpunkts des URL-Pfad
  • Binden des EndPoint-Sicherheitsmodus + Authentication-Type =
  • Vertrag = Standard WS-Trust-Protokoll

Eine Föderation AD FS 2.0 mit einem anderen STS

Zusätzlich zur Erstellung relying Parties, können Sie eine Vertrauensstellung zwischen AD FS 2.0 und Ihre benutzerdefinierten STS oder einem anderen AD FS 2.0 einrichten. Beispielsweise wenn noch ein STS, der authentifiziert Benutzer und -Token ausgibt, können Sie einfach es als eine vertrauenswürdige Identitätsprovider in AD FS 2.0 hinzufügen die vom STS ausgestellte Token akzeptiert wird.

Einrichten eines Anbieters Identity

Einrichten einer neuen, vertrauenswürdigen Identitätsprovider in AD FS 2.0 ist vergleichbar mit einer neuen relying Party einrichten. Der Identity-Dienstanbieter hinzufügen-Assistenten Sie verwenden, sucht und viel verhält sich wie der Assistent zum Hinzufügen von Relying Party (wieder finden Sie in Abbildung 3 ).

Um zur Seite Identifier konfigurieren zu erhalten, wählen Sie die Option manuelle Konfiguration erneut (wie in Abbildung 3 ), und wählen Sie AD FS 2.0 Profil auf der Seite Profil auswählen. Behalten Sie die Standardeinstellungen auf der Seite URL konfigurieren. Sie wählen Sie dann einen Bezeichner und ein öffentliches Schlüsselzertifikat für den Identitätsanbieter aus, und beenden Sie den Assistenten, neue Identitätsprovider zu registrieren.

Anfordern eines Tokens, die mit WCF

Nachdem Sie einen zusätzliche Identitätsprovider mit Active Directory registrieren ähnelt in Abbildung 7 dargestellten Konfiguration EA 2.0, die logische Architektur.


Abbildung 7 Architektur von Active Directory (EA) 2.0 mit dem eine zusätzliche Identität Anbieter

Der Code in Abbildung 8 können Sie erwerben ein Token explizit, Ihnen die Flexibilität, das Token lokal zwischenzuspeichern und Bedarf an den Dienst senden.

Abbildung 8 IssuedTokenWSTrustBinding zum Kauf eines Tokens explizit mithilfe von

string adfsStsUri = "http://bccoss.com/Trust/2005/IssuedTokenAsymmetricBasic256";

//binding for local STS(IP-STS)
WSHttpBinding localStsBinding = new WSHttpBinding(SecurityMode.Message);

localStsBinding.Security.Message.ClientCredentialType = MessageCredentialType.None;
localStsBinding.Security.Message.EstablishSecurityContext = false;
localStsBinding.Security.Message.NegotiateServiceCredential = false;

EndpointAddress localStsEpr = new EndpointAddress(
   new Uri("http://localhost:9000/STS/"),
   new X509CertificateEndpointIdentity(new X509Certificate2(@"MyCustomSTSPublicKey.cer")));

//This binding will transparently acquire all the intermediate tokens as part of the call. (R-STS)
IssuedTokenWSTrustBinding fedBinding = new IssuedTokenWSTrustBinding(localStsBinding, localStsEpr);
fedBinding.TrustVersion = TrustVersion.WSTrustFeb2005;

EndpointAddress adfsStsEpr = new EndpointAddress(
    new Uri(adfsStsUri),
    new X509CertificateEndpointIdentity(new X509Certificate2("AdfsStsPubicKeyOnly.cer")));

WSTrustClient trustClient = new WSTrustClient(fedBinding, adfsStsEpr, TrustVersion.WSTrustFeb2005,
null);

//Create a security token request
RequestSecurityToken rst = new RequestSecurityToken(RequestTypeConstants.Issue);
//Set Relying Party's identifier accordingly
rst.AppliesTo = new EndpointAddress("http://local.zamd.net");

SecurityToken finalToken = trustClient.Issue(rst);

IssuedTokenWSTrustBinding ähnelt sehr dem WsFederationHttpBinding, da es Blendet die Komplexität von intermediate-Token durch transparent Kommunikation mit der IP-STS ein intermediate Token zu erwerben, die dann als ein Authentifizierungstoken R STS gesendet wird.

Der Code in Abbildung 9 verwendet WsFederationHttpBinding, um einen WCF-Client ein Token implizit als Teil eines Dienstaufrufs erwerben zu ermöglichen.

Beachten Sie, dass eine CustomBinding beim Sprechen in den /IssuedTokenMixedSymmetricBasic256 Endpunkt verwendet wird. Standard WsFederationHttpBinding nicht hier möglich, da er versucht, eine sichere Sitzung einzurichten, die nicht kompatibel mit dieser Active Directory ist EA-2.0-Endpunkt. WCF-Clients mit AD FS 2.0 eine Föderation eingehen, müssen Sie entweder eine CustomBinding oder eines der neuen WS-Trust-basierten Bindungen, die Teil des Lieferumfangs mit WIF verwenden.

Abbildung 9 WsFederationHttpBinding zum Kauf einer Token implizit mit

<system.serivceModel>
   <bindings>
      <wsFederationHttpBinding>
         <binding name="R-STS">
            <security mode="Message">
               <message>
                  <issuer address="https://bccoss.com/Trust/2005/IssuedTokenMixedSymmetricBasic256" binding="customBinding" bindingConfiguration="IP-STS"/>
               </message>
            </security>
         </binding>
      </wsFederationHttpBinding>

      <customBinding>
         <binding name="IP-STS">
            <security authenticationMode="IssuedTokenOverTransport">
               <issuedTokenParameters>
                  <issuer address="http://localhost:9000/CustomSTS" binding="wsHttpBinding"/>
               </issuedTokenParameters>
            </security>
            <httpsTransport/>
         </binding>
      </customBinding>
   </bindings>

   <client>
      <endpoint address="http://localhost:9990/ES" binding="wsFederationHttpBinding" bindingConfiguration="R-STS"
contract="ServiceReference1.IEmployeeService" name="WSFederationHttpBinding_IEmployeeService"/>
      </client>
</system.serviceModel>

AD FS 2.0 und Browser Clients

AD FS 2.0 verfügt über eine erstklassige Unterstützung für Web single Sign-On (WebSSO) und des Föderationsszenarios sowohl WS-Federation und SAML 2.0-Protokolle.

Vom Konzept her ähneln WS-Federation und das SAML-Protokoll, obwohl Sie Draht unterschiedliche Darstellungen aufweisen. Das Übertragungsformat WS-Federation ist engem Zusammenhang mit WS-Trust-Protokoll, so dass Sie die logische Wahl beim Bereitstellen von aktiven und passiven (Browser-basierte) Clients sind. Das SAML-Protokoll hat eine bessere Interoperabilität innerhalb verschiedener Hersteller. Systemeigene Unterstützung AD FS 2.0 beide Protokolle. Es ist ratsam, halten Sie ein einzelnes Protokoll (z. B. WS-Federation) innerhalb der Sicherheitsbegrenzung und AD FS 2.0 als Hub Broker-Protokoll für eingehende oder ausgehende SSOs verwenden.

Let’s sollten Sie ein Beispiel. Genommen Sie an, dass Sie eine einfache ASP.NET-Anwendung, die Funktionalität nur für authentifizierte Benutzer bereitstellt. Als eigenständige Anwendung Authentifizierungslogik wird als Teil der Anwendung implementiert, und eine Interaktion mit dieser Anwendung würde die Schritte im Abbildung 10 angezeigt.


Abbildung 10 Direct Authentifizierung in eine einfache ASP.NET-Anwendung

Hier werden die üblichen ASP.NET Authentifizierungsmechanismen, z. B. Formularauthentifizierung, implementiert wird. Unser Ziel ist die Authentifizierung Funktionalität aus dieser Anwendung extrahiert und verwenden Sie stattdessen AD FS 2.0.

Im AD FS 2.0 Setup, die in Abbildung 11 gezeigt wird, die Anwendung wird eine vertrauenswürdige relying Party in AD FS 2.0 und daher vertraut Token von Active Directory ausgestellt EA 2.0. Die Anwendung verwendet WIF für alle Aufgaben des Tokens analysieren, Ansprüche und so weiter zu extrahieren. Die Anwendung, die IIdentity/IPrincipal Standardabstraktionen werden Identitätsinformationen bereitgestellt.

Die verteilte Authentifizierung in AD FS 2.0 ist viel flexibler als direkte Authentifizierung, und es bietet einige wichtige Vorteile:

  • Authentifizierung ist von der Anwendung externalized, damit der Authentifizierungsmechanismus (z. B. von Benutzernamen zu Kerberos) geändert werden kann, ohne dass dies Auswirkungen auf die Anwendung.
  • Die Flexibilität ein anspruchsbasiertes Sicherheitsmodell kann die erforderliche Informationen an die Anwendung (als Teil des Tokens) direkt anstatt die Anwendung selbst Abrufen dieser Informationen aus verschiedenen Quellen bereitstellen.

Die Beta 2-Version des WIF eingeführt neue Projektvorlagen, die eine Anwendung Authentifizierungslogik ein STS externalize erleichtern. Diese Vorlagen sind als des Verfassens dieses Artikels nur in c# verfügbar.


Abbildung 11 verteilte Authentifizierung in AD FS 2.0

Authentifizierung Logic externalizing

Um eine Anwendung Authentifizierungslogik externalize, verwenden Sie das Microsoft Visual Studio-Dialogfeld Neue Website. Wählen Sie die Claims-aware Web Site Vorlage eine standardmäßige ASP.NET Web-Website, die so vorkonfiguriert ist mit WIF erstellen.

Klicken Sie mit der rechten Maustaste auf den Website-Knoten im Projektmappen-Explorer, und wählen Sie ändern STS Verweis aus dem Menü, so starten Sie den Föderation Utility Assistenten, die in Abbildung 12 angezeigt wird.


Abbildung 12 Föderation Dienstprogramm

In diesem Beispiel wir Wählen Sie die Option “ mit einem vorhandenen STS ”, und geben Sie AD FS 2.0 als der STS. Der Assistent benötigt den URL des Dokuments Metadaten um die erforderlichen Konfigurationen zu automatisieren. Die Metadaten-Dokument-URL ist als einen Endpunkt in AD FS 2.0 verfügbar.

Föderation Metadaten enthält wichtige Informationen wie z. B. der STS Signaturzertifikat, die Ansprüche angeboten und die Tokenausstellung URL. Müssen von ein standardisiertes Format for dieser Informationen die Tools zum Automatisieren der Einrichtung von Vertrauensstellungen zwischen einem STS kann und sich die Parteien verlassen.

Die Zusammenfassungsseite des Assistenten sind die Änderungen, die in der Datei web.config vorgenommen werden, zusammengefasst.

Der Föderation Dienstprogramm Assistent konfiguriert WIF in Ihrer Website, um die folgenden Funktionen:

  • Zu AD FS 2.0 werden alle nicht authentifizierte Anforderungen umgeleitet.
  • Jede Anforderung, ein gültiges Token enthält verarbeitet werden, und Identitätsinformationen wird an die Anwendung in Form von ClaimsIdentity/ClaimsPrincipal dargestellt werden. Die Anwendung weiterhin Identitätsinformationen über die IPrincipal/IIdentity Standardabstraktionen unabhängig von der Quelle dieser Informationen zugreifen.

Bevor Sie die Anwendung testen, müssen Sie eine letzte Konfiguration auf AD FS 2.0 ändern. Sie müssen einen zusätzlichen Endpunkt die relying Party für Browserclients hinzufügen. Dieser Endpunkt ist erforderlich, da nachdem AD FS 2.0 eine Tokenausstellung Anforderung verarbeitet hat, zwei Stück von Informationen erforderlich sind, bevor das Token zurück an den Browser gesendet werden können:

  • Die Adresse, wobei das Token gesendet werden soll
  • Das Protokoll (SAML oder WS-Federation), über dem das Token gesendet werden sollten

Sie können einen passiven Endpunkt die relying Party im Test RP Eigenschaftendialogfeld auf der Registerkarte Endpunkte hinzugefügt werden. Beispielsweise wenn Sie als die Endpunkttyp WS-Federation auswählen, sendet AD FS 2.0 Token zurück an die relying Party unter Verwendung des Protokolls WS-Federation. Innerhalb der relying Party verarbeitet die WIF, die WS-Federation Protokoll systemintern versteht diese Token.

Jetzt Wenn Sie versuchen, an die Anwendung zu durchsuchen, Sie automatisch zu AD FS 2.0 für die Authentifizierung umgeleitet werden, möchten in dem Sie die Authentifizierungsmethode auswählen können Sie verwenden: Integrierte Windows-Authentifizierung, Zertifikatsauthentifizierung oder Benutzername/Kennwort-Formular.

Sobald die Authentifizierung erfolgreich, ist Sie – zusammen mit einem von AD FS 2.0 ausgestellte Token – werden an die Anwendung umgeleitet. WIF verarbeitet dieses Token und macht die letzte Identität (in Form von Ansprüchen) für die Anwendung, die ASP.NET Standardmechanismen (z. B. Page.User) verfügbar.

Browser-basierte Föderation

Sie können eine externe Standardauthentifizierung Szenario in einem Verbundszenario erweitern, indem Sie zusätzliche vertrauenswürdigen Identitätsprovider hinzufügen. Die Identität Provideroptionen werden während des Authentifizierungsvorgangs angezeigt.

Sie können mit AD FS 2.0 authentifizieren, oder eine andere Identitätsprovider vertrauenswürdig. Wenn Sie einen andere Identität-Anbieter auswählen, Sie an, dass Identitätsprovider umgeleitet und nach erfolgreicher Authentifizierung umgeleitet an AD FS 2.0, die dann basierend auf das Token, die von der vertrauenswürdigen Identitätsprovider ausgestellt authentifiziert werden würde.

Leistungsfähige Kombination

Wie Sie in diesem Artikel gesehen haben, AD FS 2.0 STS stellt ein einfach und vorgefertigte Lösung für Ansprüche-Ihre WCF-Dienste und browserbasierten Anwendungen aktivieren. STS selbst ist nur ein kleines Stück AD FS 2.0, der auch ein System, eine regelbasierte Ansprüche Transformation Engine, Automatisches vertrauen zu Infrastruktur, Verwaltung und Konfiguration Verwaltungsdienste und Ihre jeweiligen Tools Bereitstellung CardSpace enthält. Zusammen mit WIF erstellt AD FS 2.0 eine leistungsfähige Kombination Programm Identität Lösungen auf der Windows-Plattform.

Zulfiqar Ahmed ist Senior Consultant im Team UK Application Development Consulting (ADC) und kann unter http://zamd.net erreicht werden.