it-swarm.com.de

Funktionsweise des Clientzertifikats für die Authentifizierung (in der Web-API)

Ich arbeite seit einer Woche an diesem Szenario. Ich habe den Code zur Authentifizierung des Client-Zertifikats über diesen Link implementiert: http://www.asp.net/web-api/overview/security/working-with-ssl-in-web-api .

Ein paar Fragen sind noch da:

  1. Wie kann ich überprüfen, ob das Anforderungszertifikat nur von einem autorisierten Client stammt? (Ich weiß, wie man einen privaten Schlüssel verwendet, aber wie?)
  2. Derzeit verwende ich ein selbstsigniertes SSL- und Client-Zertifikat. Woher und wie kann ich ein vertrauenswürdiges Zertifikat erhalten? (Ich weiß, von einer Zertifizierungsstelle, aber was ist der eigentliche Prozess dafür?)
  3. Wie kann ich meinen vertrauenswürdigen Kunden ein Client-Zertifikat ausstellen?

Ich habe so viele Ringantworten auf die obigen Fragen. Ich brauche eine saubere Antwort auf die obigen Fragen. Ich verwende ASP.NET 4.5 (webAPI).

Jede Hilfe wird geschätzt.

6
DSA

Gegenseitiges TLS (auch bekannt als Client-Authentifizierung) ist eine Lösung dafür.

Was die Ausstellung von Zertifikaten angeht, würde ich das nicht tun. Ich würde selbstsignierte Zertifikate vom Kunden nehmen und sie auf irgendeine Weise direkt an Auftraggeber (Benutzer) anheften. Dazu hätte ich eine Nachschlagetabelle, die sowohl nach dem allgemeinen Namen als auch nach dem öffentlichen Schlüssel des Zertifikats indiziert ist. Dies erleichtert potenzielle Probleme wie den Widerruf von Zertifikaten (Löschen der Zeile) und CA-Kompromisse (keine beteiligt) erheblich.

Alternativ können Sie CSRs von Kunden anfordern und diese mit einer vertrauenswürdigen Zertifizierungsstelle signieren (entweder einer Drittanbieter-Zertifizierungsstelle oder Ihrer eigenen internen Zertifizierungsstelle, wenn Ihre Organisation über das Fachwissen und die Ressourcen verfügt, um diese ordnungsgemäß zu schützen).

Hier ist eine gute allgemeine Beschreibung von The Code Project, und es gibt .NET-Beispielcode, der dies demonstriert:

Die gegenseitige SSL-Authentifizierung oder die zertifikatsbasierte gegenseitige Authentifizierung bezieht sich auf zwei Parteien, die sich gegenseitig authentifizieren, indem sie das bereitgestellte digitale Zertifikat überprüfen, damit beide Parteien die Identität der anderen sicher sind. In technologischer Hinsicht bezieht es sich auf einen Client (Webbrowser oder Clientanwendung), der sich bei einem Server (Website oder Serveranwendung) authentifiziert, und diesen Server, der sich auch beim Client authentifiziert, indem er das vom vertrauenswürdigen Zertifikat ausgestellte Public-Key-Zertifikat/digitale Zertifikat überprüft Behörden (CAs). Da die Authentifizierung auf digitalen Zertifikaten basiert, sind Zertifizierungsstellen wie Verisign oder Microsoft Certificate Server ein wichtiger Bestandteil des gegenseitigen Authentifizierungsprozesses. Aus einer übergeordneten Sicht umfasst der Prozess der Authentifizierung und Einrichtung eines verschlüsselten Kanals mithilfe der zertifikatbasierten gegenseitigen Authentifizierung die folgenden Schritte:

  1. Ein Client fordert den Zugriff auf eine geschützte Ressource an.
  2. Der Server legt dem Client sein Zertifikat vor.
  3. Der Client überprüft das Zertifikat des Servers.
  4. Bei Erfolg sendet der Client sein Zertifikat an den Server.
  5. Der Server überprüft die Anmeldeinformationen des Clients.
  6. Bei Erfolg gewährt der Server Zugriff auf die vom Client angeforderte geschützte Ressource.

QUELLE: http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication

10
Alain O'Dea