War diese Seite hilfreich?
Ihr Feedback ist uns wichtig. Teilen Sie uns Ihre Meinung mit.
Weiteres Feedback?
1500 verbleibende Zeichen
Exportieren (0) Drucken
Alle erweitern

Vorgehensweise: Anfordern eines Tokens bei ACS mithilfe des OAuth-WRAP-Protokolls

Letzte Aktualisierung: März 2015

  • Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS)

Wenn Ihre Webanwendungen und -dienste die Authentifizierung mithilfe von ACS verarbeiten, muss der Client ein von ACS ausgestelltes Sicherheitstoken erhalten, um sich bei Ihrer Anwendung oder Ihrem Dienst anzumelden. Um dieses von ACS ausgestellte Token (Ausgabetoken) zu erhalten, muss der Client sich entweder direkt bei ACS authentifizieren oder ein von seinem Identitätsanbieter ausgegebenes Sicherheitstoken (Eingabetoken) an ACS senden. ACS überprüft dieses Eingabesicherheitstoken, verarbeitet die Identitätsansprüche in diesem Token anhand des ACS-Regelmoduls, berechnet die Ausgabeidentitätsansprüche und gibt ein Ausgabesicherheitstoken aus.

In diesem Thema werden die Methoden zum Anfordern eines Tokens bei ACS mithilfe des OAuth-WRAP-Protokolls beschrieben. Alle Tokenanforderungen über das OAuth-WRAP´-Protokoll werden über SSL übermittelt. ACS gibt als Antwort auf eine im richtigen Format eingehende Tokenanforderung immer ein SWT (Simple Web Token) über das OAuth-WRAP-Protokoll aus. Alle Tokenanforderungen über das OAuth-WRAP-Protokoll werden in einem HTTP POST an ACS gesendet. Sie können ein ACS-Token über das OAuth-WRAP-Protokoll von jeder Plattform aus, die HTTPS FORM POSTs vornehmen kann, anfordern: .NET Framework, Windows Communication Foundation (WCF), Silverlight, ASP.NET, Java, Python, Ruby, PHP, Flash und andere Plattformen.

In der folgenden Tabelle sind drei unterstützte Verfahren zum Anfordern eines von ACS ausgestellten SWT-Tokens über das OAuth-WRAP-Protokoll aufgelistet.

Drei Verfahren zum Anfordern eines Tokens bei ACS mithilfe des OAuth-WRAP-Protokolls

Tokenanforderungsverfahren Beschreibung

Kennworttokenanforderungen

Für dieses einfachste Verfahren muss der Client einen Benutzernamen und ein Kennwort von einem Dienst direkt über das OAuth-WRAP-Protokoll zur Authentifizierung an ACS senden.

SWT-Tokenanforderungen

Für dieses Verfahren muss der Client ein SWT-Token, das mit dem symmetrischen Schlüssel einer Dienstidentität oder eines Identitätsanbieters signiert sein kann, über das OAuth-WRAP-Protokoll zur Authentifizierung an ACS senden.

SAML-Tokenanforderungen

In erster Linie für Zwecke der AD FS 2.0-Integration (Active Directory Federation Service) vorgesehen, erfordert das SAML-Verfahren (Security Assertion Markup Language), dass der Client ein signiertes SAML-Token mithilfe des OAuth-WRAP-Protokolls zur Authentifizierung an ACS sendet. Dieser Ansatz ermöglicht es dem Client, eine Unternehmensidentität für die Authentifizierung bei ACS zu verwenden.

Alle ACS-Tokenanforderungen über das OAuth-WRAP-Protokoll werden an einen Token ausgebenden ACS-Endpunkt gesendet. Der URI dieses Endpunkts hängt vom Namespace für die Zugriffssteuerung ab. Der Namespace erscheint im URI von Tokenanforderungen als DNS-Namenspräfix. Der Rest des DNS-Namens ist fest, ebenso der Pfad. ○Wenn Sie z. B ein Token mit dem Namen "meinsnservice" beim Namespace für die Zugriffssteuerung anfordern möchten, können Sie eine Tokenanforderung an den folgenden URI richten: https://meinsnservice.accesscontrol.windows.net/WRAPv0.9.

