Active Directory und anspruchsbasierte Authentifizierung
Anspruchsbasierte Authentifizierung bietet ein branchenkompatibles Sicherheitsprotokoll, um einen Benutzer auf einem Hostcomputer zu authentifizieren. Bei der anforderungsbasierten Authentifizierung handelt es sich um einen Satz von WS-*-Standards, die die Verwendung eines Security Assertion Markup Language (SAML)-Tokens entweder im passiven Modus (wenn WS-Federation mit der Webanwendung Dynamics 365 for Customer Engagement verwendet wird) oder im aktiven Modus (wenn 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 Dynamics 365 Server zu bieten. Alle Dynamics 365 Customer Engagement (on-premises) Editionen unterstützen anspruchsbasierte Authentifizierung.
Die anspruchsbasierte Authentifizierung erfordert die Verfügbarkeit eines Sicherheitstokendienstes (STS), das auf einem Server ausgeführt wird. Ein STS-Server kann auf Active Directory Federation Services (AD FS) V2 oder einer beliebigen Plattform basieren, die das offizielle STS-Protokoll bereitstellt. Weitere Informationen: TechNet: Konfigurieren von IFD für Dynamics 365 Customer Engagement (on-premises).
Unterstützte Authentifizierungsszenarien
Dynamics 365 Customer Engagement (on-premises) unterstützt die folgenden Authentifizierungsszenarien für jede Bereitstellungsart.
| Bereitstellung | Authentifizierungsmodell |
|---|---|
| Dynamics 365 for Customer Engagement (on-premises) | Claims-basierte oder Active Directory-Authentifizierung |
| Dynamics 365 for Customer Engagement Internet-facing deployment (IFD) | Claims-basierte oder Active Directory-Authentifizierung |
So funktioniert die anspruchsbasierte Authentifizierung.
Eine Anfrage zur Authentifizierung eines Benutzers wird von Dynamics 365 for Customer Engagement oder einer angepassten 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 Anfrage zur Authentifizierung eines Benutzers wird von Dynamics 365 Customer Engagement (on-premises) oder einer angepassten Anwendung an Active Directory gesendet. Der WCF-Stack verwaltet den Authentifizierungsprozess für Organization Service-Aufrufe aus einer Anwendung, während Internet Information Services (IIS) die Authentifizierung für eine Webanwendung verwaltet.
Nicht-unterstützte Authentifizierungsszenarien
Die Verwendung von Clientzertifikaten wird nicht unterstützt. Wenn Sie die Dynamics 365 Customer Engagement-Website so konfigurieren, dass IIS-Clientzertifikate erforderlich sind, erhalten Sie Authentifizierungsfehler bei allen Anwendungen, die mithilfe des SDK erstellt wurden.
Weitere Informationen über zusätzliche nicht unterstützte Programmiermethoden 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.
* Microsoft Online Services Umgebung
Tipp
Abhängig von Ihrem Anwendungsszenario ist die empfohlene Methode, eine .NET Framework Client-Anwendung mit jeder Bereitstellung von Dynamics 365 Customer Engagement (on-premises) zu authentifizieren und die CrmServiceClient Klasse zu verwenden.
Verwenden Sie die ServiceClient -Klasse nicht, wenn Sie ADFS für die lokale Authentifizierung verwenden.
Authentifizierung mithilfe der Clientproxyklassen
Eine Möglichkeit, sich bei den Dynamics 365 Customer Engagement (on-premises)-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 die Bereitstellung von Dynamics 365 for Customer Engagement. Diese Proxy-Klassen handhaben automatisch Ansprüche oder die Active Directory-Authentifizierung und verwalten auch die Ressourcenbeschränkungen auf dem WCF-Channel-Endpunkt.
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 Anmeldeinformationen des registrierten Computergeräts werden nur bei der Authentifizierung mit Dynamics 365 for Customer Engagement über den Microsoft Account Identity Provider verwendet. Beispielcode, der zeigt, wie die Proxykonstruktorparameter aufgefüllt werden, finden Sie unter Beispiel: Zugreifen auf Suchdienst.
Wichtig
Bei einer Installation von Dynamics 365 for Customer Engagement vor Ort oder einem Internet-facing deployment (IFD) verwenden die Client-Proxy-Klassen die behauptungsbasierte Authentifizierung, wenn ein STS-Server verfügbar ist. Andernfalls wird die Active Directory-Authentifizierung verwendet.
Wenn Sie Dynamics 365 Customer Engagement (on-premises)-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()
Wichtig
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 Dynamics 365 Customer Engagement (on-premises)-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.
Dynamics 365 Customer Engagement (on-premises) behandelt die bereitgestellten 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 zufalsefestgelegt.- Wenn Anmeldeinformationen explizit von Ihrem Code angegeben sind, wird der aktuelle
SupportInteractive-Wert an die WCF-Kanalfactory übergeben.SupportInteractiveist standardmäßig auftruefestgelegt, sofern Sie es nicht explizit ändern. - Wenn
SupportInteractivezutruefestgelegt 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.
- Wenn Anmeldeinformationen explizit von Ihrem Code angegeben sind, wird der aktuelle
Behandlung von Kanalausnahmen und -fehlern
Ihr Code sollte die folgenden Ausnahmen und Fehler abfangen. In den C#-Beispielen in der Entwicklerdokumentation finden Sie eine Liste von zusätzlichen Ausnahmen, die abzufangen sind:
FaultException<DiscoveryServiceFault>
Weitere Informationen finden Sie in der WCF-Dokumentation des .NET Frameworks über den Umgang mit WCF-Fehlern und Ausnahmen.
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 Dynamics 365 Customer Engagement (on-premises) 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 Dynamics 365 Server. |
| Name | Wenn der authentifizierte Benutzer auch ein Bereitstellungsadministrator in Dynamics 365 Customer Engagement (on-premises) ist, enthält dieser Anspruch die ID des Bereitstellungsadministrators im domain\alias-Format auf dem Ziel Dynamic 365 Server. Windows Identity Foundation ordnet den Name-Anspruch zur Identity.name-Eigenschaft zu. |
| Weitere Ansprüche | Nicht verwendet von Dynamics 365 Customer Engagement (on-premises). |
Unterstützte Sicherheitstokentypen
Dynamics 365 for Customer Engagement unterstützt zwei Arten von SAML-Tokens:
Webanwendung - Die Dynamics 365 Customer Engagement (on-premises)-Webanwendung erhält ein Trägertoken von STS. Bei diesem Token fehlt einige erforderliche Information, so wird eine Transport Layer Security (TLS)- oder Secure Sockets Layer (SSL)-basierte URL (https://) zum 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 Dynamics 365 Customer Engagement (on-premises)-Webdienste ausgelöst wird, wenn die nächste Nachrichtenanforderung von Ihrer Anwendung verarbeitet wird.
Siehe auch
Exemplarische Vorgehensweise: Registrieren einer Dynamics 365 Customer Engagement (on-premises) bei Active Directory
Verbinden von Microsoft Office 365 und Dynamics 365 Customer Engagement (on-premises)
Implementieren Sie einmaliges Anmelden von einer ASPX-Webseite oder IFRAME
Beispiel: Authentifizieren von Benutzern mit Dynamics 365 Customer Engagement-Webdiensten