Active Directory und anspruchsbasierte Authentifizierung

 

Veröffentlicht: Januar 2017

Gilt für: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

Anspruchsbasierte Authentifizierung bietet ein branchenkompatibles Sicherheitsprotokoll, um einen Benutzer auf einem Hostcomputer zu authentifizieren. Anspruchsbasierte Authentifizierung ist eine Reihe WS-*-Standards, die die Verwendung eines Security Assertion Markup Language (SAML)-Tokens im passiven Modus (wenn der WS-Verbund mit der Microsoft Dynamics 365 (online und lokal)-Webanwendung verwendet wird) oder aktiven Modus (wobei WS-Trust mit Windows Communication Foundation (WCF)-Clients verwendet wird) beschreiben. Diese Authentifizierung arbeitet mit WCF, um eine sichere Benutzerauthentifizierung und einen Kommunikationskanal mit einem Microsoft Dynamics 365-Server zu bieten. Alle Microsoft Dynamics 365-Editionen unterstützen anspruchsbasierte Authentifizierung.

Die anspruchsbasierte Authentifizierung erfordert die Verfügbarkeit von Sicherheitstokendienst (STS), das auf einem Server ausgeführt wird. Ein STS-Server kann auf Active Directory Federation Services (AD FS) V2 basiert sein, oder einer Plattform, die das offizielle STS-Protokoll bereitstellt. Weitere Informationen finden Sie im folgenden Thema in der Dynamics 365-Bereitstellungs- und -Verwaltungsdokumentation: TechNet: Konfigurieren von IFD für Microsoft Dynamics CRM 2015.

In diesem Thema

Unterstützte Authentifizierungsszenarien

Nicht-unterstützte Authentifizierungsszenarien

Authentifizierungsklassen

Authentifizierung mithilfe der Clientproxyklassen

Behandlung von Kanalausnahmen und -fehlern

Zusätzliche Informationen zum Sicherheitstoken (SAML)

Unterstützte Authentifizierungsszenarien

Microsoft Dynamics 365 unterstützt die folgenden Authentifizierungsszenarien für jede Bereitstellungsart.

Bereitstellung	Authentifizierungsmodell
Microsoft Dynamics 365 (online)	Anspruchsbasierte oder Active Directory-Authentifizierung (durch Verbund)
Microsoft Dynamics 365 (lokal)	Anspruchsbasierte oder Active Directory-Authentifizierung
Microsoft Dynamics 365Bereitstellung mit Internetzugriff (IFD)	Anspruchsbasierte oder Active Directory-Authentifizierung

So funktioniert die anspruchsbasierte Authentifizierung.

Eine Anforderung, einen Benutzer zu authentifizieren, wird von Microsoft Dynamics 365 oder Microsoft Dynamics 365 (online) einer benutzerdefinierten Anwendung an den STS-Server gesendet. Der STS-Server ermittelt, ob der Benutzer authentifiziert werden soll, und gibt, wenn ja, ein verschlüsseltes SAML-Token aus, das die Benutzerauthentifizierungsinformationen enthält. Das Token hat eine begrenzte Lebensdauer und muss möglicherweise regelmäßig aktualisiert werden, abhängig davon, wie lange die Anwendung das Token verwendet. Dies wird weiter unten in diesem Thema detaillierter behandelt.

So funktioniert Active Directory-Authentifizierung.

Eine Anforderung, einen Benutzer zu authentifizieren, wird von Microsoft Dynamics 365 oder einer benutzerdefinierten Anwendung an Active Directory gesendet. Der WCF-Stapel verwaltet den Organisationsprozess für Internetinformationsdienste (IIS)-Aufrufe aus einer Anwendung, während die Authentifizierung für eine Webanwendung verwaltet.

Nicht-unterstützte Authentifizierungsszenarien

Die Verwendung von Clientzertifikaten wird von Microsoft Dynamics 365 SDK nicht unterstützt. Wenn Sie die Microsoft Dynamics 365-Website so konfigurieren, dass IIS-Clientzertifikate erforderlich sind, erhalten Sie Authentifizierungsfehler bei allen Anwendungen, die mithilfe des SDK erstellt wurden.

Weitere Informationen zu zusätzlichen unterstützten Programmierverfahren finden Sie unter Nicht unterstützte Anpassungen.

Authentifizierungsklassen

Die folgende Tabelle enthält die primären Authentifizierungsklassen, die im SDK verfügbar sind, beschreibt, wann sie verwendet werden, und enthält Links zu weiteren relavanten Dokumentationen.

