Vor einiger Zeit brauchten wir eine Lösung für die Single Sign On-Authentifizierung zwischen mehreren Webdiensten. Zumindest zu dieser Zeit hielten wir das OpenID-Protokoll für zu kompliziert und wir waren nicht überzeugt von den Ruby on Rails-Plugins dafür. Deshalb haben wir ein eigenes Protokoll entwickelt, anstatt einen OpenID-Provider und OpenID-Consumer zu implementieren.

Ich habe zwei Fragen

War es eine schlechte Sache, keinen eigenen OpenID-Provider zu erstellen und unsere OpenID-Konsumenten so einzurichten, dass sie nur diesen akzeptieren? Öffentliche Anmeldungen oder Registrierungen sind nicht gestattet und wir wollten die Authentifizierung einfach halten.

Kannst du einen entscheidenden Fehler oder eine Sicherheitslücke im folgenden Design entdecken?

Wenn Sie als Gemeinde dieses Design genehmigen können, werde ich erwägen, diesen Code in ein Ruby on Rails-Plugin zu extrahieren.

Bitte schauen Sie auf dieFlussdiagramm und Ablaufdiagramm.

Einzelheiten

Authentication Provider ("AP"):

Zentraler Dienst, der alle Daten über die Benutzer enthält.In diesem Setup ist nur ein "AP" vorhanden. Es könnte möglich sein, mehrere "AP" zu haben, aber das sollte in diesem Zusammenhang nicht relevant sein. "AP" kennt jedes "S" vorher.

Authentication Client (Dienst "S"):

s gibt mehrere interne und externe WebserviceJeder Dienst kennt "AP" und seinen öffentlichen Schlüssel im Voraus.

Actor ("A"):

Der Endbenutzer, der sich mit einem Benutzernamen und einem Passwort bei AP authentifiziertKann direkt eine URI von "S" oder "AP" anfordern, bevor sie sich anmeldet

Verbindungen zwischen "A", "S" und "AP" werden durch HTTPS gesichert.

Authentifizierungslogik kurz beschrieben:

Dies sind eine Beschreibung für das grafische Flussdiagramm und das Sequenzdiagramm, die oben in diesem Beitrag verlinkt wurden.

1) Authentifizierungsanbieter "AP"

"AP" sendet eine HTTP-POST-Anforderung von Server zu Server an "S", um eine Nonce zu erhalten. "AP" generiert ein Authentifizierungstoken.Authentication-Token ist eine XML-Entität, die Folgendes enthält:ein Ablaufdatum (in 2 Minuten),die zuvor angeforderte Nonce (um die Wiedergabe zu verhindern),identifying Name von "S" (Token für Service_1 ist nicht gut für Service_2),Information über den Endbenutzer.Authentication-Token wird mit AES256 verschlüsselt und der Verschlüsselungsschlüssel und der Initialisierungsvektor werden vom privaten RSA-Schlüssel von AP signiert.Ergebnisreiche Zeichenfolgen ("data", "key" und "iv") werden zuerst mit Base64 und dann mit URL codiert, damit sie in der URL-Abfragezeichenfolge bereitgestellt werden können.Ende Benutzer "A" wird HTTP-umgeleitet an Dienst "S" (HTTPS-GET-Anforderung).

2) Service "S"

Erhält das Authentifizierungstoken in den URL-Parametern vom Benutzeragenten. Entschlüsselt das Authentifizierungstoken mit dem vorinstallierten öffentlichen Schlüssel des AP.Nimmt ein Authentifizierungstoken nur einmal an (Token enthält eine Nonce, die nur einmal gültig ist).Überprüft, ob der identifizierende Name im Authentifizierungstoken dem Namen des Dienstes entspricht.Überprüft, ob das Authentifizierungstoken nicht abgelaufen ist.

Bemerkungen

Es ist kein Problem, wenn jemand anderes das Authentifizierungstoken ebenfalls entschlüsseln kann, da es keine vertraulichen Informationen über den Benutzer enthält. Es ist jedoch von entscheidender Bedeutung, dass niemand anderes als der AP ein gültiges Authentifizierungstoken generieren kann. Daher ist das RSA-Schlüsselpaar beteiligt.

er private @RSA-Schlüssel wird nur zum Signieren des Tokens verwendet, da er keine Daten verschlüsseln kann, die länger als die tatsächliche Schlüssellänge sind. Daher wird AES für die Verschlüsselung verwendet.

Da das Authentifizierungstoken als HTTP-GET-Anforderung übermittelt wird, wird es z. in Apaches Protokolldatei. Die Verwendung eines Einweg-Nonces und eines Ablaufdatums sollte die Möglichkeit eines Wiederholungsangriffs minimieren. Eine POST-Anfrage würde eine HTML-Seite mit einem Formular erfordern, das automatisch von Javascript gesendet wird, weshalb GET verwendet wird.

Service "S" generiert eine Nonce nur in einer Server-zu-Server-API-Anforderung. Daher sollten nicht authentifizierte Generierungsanforderungen keine DoS-Schwachstelle darstellen.