Authentifizierung und Autorisierung von Silverlight Client zu WCF Web-Service

Question

Ich habe eine Situation, wo ich einen Web-Service habe, der Daten (Bilder, Medien usw.) bereitstellt, die nur durch den entsprechenden Silverlight Client zugänglich sind . Es kann viele geben, von denen einige Zugang zu einigen Medien haben und einige Zugang zu anderen haben.

Der Web-Service existiert und es ist aktuell ein .asmx, aber wir werden dies auf WFC aktualisieren.

Bisher nachdem viele Blogs auf WCF und Autorisierung zu lesen, habe ich auf diese Idee kommen:

1. Jeder Silver Client hat irgendwo einen Client-Schlüssel in seiner Konfiguration.
2. Der Web-Service-Server ist durch SSL geschützt, sodass die Client-ID als Web-Service-Parameter verschlüsselt wird.
3. Die Authentifizierung erfolgt über den Clientschlüssel.
4. Die Autorisierung erfolgt über den Clientschlüssel.

Soweit ich sehen kann, Ich denke dies sicher sein sollte, aber Sie fühlen sich frei Löcher zu stecken!

Das einzige, was mich nervt, ist aus meiner Forschung, es gibt so viel Gefallen an der Verwendung von WCF für Authentifizierung und Autorisierung, aber für mich fühlt es sich einfach zu kompliziert für das, was ich brauche! Ganz zu schweigen davon, wie die komplizierten Clientkonfigurationsdateien für eine Silverlight-Anwendung funktionieren, die auf den WCF-Dienst zugreift.

In jedem Fall erfordert die WCF-Authentifizierung aus meiner Sicht mindestens einen Benutzernamen und ein Passwort oder ein Zertifikat, die beide sehr unhandlich sind, anstatt nur einen netten Clientschlüssel auszugeben.

Scheint meine Idee sicher und vernünftig, oder sollte ich mit meinem WFC-Lernen fortfahren, da das Framework eine bessere Lösung ist?

Wenn das WCF-Framework für Sicherheit bevorzugt wird, gibt es einen Rat auf höchster Ebene, den Sie mir geben können, welche Art von Flow würde ich benötigen, um meinen Web-Service zu sichern?

Freuen Sie sich darauf, Völker Rat und Erfahrung zu hören! :)

Vielen Dank!

Andy

Answer 1

Auf diese Weise ist nicht sicher, weil Silverlight-Client-Technologie, so dass beide SL Kontrolle und ihre Konfigurations speichern auf Anwender-Computer. So kann jeder Benutzer frei auf Schlüssel zugreifen/ändern.
Benutzerdefinierte Sitzungen sind am sichersten, um Ihre Aufgabe zu bewältigen.
Zum Beispiel:
Authentifizierung/Autorisierung kann unter Verwendung von Standard implementiert werden (oder benutzerdefiniert, Sie können einige spezifische Anbieterrollen)/Mitgliedschaftsanbieter implementieren. Nachdem der Client authentifiziert wurde, erhält er vom Server generierte Sitzungstoken (z. B. guid). Gleiche GUID speichert in der serverseitigen Datenbank (z. B. in einer Datenbank, in der alle Rollen, Benutzer usw. gespeichert sind).
Jedes Sitzungstoken hat Ablaufdatum (verwenden Sie DB-Agenten/Tasks/shedulers, um abgelaufene Schlüssel aus der Datenbank zu entfernen).
Jedes Mal, wenn der Client eine Ressource anfordert, sendet er dem Server sein Sitzungstoken sowie andere Anforderungsparameter. Nach dem Empfang des Anforderungsservers Suche nach dem gleichen Sitzungstoken in der Datenbank und falls ein Token existiert, Zugriff auf die angeforderte Ressource bereitstellen. Andernfalls schlägt die Authentifizierung fehl.

Benutzerdefinierte Sitzungen ist ziemlich kompliziert, aber in der gleichen Zeit am sichersten Weg, um Auth-Operationen zu behandeln. Fühlen Sie sich frei, mich zu fragen, wenn Sie einige Fragen dazu haben.