Mit einer Kennworttokenanforderung kann ein Client einen Benutzernamen und ein Kennwort von einer Dienstidentität direkt über das OAuth-WRAP-Protokoll zur Authentifizierung an ACS senden. Dies ist die einfachste Möglichkeit zum Anfordern eines Tokens bei ACS über das OAuth WRAP-Protokoll. Im Gegensatz zum Einrichten einer SSL-Verbindung erfordert dieser Ansatz keine Kryptografiefähigkeit. Praktisch ähnelt es dem Modell von Benutzername/Kennwort, das in REST-Webdiensten vorherrschend ist. Diese Art Tokenanforderung stellt tatsächlich einen HTTPS-Formular-POST dar. Die Parameter in einer Kennworttokenanforderung sind formularcodiert.

Das folgende Beispiel ist eine Skizze für eine Klartextanforderung an einen Namespace mit dem Namen "meinsnservice".

POST /WRAPv0.9/ HTTP/1.1
Host: mysnservice.accesscontrol.windows.net
Content-Type: application/x-www-form-urlencoded

wrap_scope=http%3A%2F%2Fmysnservice.com%2Fservices%2F&
wrap_name=mysncustomer1&
wrap_password=5znwNTZDYC39dqhFOTDtnaikd1hiuRa4XaAj3Y9kJhQ%3D

Die Tabelle unten enthält die Namen, Beschreibungen und erforderlichen Parameterwerte, die in einer Kennworttokenanforderung vorhanden sein müssen:

 

Parametername Beschreibung Wertanforderungen

wrap_scope

Ordnet die Tokenanforderung anhand einer Menge von Regeln zu. Legen Sie den Wert dieses Parameters auf den Wert des Bereichs der Anwendung der vertrauenden Seite fest. Sie können diesen Wert (im Feld Bereich) über das ACS-Verwaltungsportal abrufen, indem Sie auf der Seite Anwendungen der vertrauenden Seite die entsprechende Anwendung der vertrauenden Seite auswählen.

  • HTTP oder HTTP(s)-URI

  • Keine Abfrageparameter oder Anker.

  • Pfadsegmente <= 32.

  • Maximale Länge: 256 Zeichen.

  • Muss URL-codiert sein.

wrap_name

Überprüft den Schlüssel des nächsten Parameters. Legen Sie den Wert dieses Parameters auf den Namen einer Dienstidentität in Ihrem Namespace für die Zugriffssteuerung fest. Sie können diesen Wert (in Feld Name) über das ACS-Verwaltungsportal abrufen, indem Sie die entsprechende Dienstidentität auf der Seite Dienstidentitäten auswählen.

  • Minimale Länge: 1 Zeichen.

  • Maximale Länge: 128 Zeichen.

  • Muss URL-codiert sein.

wrap_password

Authentifiziert die eingehende Anforderung. Legen Sie den Wert dieses Parameters auf das Kennwort einer Dienstidentität in Ihrem Namespace für die Zugriffssteuerung fest. Sie können diesen Wert (im Feld Kennwort auf der Seite Anmeldeinformationen bearbeiten) über das ACS-Verwaltungsportal abrufen, indem Sie zuerst die entsprechende Dienstidentität auf der Seite Dienstidentitäten und anschließend das passende Kennwort in der Tabelle Anmeldeinformationen auf der Seite Dienstidentität bearbeiten auswählen.

  • Zeichenfolge, minimale Länge 1 und maximale Länge 64 Zeichen.

  • Muss URL-codiert sein.

Die Werte dieser Parameter müssen URL-codiert werden, bevor Sie die Anforderung an ACS senden. Ihre Webanwendung oder Ihr Webdienst kann den Wert von wrap_scope an den Client übergeben, oder der Client kann sich entscheiden, den Wert des Parameters wrap_scope auf den URI des Ressourcenziels der Webanwendung oder des Webdiensts festzulegen.

Kennworttokenanforderungen über das OAuth-WRAP-Protokoll können außerdem weitere Parameter enthalten, die ACS während des Berechnungsvorgangs des Ausgabeanspruchs verwenden kann. Die Namen und Werte dieser zusätzlichen Parameter müssen URL-codiert sein und die Werte dürfen nicht in Anführung stehen.

Das Kennworttokenanforderungs-Verfahren ist ziemliche geradlinig in seiner Verwendung von .

WebClient client = new WebClient();
client.BaseAddress = string.Format("https://mysnservice.accesscontrol.windows.net");

NameValueCollection values = new NameValueCollection();
values.Add("wrap_name", "mysncustomer1");
values.Add("wrap_password", "5znwNTZDYC39dqhFOTDtnaikd1hiuRa4XaAj3Y9kJhQ=");
values.Add("wrap_scope", "http://mysnservice.com/services");

