Selbst gehostete WCF-REST-service und Basic Authentifizierung

Ich habe eine selbst gehostete WCF-REST-Dienst (mit einigen extra ' s von WCF REST Starter Kit Preview 2). Dies ist alle wunderbar funktioniert.

Ich bin jetzt versuchen, fügen Sie " Basic authentication service. Aber ich bin man ein paar ziemlich große Hürden in den WCF-stack-was hindert mich daran, dies zu tun.

Scheint es, dass die HttpListener (die selbst gehostete WCF-Dienste verwenden intern auf einem niedrigen Niveau in den WCF-stack) blockiert meine versuche, Sie zum einfügen eines WWW-Authenticate header selbst generiert 401 Unauthorized Antwort. Warum?

Ich kann die Authentifizierung funktioniert, wenn ich es nicht vergesse über dieses WWW-Authenticate header (was es scheint, Microsoft hat den auch). Aber das ist das Problem. Wenn ich nicht senden Sie zurück WWW-Authenticate header der web-browser zeigt auch nicht seine standard - "Anmeldung" - dialog. Der Benutzer wird lediglich vor 401 Unauthorized Fehler-Seite mit keinen Weg, um tatsächlich anmelden.

REST-services zugänglich sein sollten, um beide Computer und Mensch (naja zumindest auf den GET-request level). Deshalb habe ich das Gefühl, dass WCF REST ist nicht die Einhaltung grundlegender Bestandteil der REST hier. Hat jemand mit mir einverstanden?

Hat jemand Basic-Authentifizierung funktioniert mit einem selbst-gehosteten WCF REST service? Wenn ja, wie haben Sie es tun?

PS: Natürlich sind meine Absichten zu nutzen unsicheren Basic-Authentifizierung sind auf der Prämisse, dass ich auch bekommen, HTTPS/SSL arbeiten für meinen Dienst. Aber das ist eine andere Sache.

PPS: ich habe versucht, WCF REST-Contrib (http://wcfrestcontrib.codeplex.com/) und das hat genau das gleiche Problem. Es scheint, dass diese Bibliothek wurde nicht getestet, in der self-hosted-Szenarien.

Dank.

InformationsquelleAutor nbevans | 2010-02-04

13

Leider habe ich festgestellt (durch die Analyse der WCF Referenz-source-code und die Hilfe, die von den Fiddler-tool für die HTTP-Sitzung sniffing), dass dies ein bug in der WCF-stack.

Mit Fiddler, bemerkte ich, dass mein WCF-Dienst sich im Gegensatz zu allen anderen web site, die Standardauthentifizierung verwendet.

Klar zu sein, was geschehen SOLLTE:
1. Browser sendet GET Anfrage ohne Kenntnis, dass ein Passwort wird auch benötigt.
2. Web-server lehnt die Anfrage mit einem 401 Unauthorized status und umfasst einen WWW-Authenticate header mit Informationen über die akzeptierten Authentifizierungsverfahren.
3. Browser fordert Benutzer zur Eingabe der Anmeldeinformationen.
4. Browser sendet GET Anfrage und beinhaltet die entsprechenden Authentication header mit den Anmeldeinformationen.
5. Wenn die Zugangsdaten korrekt waren, wird der web-server antwortet mit 200 OK und der web-Seite.
  Wenn Sie die Anmeldeinformationen falsch waren, der web-server antwortet mit 401 Unauthorized und beinhaltet die gleichen WWW-Authenticate header, der in Schritt #2.
Was war EIGENTLICH passiert mit meinem WCF-service war:
1. Browser sendet GET Anfrage ohne Kenntnis, dass ein Passwort wird auch benötigt.
2. WCF verstoßen es gibt keine Authentication - header in der Anforderung und blind lehnt die Anfrage mit einem 401 Unauthorized status und umfasst einen WWW-Authenticate header. Alles normal so weit.
3. Browser fordert Benutzer zur Eingabe der Anmeldeinformationen. Noch normal.
4. Browser sendet GET Antrags einschließlich der entsprechenden Authentication header.
5. Wenn die Zugangsdaten korrekt waren, wird der web-server antwortet mit 200 OK. Alles ist in Ordnung.
  Wenn Sie die Anmeldeinformationen falsch waren allerdings WCF reagiert mit 403 Forbidden und keine zusätzlichen Header wie WWW-Authenticate.
Wenn der browser erhält die 403 Forbidden status es nicht wahrnimmt, einem fehlgeschlagenen Authentifizierungsversuch. Dieser status-code ist bestimmt der browser die Information, dass die URL, die Sie zugreifen wollten, ist off limits. Es nicht beziehen sich auf die Authentifizierung in keiner Weise. Dieses hat die schreckliche Seite beeinflussen, wenn der Benutzer gibt seinen Benutzernamen/Passwort falsch (und der server lehnt mit 403), dann wird der web-browser nicht reprompt den Benutzer zur Eingabe Ihrer Anmeldeinformationen erneut eingeben. In der Tat, der web-browser-Ansicht-Authentifizierung ist gelungen und so werden die Anmeldeinformationen für den rest der session!

Mit diesem im Verstand, ich bat um Klärung:

RFC 2617 (http://www.faqs.org/rfcs/rfc2617.html#ixzz0eboUfnrl) erwähnt nicht überall die Verwendung des 403 Forbidden status-code. In der Tat, was es eigentlich zu sagen hat, auf die Sache ist folgende:

Wenn der origin-server nicht wollen
akzeptieren Sie die Anmeldeinformationen gesendet mit
Anfrage, SOLLTE es wieder einen 401
(Unauthorized) response. Die Antwort
MUSS eine WWW-Authenticate-header
Feld mit mindestens einem
(möglicherweise neuen) Herausforderung anwendbar
die angeforderte Ressource.

WCF weder eine von diesen. Es weder richtig sendet eine 401 Unauthorized status-code. Noch ist es eine WWW-Authenticate header.

Nun zu finden, die smoking gun in den WCF-source-code:

Entdeckt, dass ich in der HttpRequestContext Klasse wird eine Methode namens ProcessAuthentication, die Folgendes enthält (Auszug):
```
if (!authenticationSucceeded) 
{
   SendResponseAndClose(HttpStatusCode.Forbidden);
}
```
Ich Verteidige Microsoft auf eine Menge Dinge, aber das ist unhaltbar.

Habe ich zum Glück habe es funktioniert, um ein "akzeptable" Niveau. Es bedeutet nur, dass, wenn der Benutzer versehentlich in Ihre Benutzername/Kennwort falsch, dann der einzige Weg, um einen weiteren Versuch, vollständig zu schließen Sie Ihren web-browser und starten Sie es neu, um zu wiederholen. Alle, weil WCF ist nicht Reaktion auf den fehlgeschlagenen Versuch mit einer 401 Unauthorized und ein WWW-Authenticate header gemäß der Spezifikation.
- Zeit zu wechseln, um eine echte http-framework wie openrasta 🙂
- Ich hatte nicht das Herz, ihm zu sagen, dass ich es aufgab zu versuchen zu lösen auth Probleme auf WCF und ging direkt zu HttpListener direkt.
- Prost Jungs 🙂 Darrel, ich habe Ihre Kommentare in ein Gespräch und glauben Sie mir, ich habe in Betracht gezogen, dass als option. Zum Glück haben wir nicht investiert zu viel in WCF REST noch. So wir können gehen Sie voran und Graben es.
InformationsquelleAutor nbevans

Fand ich die Lösung basiert in dieser link und diese.

Das erste ist das überschreiben der Methode zu Validieren, die in einer Klasse namens CustomUserNameValidator wich erbt von System.IdentityModel.Selektoren.UserNamePasswordValidator:

Imports System.IdentityModel.Selectors
Imports System.ServiceModel
Imports System.Net

Public Class CustomUserNameValidator
    Inherits UserNamePasswordValidator

Public Overrides Sub Validate(userName As String, password As String)
    If Nothing = userName OrElse Nothing = password Then
        Throw New ArgumentNullException()
    End If

    If Not (userName = "user" AndAlso password = "password") Then
        Dim exep As New AddressAccessDeniedException("Incorrect user or password")
        exep.Data("HttpStatusCode") = HttpStatusCode.Unauthorized
        Throw exep
    End If
End Sub
End Class

Der trick war, ändern Sie das Attribut von der Ausnahme HttpStatusCode zu HttpStatusCode.Unbefugte

Das zweite ist, wir schaffen das serviceBehavior in der App.config wie folgt:

<behaviors>
  <endpointBehaviors>
    <behavior name="HttpEnableBehavior">
      <webHttp />
    </behavior>
  </endpointBehaviors>
  <serviceBehaviors>
    <behavior name="SimpleServiceBehavior">
      <serviceMetadata httpGetEnabled="true"/>
      <serviceDebug includeExceptionDetailInFaults="false"/>
      <serviceCredentials>
        <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="Service.CustomUserNameValidator, Service"/>
      </serviceCredentials>
    </behavior>
  </serviceBehaviors>
</behaviors>

Schließlich müssen wir angeben, um die Konfiguration für die "webHttpBinding" und wenden Sie es auf dem endpoint:

<bindings>
  <webHttpBinding>
    <binding name="basicAuthBinding">
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Basic" realm=""/>
      </security>
    </binding>
  </webHttpBinding>
</bindings>

<service behaviorConfiguration="SimpleServiceBehavior" name="Service.webService">
    <host>
      <baseAddresses>
        <add baseAddress="http://localhost:8000/webService" />
      </baseAddresses>
    </host>
    <endpoint address="http://localhost:8000/webService/restful" binding="webHttpBinding" bindingConfiguration="basicAuthBinding" contract="Service.IwebService" behaviorConfiguration="HttpEnableBehavior"/>
</service>

InformationsquelleAutor Isaac Hernandez

1

Ja, Sie können die Standardauthentifizierung für REST-basierte WCF-Dienste. Allerdings gibt es mehrere Schritte, die Sie befolgen müssen, um eine komplette und sichere Lösung und bisher die meisten Antworten sind Fragmente der Figuren benötigt.
1. Konfigurieren Sie Ihre self-hosted-service, um ein SSL-Zertifikat an den Anschluss gebunden, die Sie hosten Ihre WCF-service auf. Dies ist ganz anders als die Anwendung einer SSL-cert bei der Verwendung von managed hosting durch so etwas wie IIS. Müssen Sie das SSL-Zertifikat unter Verwendung einer Befehlszeilen-Dienstprogramm. Sie NICHT Standardauthentifizierung verwenden möchten, die auf einen REST service ohne Verwendung von SSL, da die Anmeldeinformationen in der Kopfzeile auf nicht sicher. Hier sind (2) detaillierte Beiträge, die ich schrieb auf genau, wie dies zu tun. Ihre Frage ist zu groß um alle details auf einem forum-post, so dass ist, warum ich die Bereitstellung der links mit umfassenden Informationen und Schritt-für-Schritt Anleitung:
  
  Die Verwendung eines SSL-Zertifikats Mit Einer Selbst-Gehosteten WCF-Dienst
  
  Erstellen eines WCF RESTful-Service Und Sichern Sie Es Mit HTTPS Über SSL
2. Ihren Dienst konfigurieren, um die Standardauthentifizierung verwenden. Dies ist ein multi-Teil-Lösung als gut. 1. ist die Konfiguration Ihres service, die Standardauthentifizierung zu verwenden. Die zweite ist die Schaffung eines 'customUserNamePasswordValidatorType' und überprüfen Sie die Anmeldeinformationen, um authentifizieren den client. Ich sehe den letzten post nicht zu diesem, aber es hat nicht die Verwendung von HTTPS und ist nur 1 sehr kleiner Teil der Lösung sein; seien Sie vorsichtig, der Führung, dass nicht nicht lieferte eine end-to-end-Lösung inklusive Konfiguration und Sicherheit. Der Letzte Schritt ist der Blick auf die security-Kontext die Autorisierung auf der methodenebene, wenn nötig. Den folgenden Beitrag schrieb ich Sie Schritt-für-Schritt, wie Sie konfigurieren, Authentifizierung, und autorisieren Ihre Kunden.
  
  RESTful-Services: Authentifizierung Der Clients Über Basic-Authentication
Dies ist der end-to-end-Lösung erforderlich, für die Verwendung der Standardauthentifizierung mit selbst-gehostete WCF-Dienste.

InformationsquelleAutor atconway

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.