Wie kann ich einen WCF Service bereitstellen, der eine Userauthentifizierung (UserName, Password) voraussetzt?
Wenn ich die meisten Beispiele sehe, dann wird ein Zertifikat vorausgesetzt. Muss ich zwingend eins installieren, oder reicht eine SSL Verbindung aus? Wenn die SSL Verbindung ausreicht, wie gehe ich hier vor, was muss ich beachten?
Wer hat Quellen, die eben nicht nur ein halbes Beispiel zeigen, bzw. Beispiele wo auch die Herangehensweise erklärt wird. Am besten auch, wo derjenige schon mit gearbeitet und es halt zu 100% weiß, das dieses funktioniert.
wenn du mit SSL arbeitest, ist ein Zertifikat zwingend. Der Artikel WCF Service with custom username password authentication auf CodeProject ist gut gelungen. Du kannst die Zertifikate auch via makecert erstellen, wenn du das angesprochene Tool nicht verwenden willst. Über WCF mit Zertifikaten findet man an sich eine ganze Menge.
Hast du für dein Vorhaben weitere Details? Hier ein paar Stichpunkte, wobei ich gleich dazu schreiben kann, womit ich bereits Erfahrungen gesammelt habe: Handelt es sich um eine lokale Anmeldung (A), z.B. an eine Datenbank oder geht es um eine allgemeine Benutzerauthentifizierung (B)? Zu (B) (keine Erfahrung): Hier gäbe es MS-CardSpace oder das populärere OpenID. Zu (A): Handelt es sich um SOAP (C) oder REST (D)? Zu (C) (Erfahrung): Hier kannst du den AuthHeader (System.Web.Services.Protocols.SoapHeader) verwenden, um Benutzerinformationen zu übertragen. Hierbei wird der Header einmal gesetzt und im Soap-Envelope bei jeder Anfrage an den Server übertragen. Siehe auch: Authentication for Web Services (using SOAP headers) Zu (D) (Erfahrung): Hier verzichte ich einfach auf http-get und verwende nur http-post. Als Objekt wird zusätzlich zu den sonstigen Parametern der Benutzer und das Passwort übertragen. Mir ist bewusst, dass ich die http-Methoden nicht so verwende, wie sie gedacht sind, aber es funktioniert sehr einfach und effektiv. Es gibt noch weitere Möglichkeiten, von denen ich gehört und wieder vergessen habe ;o) Weitere Ergänzungen: Wie ich hier schon schrieb Was und wie verschlüsseln, verschlüssel ich das Passwort mit AES. Zudem wird dem Kunden dringend empfohlen SSL zu verwenden, sonst sind seine Daten nicht sicher. Die Verschlüsselung des Passworts dient lediglich dazu, dass sie in der Datenbank nicht lesbar sind. Um Service-Methoden auzuführen ist das Passwort im Klartext nicht nötig. Es reicht das Token mitzulesen, um an die Services zu kommen. Daher ist SSL ein muss. Zu SSL: Du brauchst ein Zertifikat, das auf deinem Server liegt und zur Vorgehensweise: Die URI bekommt ein "s" hinter dem http ;o) An der Programmierung ändert sich nichts.
Edit: Zu deinen Infos im Kommentar: Bei der Kombination A und C ist es sehr einfach: Im Soap-Header werden alle relevanten Infos verpackt. Du kannst auch noch weitere Infos wie z.B. einen Datenbankalias oder einen Connectionstring mitgeben, wenn die Datenbank im Serverpart nicht konstant ist. Dazu SSL und das wars.
Wow +1, so hab ich mir das vorgestellt. Bei mir tritt A und C zu. btw "SSL ohne Zertifikat..." ich hätte mal vor meine Fragestellung kurz nachdenken sollen :) Ich werde mir diesbezüglich morgen einige Beispiel nochmal zu Gemüte ziehen. Soweit danke ich erstmal!
Kleine Ergänzung: soweit ich sehe, nutzt das Beispiel von codeproject aus Khalids Antwort einen eigenen Service, um User/Password zu prüfen. Eine Alternative, insbesondere wenn die User-Daten in einer Datenbank liegen, die der Server direkt ansprechen kann, ist die Nutzung eines ASP.NET Membership Providers (ja, geht auch für WCF). Dazu gibt es ein Beispiel auf MSDN. Das prinzipielle Vorgehen ist ansonsten wie in dem codeproject-Beispiel.
Vorteil aus meiner Sicht: wenn Du parallel auch noch eine ASP.NET-Seite absichern mußt und dabei die gleiche User-Datenbank benutzt wird, hast Du ein paar Synergien.
Leider kann ich das Funktionieren nicht aus eigener Erfahrung bestätigen - habe bislang immer NTLM/Kerberos genutzt.
Übrigens, falls Du mehr mit WCF vorhast: Sehr empfehlen kann ich das Buch "Programming WCF Services" von Juval Löwy.