// WebClient takes care of the URL Encoding
byte[] responseBytes = client.UploadValues("WRAPv0.9", "POST", values);

// the raw response from ACS
string response = Encoding.UTF8.GetString(responseBytes);

Informationen, wie das Ausgabetoken aus ACS ausgepackt und an die Webanwendung oder den Webdienst gesendet wird, finden Sie unter Unwrapping and sending the token to a web application or service.

Sie können außerdem über das OAuth-WRAP-Protokoll mithilfe eines SWT-Tokens, das mit einem symmetrischen Schlüssel signiert ist, ein Token bei ACS anfordern. Alle SWT-Tokenanforderungen erfolgen mittels eines HTTPS-Formular-POSTs. Die Parameterwerte in dieser Tokenanforderungsmethode sind formularcodiert.

Das Folgendes ist ein Beispiel einer Ablaufverfolgung einer SWT-Tokenanforderung mit dem Namespace "meinsnservice" über das Netzwerk.

POST /WRAPv0.9/ HTTP/1.1
Host: mysnservice.accesscontrol.windows.net
Content-Type: application/x-www-form-urlencoded

wrap_scope=http%3A%2F%2Fmysnservice.com%2Fservices%2F&
wrap_assertion_format=SWT&
wrap_assertion=Issuer%3dmysncustomer1%26HMACSHA256%3db%252f%252bJFwbngGdufECFjQb8qhb9YH0e32Cf9ABMDZFiPPA%253d

Eine SWT-Tokenanforderung muss die folgenden Parameter und Werte aufweisen:

 

Parametername Beschreibung Wertanforderungen

wrap_scope

Ordnet die Tokenanforderung anhand einer Menge von Regeln zu.

  • Legen Sie den Wert dieses Parameters auf den Wert des Bereichs der Anwendung der vertrauenden Seite fest. Sie können diesen Wert (im Feld Bereich) über das ACS-Verwaltungsportal abrufen, indem Sie auf der Seite Anwendungen der vertrauenden Seite die entsprechende Anwendung der vertrauenden Seite auswählen.

  • HTTP oder HTTP(s)-URI

  • Keine Abfrageparameter oder Anker.

  • Pfadsegmente <= 32.

  • Maximale Länge: 256 Zeichen.

  • Muss URL-codiert sein.

wrap_assertion

Dies ist das Eingabetoken, das an ACS gesendet wird.

  • Ein signiertes SWT-Token mit Eingabeansprüchen, die Aussteller- und HMACSHA256-Parameter enthalten.

  • Maximale Länge: 2048 Zeichen.

  • Muss URL-codiert sein.

wrap_assertion_format

Dies ist das Format des Eingabetokens, das an ACS gesendet wird.

SWT

Wie im folgenden Beispiel gezeigt, ähnelt der Code, der erforderlich ist, um eine SWT-Tokenanforderung zu stellen, dem Code, der für eine Kennworttokenanforderung erforderlich ist.

WebClient client = new WebClient();
client.BaseAddress = string.Format("https://mysnservice.accesscontrol.windows.net");

NameValueCollection values = new NameValueCollection();
// add the wrap_scope
values.Add("wrap_scope", "http://mysnservice.com/services");
// add the format
values.Add("wrap_assertion_format", "SWT");
// add the SWT
values.Add("wrap_assertion", "Issuer=mysncustomer1&HMACSHA256=b%2f%2bJFwbngGdufECFjQb8qhb9YH0e32Cf9ABMDZFiPPA%3d");
// WebClient takes care of the remaining URL Encoding
byte[] responseBytes = client.UploadValues("WRAPv0.9", "POST", values);

// the raw response from ACS
string response = Encoding.UTF8.GetString(responseBytes);

Informationen, wie die Antwort aus ACS ausgepackt und an die Webanwendung oder den Webdienst gesendet wird, finden Sie unter Unwrapping and sending the token to a web application or service.

Ein SWT-Token ist ein Satz von Schlüssel/Wert-Paaren, die mit einem Ausstellerschlüssel (einen symmetrischen Schlüssel) signiert werden. Ein in einer SWT-Tokenanforderung an ACS gesendetes SWT-Token muss die Parameter Issuer und HMACSHA256 sowie weitere Parameter enthalten, z. B. ExpiresOn, Audience und weitere clientspezifische Ansprüche. Die folgende Tabelle enthält die Namen und Beschreibungen von SWT-Tokenparametern:

 

Parametername Beschreibung

Issuer