Klassen	Verwendung	Verwandte Dokumentationen
IServiceConfiguration<TService>, IServiceManagement<TService>	Alle Bereitstellungstypen: lokale Version/IFD, online (Microsoft-Konto und Office 365/MOS*) Beste Option für Multi-Thread-Anwendungen	Authentifizieren von Office 365-Benutzern durch die Microsoft Dynamics 365 (online)-Webdienste Beispiel: Authentifizieren von Benutzern durch die Microsoft Dynamics 365-Webdienste Verbessern der Servicekanal-Zuteilungsleistung
DiscoveryServiceProxy, OrganizationServiceProxy	Alle Bereitstellungstypen: lokale Version/IFD, online (Microsoft-Konto und Office 365/MOS*)	Authentifizierung mithilfe der Clientproxyklassen Beispiel: Zugreifen auf den Suchdienst Verbessern der Servicekanal-Zuteilungsleistung
CrmConnections-Klasse	Alle Bereitstellungstypen: lokale Version/IFD, online (Microsoft-Konto und Office 365/MOS*)	Vereinfachte Verbindung mit Microsoft Dynamics CRM Beispiel: Erste Schritte für einfacheres Herstellen von Verbindungen mithilfe von Microsoft Dynamics 365
Verbindung mit dem Server	Alle Bereitstellungstypen: lokale Version/IFD, online (Microsoft-Konto und Office 365/MOS*) Verwendung für Konsolentest-Anwendungen und Beispielcode. Entworfen, um die Benutzerfreundlichkeit zu verbessern, wenn SDK-Beispielcode ausgeführt wird und um die Nutzung der Authentifizierungsklassen vorzuführen. Enthält Konsolenausgabecode.	Hilfscode: Klasse "ServerConnection" Beispiel: Erste Schritte für Microsoft Dynamics 365

*Microsoft Online Services-Umgebung

Authentifizierung mithilfe der Clientproxyklassen

Eine Möglichkeit, sich bei den Microsoft Dynamics 365-Webdiensten zu authentifizieren, ist durch Verwendung der OrganizationServiceProxy- und DiscoveryServiceProxy-Klassen in der Anwendung, die Sie schreiben. Der Vier-Parameter-Konstruktor dieser Klassen unterstützt Microsoft Dynamics 365 (online und lokal)-Bereitstellungen. Diese Proxyklassen verarbeiten Ansprüche oder Active Directory-Authentifizierung automatisch und verwalten auch Ressourcenbegrenzungen im WCF-Kanalendpunkt.

Der folgende Codezeigt, wie der Organisationsserviceproxy instanziiert wird:

using (OrganizationServiceProxy _serviceProxy =    new OrganizationServiceProxy(organizationUri, homeRealmUri, userCredentials, deviceCredentials))

Der folgende Codezeigt, wie der Suchdienst-Proxy instanziiert wird:

using (DiscoveryServiceProxy _discProxy =    new DiscoveryServiceProxy(organizationUri, homeRealmUri, userCredentials, deviceCredentials))

Es ist wichtig, die Serviceproxyinstanz ordnungsgemäß in der Anwendung zu entfernen, bevor die Anwendung beendet wird. Duch die using-Anweisung wird sichergestellt, dass der Serviceproxy ordnungsgemäß entfernt wird, indem automatisch auf dem Serviceproxy Dispose aufgerufen wird, wenn er den Bereich verlässt. Für verbesserte Leistung der Anwendung ist es jedoch eine bewährte Methode, die Serviceproxyinstanz in der Anwendung für die gesamte Anwendungssitzung verfügbar sein zu lassen, anstatt sie zu entfernen und sie an einer anderen Stelle in Anwendungscode nach Bedarf erneut zuzuweisen. Der Grund ist der, dass das Erstellen und Authentifizieren eines Servicekanals ein (zeitlich) aufwändiger Vorgang ist. In diesem Fall müssen Sie, wenn Sie die Serviceproxyinstanz beendet haben, die Entfernungs -Methode direkt auf dem Proxy aufrufen, bevor die Anwendung endet.

Die Geräteanmeldeinformationen des registrierten des Computers werden nur bei der Authentifizierung bei Microsoft Dynamics 365 (online) durch den Microsoft-Konto-Identitätsanbieter verwendet. Beispielcode, der zeigt, wie die Proxykonstruktorparameter aufgefüllt werden, finden Sie unter Beispiel: Zugreifen auf den Suchdienst.

Wichtig

Bei einer lokale Bereitstellung oder einer Installatiopn mit Internetzugriff (IFD) von Microsoft Dynamics 365 verwenden die Clientproxyklassen anspruchsbasierte Authentifizierung, wenn ein STS-Server verfügbar ist. Andernfalls wird Active Directory-Authentifizierung verwendet.

Wenn Sie Microsoft Dynamics 365-Entitätstypen mit früher Bindung verwenden möchten, müssen Sie die folgende Codezeile hinzufügen, nachdem der Organisationsserviceproxy instanziiert ist, aber bevor Sie Webdienstmethodenaufrufe durchführen:

_serviceProxy.EnableProxyTypes()

Sicherheit Hinweis

