Wie kann ich mich nur einmal mithilfe von Clientanmeldeinformationen in WCF authentifizieren?

Question

Was ist der beste Ansatz, um sicherzustellen, dass Sie nur einmal authentifizieren müssen, wenn Sie eine API verwenden, die auf WCF basiert?

Meine aktuellen Bindungen und Verhaltensweisen sind im Folgenden aufgeführt

<bindings> 
     <wsHttpBinding> 
      <binding name="wsHttp"> 
       <security mode="TransportWithMessageCredential"> 
        <transport/> 
        <message clientCredentialType="UserName" negotiateServiceCredential="false" establishSecurityContext="true"/> 
       </security> 
      </binding> 
     </wsHttpBinding> 
    </bindings> 
    <behaviors> 
     <serviceBehaviors> 
      <behavior name="NorthwindBehavior"> 
       <serviceMetadata httpGetEnabled="true"/> 
       <serviceAuthorization principalPermissionMode="UseAspNetRoles"/> 
       <serviceCredentials> 
        <userNameAuthentication userNamePasswordValidationMode="MembershipProvider"/> 
       </serviceCredentials> 
      </behavior> 
     </serviceBehaviors> 
    </behaviors> 

Als nächstes ist das, was ich in meiner Client-Anwendung bin mit zu authentifizieren (derzeit muß ich diese jedes Mal will ich einen Anruf in WCF machen)

Dim client As ProductServiceClient = New ProductServiceClient("wsHttpProductService") 
client.ClientCredentials.UserName.UserName = "foo" 
client.ClientCredentials.UserName.Password = "bar" 
Dim ProductList As List(Of Product) = client.GetProducts() 

Was ich tun möchte, ist auth w/API einmal mit diesen Anmeldeinformationen, dann erhalten Sie eine Art von Token für den Zeitraum, in dem meine Client-Anwendung das Web-Service-Projekt verwendet. Ich dachte, seethsecuritycontext = true hat das für mich getan?

Answer 1

Wenn Sie sich in einem Intranet befinden, kann die Windows-Authentifizierung von der Konfiguration allein als "frei" behandelt werden.

Wenn dies nicht angemessen ist, funktionieren Token-Dienste problemlos, aber in manchen Situationen sind sie einfach zu viel.

Die Anwendung, an der ich arbeite, benötigte eine reine Authentifizierung. Unser Server und unser Client laufen innerhalb eines (sehr sicheren) Intranets. Daher war es uns nicht sonderlich wichtig, ein X.509-Zertifikat zu verwenden, um die Kommunikation zu verschlüsseln. Dies ist erforderlich, wenn Sie die Authentifizierung des Benutzernamens verwenden.

So fügten wir dem Client einen custom behavior hinzu, der den Nachrichtenheadern den Benutzernamen und das (verschlüsselte) Kennwort hinzufügt, und ein anderes benutzerdefiniertes Verhalten auf dem Server, der sie überprüft.

Alles sehr einfach, erfordert keine Änderungen an der Client-Seite Service Access Layer oder die Servicevertrags-Implementierung. Und wenn alles durch die Konfiguration erledigt ist, und wenn wir etwas stärker werden müssen, ist es einfach zu migrieren.

Answer 2

Während ich hasse, eine Antwort zu geben, bin ich nicht 100% sicher, der Mangel an Antworten macht mich bisher denken, dass eine potentiell richtige Antwort in diesem Fall okay sein könnte.

Soweit ich weiß, gibt es nicht die Art von Session-Token-Mechanismus, den Sie mit WCF out-of-the-box suchen, was bedeutet, dass Sie einige schwere heben müssen, um zu bekommen Dinge arbeiten so, wie du willst. Ich sollte klarstellen, dass es in WCF einen Sitzungsmechanismus gibt, aber es konzentriert sich darauf, Nachrichtenaufträge zu garantieren und ist nicht das ideale Werkzeug zum Erstellen einer Authentifizierungssitzung.

Ich habe gerade mit der Arbeit an einem Projekt abgeschlossen, in dem wir einen eigenen Session-Mechanismus zur Verarbeitung aller möglichen SOAP-Stacks implementiert haben. Ich glaube jedoch, dass die Verwendung von Secure Token Service (STS) wie Pablo Cibraro's empfohlen wird.

Wenn Sie weitere Details wünschen, rufen Sie bitte, aber ich vermute, Pablos Blog wird mehr als genug Informationen für Sie haben, um voranzukommen.