Sucht in ACS den Schlüssel, der zum Signieren des Tokens verwendet wurde. Wenn die Signatur gültig ist, wird dieser Wert verwendet, um die Berechnung des Ausgabeanspruchs durchzuführen.

Sie können diesen Parameter auf den Wert des Bereichs eines Identitätsanbieters in Ihrem Namespace für die Zugriffssteuerung oder auf den Namen einer Dienstidentität in ihrem Namespace für die Zugriffssteuerung festlegen. Sie können diesen Wert (im Feld Bereich auf der Seite Identitätsanbieter bearbeiten) über das ACS-Verwaltungsportal abrufen, indem Sie den entsprechenden Identitätsanbieter auf der Seite "Identitätsanbieter" auswählen. Alternativ können Sie diesen Wert über den ACS-Verwaltungsdienst abrufen – hier ist es die Nameneigenschaft des Ausstellerdatensatzes, der für jeden Identitätsanbieter erstellt wird.

HMACSHA256

Überprüft in ACS die SWT-Signatur und schlägt den im Parameter Issuer genannten Ausstellerschlüssel nach.

Die SWT-Signatur wird mithilfe des symmetrischen Signaturschlüssels erstellt, der an eine Dienstidentität oder einen Identitätsanbieter in Ihrem Namespace für die Zugriffssteuerung angefügt ist.

Zielgruppe

Wenn er vorhanden ist, verwendet ACS diesen Wert, um sicherzustellen, dass ACS das beabsichtigte Ziel des SWT-Tokens ist. Dies ist die URL Ihres Namespace für die Zugriffssteuerung, z. B. "https://contoso.accesscontrol.windows.net/"

ExpiresOn

Gibt falls vorhanden (in Epochenzeit) an, ob das Token abgelaufen ist. Beispielsweise kann der Wert dieses Parameters 1324300962 sein.

Zusätzliche Ansprüche

Falls vorhanden, verwendet ACS diese Parameter bei der Berechnung des Ausgabeanspruchs. Jeder Anspruchstyp darf nur ein Mal vorkommen. Mehrere Anspruchswerte des gleichen Anspruchstyps müssen mit einem Komma (",") verkettet werden. Weitere Informationen zur Bestätigung von Ansprüchen in ACS finden Sie unter Anspruchsbestätigung mithilfe des OAuth-WRAP-Protokolls.

Das folgende Codebeispiel zeigt, wie ein SWT-Token mithilfe von erstellt wird. Es enthält einen Typ, der SWT-Token erstellt, die die Parameter Issuer und HMACSHA256 enthalten.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Security.Cryptography;
using System.Text;
using System.Web;

public class TokenFactory
{
    string signingKey;   
    string issuer;
    
    public TokenFactory(string issuer, string signingKey)
    {
        this.issuer = issuer;
        this.signingKey = signingKey;
    }

    public string CreateToken()
    {
        StringBuilder builder = new StringBuilder();

        // add the issuer name
        builder.Append("Issuer=");
        builder.Append(HttpUtility.UrlEncode(this.issuer));

        string signature = this.GenerateSignature(builder.ToString(), this.signingKey);
        builder.Append("&HMACSHA256=");
        builder.Append(signature);

        return builder.ToString();
    }

   
    private string GenerateSignature(string unsignedToken, string signingKey)
    {
        HMACSHA256 hmac = new HMACSHA256(Convert.FromBase64String(signingKey));

        byte[] locallyGeneratedSignatureInBytes = hmac.ComputeHash(Encoding.ASCII.GetBytes(unsignedToken));

        string locallyGeneratedSignature = HttpUtility.UrlEncode(Convert.ToBase64String(locallyGeneratedSignatureInBytes));

        return locallyGeneratedSignature;
    }
}

Das SAML-Tokenanforderungsverfahren ist im Wesentlichen für die AD FS 2.0-Integration vorgesehen und ermöglicht dem Client die Verwendung einer Unternehmensidentität (Active Directory) für die Authentifizierung bei ACS. Mit dem SAML-Tokenanforderungsverfahren können Sie ein von AD FS 2.0 ausgestelltes signiertes SAML 1.1- oder SAML 2.0-Token (Eingabetoken) über das OAuth-WRAP-Protokoll an ACS senden.

ACS verwendet seine Regeln, um die Ausgabeansprüche zu berechnen, gruppiert sie in einem SWT-Token (Ausgabetoken), signiert es und schickt es über das OAuth-WRAP-Protokoll an den Client zurück.

Eine SAML-Tokenanforderung muss die folgenden Parameter und Werte aufweisen:

 