WCF unterstützt eine Funktion, mit in der sie den Benutzer interaktiv zur Eingabe von Anmeldeinformationen auffordern können, falls es erforderlich ist. Diese Funktion wird aktiviert, indem die Eigenschaft SupportInteractive der ClientCredentials-Klasse festgelegt wird. Diese Anmeldeinformationen werden im userCredentials-Parameter verwendet, der im vorherigen Codeausschnitt gezeigt wurde. Wenn SDK-Aufrufe an die Microsoft Dynamics 365-webdienste durchgeführt werden, können der Besitz des Vorgangs und Entitätsdatenänderungen, die vom SDK-Aufruf durchgeführt werden, durch diese WCF-Funktion unabhängig von Ihrer Auswahl geändert werden. Microsoft Dynamics 365 behandelt bereitgestellte Anmeldeinformationen in Webdienstaufrufen wie folgt: Wenn im Webdienstaufruf keine Anmeldeinformationen angegeben wurden, bestimmt der WCF-Stapel, welche Anmeldeinformationen zu verwenden sind. In diesem Fall wird der SupportInteractive-Eigenschaftswert automatisch zu false festgelegt. Wenn Anmeldeinformationen explizit von Ihrem Code angegeben sind, wird der aktuelle SupportInteractive-Wert an die WCF-Kanalfactory übergeben.SupportInteractive wird standardmäßig auf true festgelegt, es sei denn, Sie ändern es explizit. Wenn SupportInteractive zu true festgelegt ist und die bereitgestellten Anmeldeinformationen fehlschlagen, wird möglicherweise ein WCF-Dialogfeld angezeigt. Alle Anmeldeinformationen, die vom Benutzer im Dialogfeld in eingegeben werden, werden anstele derjenigen verwendet, die in den Webdienstaufrufen angegeben werden, die Ihre Anwendung aufruft.

Behandlung von Kanalausnahmen und -fehlern

Ihr Code sollte die folgenden Ausnahmen und Fehler abfangen. In den C#- oder -Beispielen in Microsoft Dynamics 365 SDK finden Sie eine Liste von zusätzlichen Ausnahmen, die abzufangen sind:

• System.TimeoutException

• FaultException <OrganizationServiceFault>

• FaultException <DiscoveryServiceFault>

Weitere Information finden Sie in der .NET FrameworkWCF-Dokumentation zur Behandlung von WCF-Fehlern und -Ausnahmen. Vgl. Verwenden des Beispiel- und Hilfscode für zusätzlichen Beispielcode.

Zusätzliche Informationen zum Sicherheitstoken (SAML)

Das SAML-Token, das bei der Benutzerauthentifizierung verwendet wird, wird unten beschrieben.

Inhalt des SAML-Tokens

Das XML-basierte SAML 2.0-Token enthält eine Identität, die einen oder mehrere Ansprüche zu einem Benutzer definiert. Dieses Token wird zwischen einem Identitätsanbieter (STS)-Server und Microsoft Dynamics 365 für anspruchsbasierte Authentifizierung übergeben. Die Ansprüche in der Identität sind wie folgt definiert worden.

Anspruch	Verwenden
Universeller Prinzipalname (UPN)	Enthält die ID des Benutzers im domain\alias-Format auf dem Ziel-Microsoft Dynamics 365-Server.
Name	Wenn der authentifizierte Benutzer auch ein Bereitstellungsadministrator in Microsoft Dynamics 365 ist, enthält dieser Anspruch die ID des Bereitstellungsadministrators im domain\alias-Format auf dem Ziel-Microsoft Dynamics 365-Server.Windows Identity Foundation ordnet den Name-Anspruch zur Identity.name-Eigenschaft zu.
Weitere Ansprüche	Nicht verwendet von Microsoft Dynamics 365.

Unterstützte Sicherheitstokentypen

Microsoft Dynamics 365 (online und lokal) unterstützen zwei Typen von SAML-Tokens:

• Webanwendung - Die Microsoft Dynamics 365-Webanwendung erhält ein Trägertoken von STS. Diesem Token fehlen einige der erforderlichen Informationen, daher wird eine Transport Layer Security (TLS) oder Secure Sockets Layer (SSL)-basierte URL (https://) als Sicherheitsschutz verwendet, wenn Sie auf den WCF-Endpunkt zugreifen.

• SDK - Eine benutzerdefinierte Anwendung empfängt ein aktives Token mit einem Prüfschlüssel, das die erforderlichen Informationen enthält.

Lebenszyklus eines Sicherheitstokens

Die Gültigkeitsdauer eines SecurityToken wird durch seine ValidFrom- und ValidTo-Eigenschaften identifiziert. Ihr Anwendungsdesign sollte die Möglichkeit berücksichigen, dass das Token ablaufen könnte, mit dem Ergebnis, dass eine ExpiredSecurityTokenException durch die Microsoft Dynamics 365-Webdienste ausgelöst wird, wenn die nächste Nachrichtenanforderung von Ihrer Anwendung verarbeitet wird.

Siehe auch

Exemplarische Vorgehensweise: Registrieren einer Dynamics 365-App mit Active Directory
Verbinden mit Microsoft Office 365 und Microsoft Dynamics 365 (online)
Implementieren Sie einmaliges Anmelden von einer ASPX-Webseite oder IFRAME
Beispiel: Authentifizieren von Benutzern durch die Microsoft Dynamics 365-Webdienste

Microsoft Dynamics 365

© 2017 Microsoft. Alle Rechte vorbehalten. Copyright