Authentifizieren des Benutzers durch die Webdienste

  • Artikel

 

Veröffentlicht: Januar 2017

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

Sie können die externe Clientauthentifizierungsfunktion von Microsoft Dynamics 365 verwenden, um eigene Client-Apps für Mobilgeräte wie Telefone und Tablets sowie für den Windows 8-Desktop zu entwickeln. Diese Funktion ist auch für nicht-.NET-Anwendungen verfügbar.

In diesem Thema

Überblick zur Authentifizierung

Technologieabhängigkeiten

Sicherheit

Benutzeranmeldung und Anwendungsregistrierung

Die Client-Anwendung

OAuth-Autorisierungsendpunkte

Ermitteln der OAuth-Endpunkt-URL

Angeben einer OAuth-Ressource

Überblick zur Authentifizierung

Entwickler, die moderne und mobile Apps erstellen, einschließlich der Apps, die nicht auf .NET Framework aufbauen, können auf die Geschäftsdaten von Microsoft Dynamics 365 über die SOAP- und OData-Endpunkte des Organisationswebdiensts zugreifen. Dieser Webdienst unterstützt bestimmte Authentifizierungsfunktionen aus dem OAuth-2.0-Protokoll.

In der folgenden Liste werden die Komponenten beschrieben, die bei einer modernen und mobilen App-Authentifizierung unterstützt werden:

  • Verwendung von JSON-Webtokens in der HTTP-Autorisierungskopfzeile

  • Authentifizierung für den OData-Dienst durch externe Apps (außerhalb des Browsers)

  • Authentifizierung für den Organization.svc/web-Dienst (SOAP) durch externe Anwendungen (außerhalb des Browsers)

Technologieabhängigkeiten

Die folgenden Technologien sind erforderlich, um externe Client-Anwendungen zu entwickeln und auszuführen, die zusammen mit den Microsoft Dynamics 365-Webdiensten OData und SOAP eine Authentifizierung durchführen:

Die folgenden Technologien sind optional, um externe Client-Anwendungen zu entwickeln und auszuführen, die zusammen mit den Microsoft Dynamics 365-Webdiensten OData und SOAP eine Authentifizierung durchführen:

Sicherheit

Die folgenden Sicherheitsinformationen gelten für diese Authentifizierungsfunktion:

  • Das Authentifizierungstoken wird auf dem Gerät im geschütztem Speicher abgelegt. Unter dem Windows-Betriebssystem wird das Windows-Anmeldeinformationsverwaltung verwendet.

  • Die Funktion verwendet Transport Layer Security (TLS) oder Secure Sockets Layer (SSL) für HTTP-Anforderungen.

Benutzeranmeldung und Anwendungsregistrierung

Die folgenden Informationen beziehen sich auf die Benutzeranmeldung und Anwendungsregistrierung.

  • Die Benutzeranmeldung für Microsoft Azure-Active Directory-Authentifizierungsbibliothek (Active Directory Authentication Library; ADAL) wird von einem Webbrowserkontext behandelt.

  • Die Anwendungsregistrierung wird durch Azure Active Directory für eine Dynamics 365 (online)-Bereitstellung verwaltet, und durch Active Directory Federation Services (AD FS) für eine lokale Version oder für Bereitstellung mit Internetzugriff (IFD). Sie können das Microsoft Azure-Verwaltungsportal oder die API verwenden, um Ihre App mit Dynamics 365 (online) zu registrieren.

Die Client-Anwendung

Der Umfang der Vorgänge, die eine externe Client-Anwendung ausführen kann, wird in der folgenden Liste zusammengefasst:

  • Bei der Verwendung des OData-Endpunkts werden Erstellungs-, Abruf-, Aktualisierungs- und Löschvorgänge unterstützt. Es gibt keine Unterstützung für die Ausführung von Meldungen oder den Abruf von Metadaten.

  • Wenn der SOAP-Endpunkt (Organization.svc/web) für moderne und mobile Anwendungen verwendet wird, ist der vollständige Webdienstfunktionsumfang verfügbar.

Wenn Sie Clientcode schreiben, der Anrufe beim Webservice tätigt, wird empfohlen, vor jedem Serviceanruf durch ADAL ein Token anzufordern. So kann ADAL bestimmen, ob eine Instanz des n Zugriffstokens wiederverwendet werden soll, eine Anforderung für ein neues unter Verwendung des Refresh-Tokens gestellt werden soll, oder ob der Benutzer aufgefordert werden soll, sich erneut anzumelden.

Ermitteln der OAuth-Endpunkt-URL

Die Möglichkeit zur Ermittlung der Zertifizierungsstelle für die Webdienstauthentifizierung während der Laufzeit wird als eine alternative Methode bereitgestellt, um die Zertifizierungsstelle in Anwendungen oder Konfigurationsdateien in zu erhalten, im Gegensatz zu fest programmierten OAuth-Anbieter-URLs.

Der Ermittlungsprozess wird gestartet, indem eine nicht autorisierte HTTP-Anfrage mit dem Begriff "Bearer" in der Kopfzeile der Authorization und der SOAP-Endpunkt-URL der Mandantenorganisation als Text der Anforderungsnachricht.

GET /XRMServices/2011/Organization.svc HTTP/1.1 Host: <org>.crm.dynamics.com Authorization: Bearer

Hinweis

Die Trägerabfrage ist jetzt optional. Ein GET ohne eine Autorisierungskopfzeile ergibt dieselben Ergebnisse.

Eine 401-Fehlermeldung wird zurückgegeben, mit einer Antwort, die einen authorization_uri-Parameter enthält. Der Wert dieses Parameters ist eine Zertifizierungsstellen-URL.

HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer authorization_uri=URI

Die Zertifizierungsstellen-Ermittlungsfunktion für SOAP-Clients ist nur verfügbar, wenn eine SdkClientVersion-Eigenschaft in der SOAP-Endpunkt-URL der Mandantenorganisation vorhanden ist. Eine Beispiel-URL wird unten angezeigt.

https://contoso.crm.dynamics.com/XRMServices/2011/Organization.svc/web?SdkClientVersion=6.1.0.533;

Der Wert für SdkClientVersion kann eine beliebige Versionsnummer mit mindestens einem "Dezimalpunkt" und größer als 6.0.0002.0000 sein. Es wird empfohlen, dass der SdkClientVersion-Eigenschaftswert auf die Produktbuildversion der SDK-Assemblys gesetzt wird, die mit der Client-Anwendung verknüpft wurden.

Das folgende Codebeispiel zeigt, wie die Zertifizierungsstellen-URL abgerufen wird. Beachten Sie, dass der Beispielcode das Microsoft Azure-Active Directory-Authentifizierungsbibliothek (Active Directory Authentication Library; ADAL) verwendet, das unter NuGet.org abgerufen werden kann. Darüber hinaus gibt es Open Source-Versionen dieser Bibliothek für Android und iOS.


/// <summary>
/// Discover the authentication authority.
/// </summary>
/// <param name="serviceUrl">The URL of the organization's SOAP endpoint. </param>
/// <returns>The authority URL.</returns>
/// <remarks>The service URL must contain the SdkClient property.</remarks>
/// <example>https://contoso.crm.dynamics.com/XRMServices/2011/Organization.svc/web?SdkClientVersion=6.1.0.533;</example>
public static string DiscoveryAuthority(Uri serviceUrl)
{
    // Use AuthenticationParameters to send a request to the organization's endpoint and
    // receive tenant information in the 401 challenge. 
    Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationParameters parameters = null;
    HttpWebResponse response = null;
    try
    {
        // Create a web request where the authorization header contains the word "Bearer".
        HttpWebRequest httpWebRequest = (HttpWebRequest)WebRequest.Create(serviceUrl);

        // The response is to be encoded.
        httpWebRequest.ContentType = "application/x-www-form-urlencoded";
        response = (HttpWebResponse)httpWebRequest.GetResponse();
    }

    catch (WebException ex)
    {
        response = (HttpWebResponse)ex.Response;

        // A 401 error should be returned. Extract any parameters from the response.
        // The response should contain an authorization_uri parameter.
        parameters = Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationParameters.
            CreateFromResponseAuthenticateHeader((response.Headers)["WWW-Authenticate"]);
    }
    finally
    {
        if (response != null)
            response.Dispose();
    }
    // Return the authority URL.
    return parameters.Authority;
}

OAuth-Autorisierungsendpunkte

Eine alternative Methode zur Verwendung der OAuth-Ermittlung ist die Verwendung bekannter OAuth-Autorisierungsendpunkte. Beim Schreiben einer App, die mit den Microsoft Dynamics 365 (online und lokal)-Webdiensten authentifiziert, müssen Sie in Ihrem Authentifizierungscode die OAuth-Anbieter-URLs wie in der folgenden Tabelle veranschaulicht verwenden.

Bereitstellung

URL

Microsoft Dynamics 365 (online)

HYPERLINK "https://login.windows.net/common/oauth2/authorize" https://login.windows.net/common/oauth2/authorize (Mehrinstanz)

https://login.windows.net/<tenant ID>/oauth2/authorize (einzelner Mandant)

Microsoft Dynamics 365 (lokale Version/IFD)

https://<serverFQDNaddress>/adfs/ls

Ersetzen Sie die Adresse Ihres IFD-Servers, beispielsweise contoso.com in der Sicherheitstokendienst (STS)-URL. Die angezeigte STS-URL wird in der Standardinstallation von AD FS benötigt. Eine benutzerdefinierte Installation verwendet möglicherweise eine andere URL. Ersetzen Sie an der entsprechenden Stelle auch Ihre Mandanten-ID.

Es wird empfohlen, dass Sie die OAuth-Ermittlung immer mit Dynamics 365 (online) verwenden, da sich die Autorisierungsendpunkte mit der Zeit ändern können.

Angeben einer OAuth-Ressource

Beim der Authentifizierung mit Microsoft AzureActive Directory mithilfe des OAuth-Autorisierungscodeflusses, müssen Sie einen Wert für die Zielressource bereitstellen. Die Internetadresse der Stammorganisation, beispielsweise https://contoso.crm.dynamics.com, muss als "Ressourcen"-Abfragezeichenfolgenparameter im Aufruf des OAuth-Autorisierungsendpunkts verwendet werden.

// Obtain an authentication token to access the web service.
String resource = “https://contoso.crm.dynamics.com”; 
_authenticationContext = new AuthenticationContext(_oauthUrl, false );
AuthenticationResult result = await _authenticationContext.AcquireTokenAsync( resource, clientID );

Weitere Informationen:Beispiel: Moderne OData-App für Windows 8-Desktop

Siehe auch

Schreiben von mobilen und modernen Apps
Exemplarische Vorgehensweise: Registrieren einer Dynamics 365-App mit Active Directory
Authentifizieren von Benutzern in Microsoft Dynamics 365
Blog: Vorstellung einer neuen Funktion in der Azure-AD-Entwicklervorschau: die Authentifizierungsbibliothek Azure
Serverseitige CRM-Authentifizierung mit Azure Active Directory

Microsoft Dynamics 365

© 2017 Microsoft. Alle Rechte vorbehalten. Copyright