Parametername Beschreibung Wertanforderungen

wrap_scope

Ordnet die Tokenanforderung anhand einer Menge von Regeln zu.

  • Legen Sie den Wert dieses Parameters auf den Wert des Bereichs der Anwendung der vertrauenden Seite fest. Sie können diesen Wert (im Feld Bereich) über das ACS-Verwaltungsportal abrufen, indem Sie auf der Seite Anwendungen der vertrauenden Seite die entsprechende Anwendung der vertrauenden Seite auswählen.

  • HTTP oder HTTP(s)-URI

  • Keine Abfrageparameter oder Anker.

  • Pfadsegmente <= 32.

  • Maximale Länge: 256 Zeichen.

  • Muss URL-codiert sein.

wrap_assertion

Dies ist das Eingabetoken, das an ACS gesendet wird.

  • Ein signiertes SAML 1.1- oder 2.0-Token mit Eingabeansprüchen. SAML 1.1-Tokens erfordern als Einschränkung des Tokens mindestens einen Eingabeanspruch. Das bedeutet, dass entweder ein Identitätsanbieter oder eine anspruchsfähige Dienstidentität für die SAML 1.1-Tokenauthentifizierung verwendet werden muss. SAML 2.0-Token erfordern keine Eingabeansprüche für die Authentifizierung bei einer Dienstidentität, abgesehen von impliziten "NameIdentifier"-Anspruch, daher können SAML 2.0-Token für die Authentifizierung bei einer normalen, nicht anspruchsfähigen Dienstidentität verwendet werden.

  • Muss URL-codiert sein.

wrap_assertion_format

Dies ist das Format des Eingabetokens, das an ACS gesendet wird.

SAML

Folgendes ist ein Beispiel für den Code, der für SAML-Tokenanforderungen erforderlich ist.

private static string SendSAMLTokenToACS(string samlToken)
{
 try
 {
  WebClient client = new WebClient();
  client.BaseAddress = string.Format("https://mysnservice.accesscontrol.windows.net");
  NameValueCollection parameters = new NameValueCollection();
  parameters.Add("wrap_assertion_format", "SAML");
  parameters.Add("wrap_assertion", samlToken);
  parameters.Add("wrap_scope", "http://mysnservice.com/services");

  byte[] responseBytes = client.UploadValues("WRAPv0.9", parameters);
  string response = Encoding.UTF8.GetString(responseBytes);

  return response
   .Split('&')
   .Single(value => value.StartsWith("wrap_access_token=", StringComparison.OrdinalIgnoreCase))
   .Split('=')[1];
 }
 catch (WebException wex)
 {
  string value = new StreamReader(wex.Response.GetResponseStream()).ReadToEnd();
  throw;
 }
}  

Informationen, wie die Antwort von ACS ausgepackt und an die Webanwendung oder den Webdienst gesendet wird, finden Sie unter Entpacken und Senden des Tokens an eine Webanwendung oder einen Webdienst.

Um Abwärtskompatibilität mit dem Verhalten von ACS 1.0-Tokenanforderungen zu ermöglichen, unterstützt ACS die Möglichkeit, Ansprüche als Teil von Tokenanforderungen zu bestätigen.

Das empfohlene Verfahren besteht darin die bestätigende Anwendung oder den bestätigenden Dienst als ACS-Identitätsanbieter zu registrieren. Die Anwendung oder der Dienst fordert dann ein Token bei ACS an, indem ein SAML- oder SWT-Token übergeben wird, das die zu bestätigenden Ansprüche enthält, und dieses Token wird mithilfe eines in ACS gespeicherten Identitätsanbieterschlüssels signiert. Beispielsweise können Sie eine SAML-Tokenanforderung mit bestätigten Ansprüchen über das OAuth-WRAP-Protokoll von AD FS 2.0 oder einem beliebigen benutzerdefinierten STS (Security Token Service), der mithilfe von WIF (Windows Identity Foundation) erstellt und in ACS als WS-Verbundidentitätsanbieter registriert wurde, an ACS senden.

Sie können das ACS-Verwaltungsportal verwenden, um einen Identitätsanbieter mithilfe von WS-Verbundmetadaten zu registrieren, oder Sie können den ACS-Verwaltungsdienst verwenden, um individuell Eigenschaften, Adressen und Schlüssel von Identitätsanbietern festzulegen. (Ein Beispiel finden Sie unter Vorgehensweise: Verwenden des ACS-Verwaltungsdiensts zum Konfigurieren von AD FS 2.0 als Unternehmensidentitätsanbieter.) Bei diesem Verfahren der Bestätigung von Ansprüchen in einer Tokenanforderung werden keine Dienstidentitäten benötigt. Diese Methode funktioniert mit allen von ACS unterstützten Protokollen.

