2009-07-07 12 views
2

Es gibt einige Anwendungen in Silverlight 3 und WPF, die mit Datenwebservices (basierend auf WCF) kommunizieren. Es ist notwendig, Daten-Webdienste zu schützen. Nur bekannte Benutzer sollten Zugriff auf die Daten haben. Lösung funktioniert im lokalen Netzwerk ohne Zugriff von außen.Binden des Sicherheitstokens an einen bestimmten Client-Computer

Der Client verbindet sich zuerst mit dem Authentifizierungswebdienst (Bereitstellung von Benutzername und Kennwort) über SSL und erhält Sicherheitstoken. Anschließend wird dieses Token an Daten-Web-Services übergeben, um den Benutzer zu validieren und Zugriff auf die Daten zu erhalten.

Hier ist die Frage: Wie kann die Verwendung von Security Token auf die Maschine begrenzt werden, für die es ursprünglich ausgestellt wurde?

Die erste Idee besteht darin, die IP-Adresse des Sicherheitstokenclients einzubeziehen. In einigen Fällen kann es jedoch zu einer erneuten Authentifizierung kommen. Zum Beispiel, wenn der Benutzercomputer über lokale Netzwerk- und Wi-Fi-Netzwerkverbindungen verfügt. In diesem Fall führt der Wechsel von einer Verbindung zu einer anderen dazu, dass sich die IP-Adresse des Client-Rechners ändert und das Sicherheitstoken ungültig wird.

Gibt es irgendwelche Muster für solche Dinge?

Antwort

2

Es gibt keine 100% Art und Weise ein Sicherheitstoken an einer Maschine zu binden :(

Was wir in der Regel tun, ist davon ausgehen, dass, wenn Sie die Anmeldeinformationen haben das Token an erster Stelle zu bekommen, du bist auf . die gutes Team und wir Ihnen irgendwie vertrauen Immerhin wir lassen Sie unsere Daten zugreifen sowieso

ich habe ein paar Gedanken.

  • Für Ihre Token, möchten Sie wahrscheinlich verwenden Formularauthentifizierung: Standardmäßig wird tok ausgegeben ens als Cookies, aber das kann konfiguriert werden. Eine andere coole Sache ist, dass die Token automatisch ablaufen (wieder konfigurierbar). Es gibt viele potentielle Fehler, die Sie mit Ihrem eigenen Token/Sicherheitssystem machen können, und die Verwendung eines bestehenden Systems wird Ihnen einen großen Vorteil verschaffen. Es gibt sogar eine WCF service for authentication.
  • Wenn Sie wirklich, wirklich ernsthaft über Anrufe von bestimmten Maschinen zu begrenzen, können Sie 2-Wege-SSL mit Zertifikaten auf dem Client-Rechner verwenden. Es ist immer noch keine idiotensichere Lösung (jemand auf dem guten Team könnte immer noch die Zertifikate mit jemandem auf dem Bad Team teilen), aber es stellt sicher, dass der Client ein Zertifikat, das Sie verteilt haben. Der Nachteil ist, dass dieses Zeug ein pain in the neck to configure ist.

Klarstellung: ein Gedankenexperiment versuchen. Selbst wenn Sie die Win32-APIs von Silverlight aufrufen können, um Maschineninformationen abzurufen und diese für das Token zu verwenden, haben Sie immer noch keine narrensichere Lösung. Ihre API-Aufrufe könnten virtualisiert werden.In diesem Fall könnte Ihre gesamte Client-Maschine virtualisiert werden. Als Beweis dafür, siehe das Darknet-Papier oder ein existierendes DRM-System. Dies ist nicht gewinnbar.

Hier ist, wie Sie den Schaden von jemandem aus dem guten Team begrenzen können, der jemandem auf dem schlechten Team Ihr Token gibt. Sie verfallen die Token nach einer gewissen Zeit. Dann ist das Szenario, mit dem Sie es zu tun haben: Ein Benutzer bietet einen legitimen Benutzer/Pass und so haben sie Zugang für eine bestimmte Zeit (10 Minuten, 10 Stunden, 10 Tage, was auch immer), und es ist Ihnen egal ob sie von Silverlight, AJAX oder einem Atari 2600 anrufen. Immerhin haben sie gerade bewiesen, dass sie mit dem Benutzer auf dem guten Team waren/pass. Dies ist ein Spiel, das Sie gewinnen können.

+0

Wir möchten Single-Sign-On-Lösung für verschiedene Arten von Anwendungen (Win-Web-Silverlight) haben. Es bedeutet, dass es notwendig ist, Token zwischen ihnen zu übertragen. Daher wäre es sinnvoll, die Token-Nutzung nur auf eine Maschine zu beschränken. In diesem Fall, wenn jemand (aus einem schlechten Team) den Token bekommt, wird es schwer sein ihn (wieder) zu benutzen. – IuriiZ

+0

Der Mechanismus, mit dem wir die Token-Wiederverwendung begrenzen, ist der Token-Ablauf. Ich werde das oben klären. –

0

Wenn die Clients Systemzugriff haben, versuchen Sie, die Seriennummer der Festplatte, die MAC-Adresse der Netzwerkkarte, die Seriennummer des Mainboards usw. zu lesen, kombinieren Sie sie und generieren Sie einen Hash daraus. Dann senden Sie diesen Hash zusammen mit den Anmeldeinformationen, um das Sicherheitstoken zu erhalten. Der Hash sollte auch auf dem Server gespeichert werden. Dann übergibt ein Client bei allen nachfolgenden Anforderungen das Sicherheitstoken zusammen mit dem gerade erzeugten Maschinen-Hash. Der Server überprüft sowohl die Anmeldeinformationen als auch den Hash. Insbesondere, ob das Sicherheitstoken mit diesem bestimmten Hash generiert wurde.

Ein bisschen Arbeit, aber es ist machbar und macht Spaß.

+0

Silverlight kann nicht auf das zugrunde liegende System zugreifen. Wenn jemand ein Sicherheitstoken zusammen mit dem generierten Maschinen-Hash erhalten kann (Dienste sind nicht mit SSL geschützt), ist es weiterhin möglich, auf Daten-Web-Services von einem anderen Rechner zuzugreifen, der token + hash präsentiert. – IuriiZ

+0

Der Maschinenfingerabdruck kann nur mit Maschinendaten erstellt werden, dh mit einigen Hardwareinformationen und nicht mit Betriebssystem-/Softwareinstallationen. Wenn Silverlight keinen Zugriff darauf hat, schlägt die Logik vor, dass Ihre Idee sinnlos ist. – User

Verwandte Themen