Wenn die Tokenanforderung erfolgreich authentifiziert wurde, gibt ACS zwei formularcodierte Parameter zurück: wrap_token und wrap_token_expires_in. Die Werte dieser Parameter sind das eigentliche SWT-Token, das der Client verwenden kann, um Zugriff auf Ihre Webanwendung oder Ihren Webdienst zu erhalten, und die ungefähre verbleibende Lebensdauer in Sekunden.

Vor dem Senden des SWT-Tokens an die Webanwendung oder den Webdienst muss der Client es aus der ACS-Antwort extrahieren und URL-decodieren. Wenn die Webanwendung oder der Webdienst die Übergabe des Tokens im Authorization-Header erfordert, muss dem Token das WRAPv0.9-Schema vorangestellt sein.

Das folgende Codebeispiel veranschaulicht, wie ein Token entpackt und der Authorization-Header formatiert wird.

WebClient client = new WebClient();
client.BaseAddress = string.Format("https://mysnservice.accesscontrol.windows.net");

NameValueCollection values = new NameValueCollection();
values.Add("wrap_name", "mysncustomer1");
values.Add("wrap_password", "5znwNTZDYC39dqhFOTDtnaikd1hiuRa4XaAj3Y9kJhQ=");
values.Add("wrap_scope", "http://mysnservice.com/services");

// WebClient takes care of the URL Encoding
byte[] responseBytes = client.UploadValues("WRAPv0.9", "POST", values);

// the raw response from ACS
string response = Encoding.UTF8.GetString(responseBytes);

string token = response
    .Split('&')
    .Single(value => value.StartsWith("wrap_token=", StringComparison.OrdinalIgnoreCase))
    .Split('=')[1];

string.Format("WRAP access_token=\"{0}\"", HttpUtility.UrlDecode(token));

ACS gibt Fehler zurück, wenn eine Tokenanforderung nicht bedient werden kann. In Übereinstimmung mit dem REST-Entwurf enthält der Fehler einen HTTP-Antwortcode. In vielen Fällen enthalten ACS-Fehler außerdem einen SubCode und Detail, die Kontext zum Fehler angeben. Das Format von Fehlern ist: Fehler:Code:<httpStatus>:Subcode:<code>:Detail:<Nachricht>. Der Content-Type eines Fehlers ist immer Text/unformatiert.

HTTP/1.1 401 Access Forbidden
Content-Type: text/plain; charset=us-ascii

Error:Code:401:SubCode:T0:Detail:ACS50009: SWT token is invalid. :TraceID:<trace id value>:TimeStamp:<timestamp value>

Weitere Informationen zu ACS-Fehlercodes finden Sie unter ACS-Fehlercodes.

Beim Debuggen oder Wiederherstellen nach einem von ACS zurückgegebenen Fehler ist es oftmals erforderlich, den Text der Antwort zu lesen. Das folgende Codebeispiel zeigt, wie die Fehlermeldung von einem WebException-Objekt zu lesen ist.

try
{
    WebClient client = new WebClient();
    client.BaseAddress = string.Format("https://mysnservice.accesscontrol.windows.net");

    NameValueCollection values = new NameValueCollection();
    values.Add("wrap_name", "mysncustomer1");
    values.Add("wrap_password", "5znwNTZDYC39dqhFOTDtnaikd1hiuRa4XaAj3Y9kJhQ=");
    values.Add("wrap_scope", "http://mysnservice.com/services");

    // WebClient takes care of the URL Encoding
    byte[] responseBytes = client.UploadValues("WRAPv0.9", "POST", values);

    // the raw response from ACS
    string response = Encoding.UTF8.GetString(responseBytes);

    string token = response
        .Split('&')
        .Single(value => value.StartsWith("wrap_access_token=",       StringComparison.OrdinalIgnoreCase))
        .Split('=')[1];
}
catch (WebException wex)
{
    if (wex.Response != null)
    {
        // the response Stream contains the error message
        StreamReader reader = new StreamReader(wex.Response.GetResponseStream());
        string message = reader.ReadToEnd();
    }
    // Throw as appropriate
}

Siehe auch

Community-Beiträge

Anzeigen:
© 2015 Microsoft