backend security

OpenIDConnect WIP

ASPNET -Sicherheitsbibliotheken

• vereinfachte ASPNET-Sicherheits-ähnliche Bibliotheken.
• Umgeschrieben von Grund auf ASPNET -Sicherheitsbibliotheken.
• Bibliotheken im funktionalen Stil [90% OOP-frei].

Sicherheitsbibliotheken

• Authentifizierung.Cookies.
• Authentifizierung.Facebook.
• Authentifizierung.Google.
• Authentifizierung.twitter.
• Authentifizierung.BeererToken.
• Authentifizierung.OAUTH2.
• Authentifizierung.openidConnect.
• Genehmigung.
• Dataprotektion.

Design

• Sicherheitsdienste [Authentifizierungs- und Autorisierungsdienste] repräsentieren das Mechanismus -Rückgrat .
• Sicherheitsdienste [Funktionen auf hoher Ebene ] fungieren als Sicherheitsverhaltenskontroller und vertreten öffentliche API.
• Sicherheitsbibliotheken wurden nach einigen FP-Prinzipien geschrieben [reine Funktionen, Funktionen mit hoher Ordnung, Unveränderlichkeit, Daten-/Verhaltenstrennung, statische Methoden/Funktionen als erstklassige Bürger, Ergebnismuster].
• DI wird als dünne Schicht verwendet, normalerweise über funktionale Sicherheitsdienste [z. Signincookie hat 2 Implementierungen mit/ohne DI -Diensten]. Implementierungen von DI -Diensten werden wie gewohnt mit spezifischen Methodenerweiterungen registriert [z. AddoCookieServices , addfacebookservices ].
• Der Sicherheitsmechanismus basiert auf Sicherheitsdiensten [Authentifizierungsschema Freimechanismus]:
  • Authentifizierung Middleware erhalten Authentifizierungsdienst als Param [ UseAuthentication -Erweiterung].
  • Autorisierung Middleware erhalten Herausforderung und verbieten Dienste als Parameter [ UseAuthorization -Erweiterung].
  • OAuth -Callback -Endpunkte erhalten einen Signin -Dienst als Param [z. MAPFAKBOOK ].
• Authentifizierungsbibliotheken implementieren spezifische Authentifizierungsdienste [z. AuthenticateCookie , Signincookie , ChallengeGoogle , AuthenticateFacebook ].
• Autorisierungsbibliothek implementieren Autorisierungsdienste [z. Autorisieren ].
• Auf hohe Funktionen verwenden normalerweise einen deklarativen Stil [z. Signincookie ].
  • Normalerweise unreine Funktionen [mit Nebenwirkungen].
  • Aufbauend auf Funktionen auf niedriger Ebene und mittlerer Ebene .
• Funktionen auf mittlerer Ebene verwenden einen imperativen/deklarativen Stil [z. SetAuthorizationParams ].
• Low-Level -Funktionen verwenden normalerweise einen imperativen Stil und sind Einzeiler [z. ISSEVOREDCOOKIE ].
  • Normalerweise reine [ohne Nebenwirkungen] oder Semi-Pure-Funktionen [Nebenwirkungen auf Parameter].
• Hierarchie-Design mit hohem Einstiegs-niedriger Ebene habe ich es LEGO-Prinzip genannt. Es war auch als Funktionspyramide an den Funktionen auf niedriger Ebene zu sehen.
• Nein, sonst Strategie [0 (Null), sonst Zweige].

Prozesse

• Es gibt 2 verschiedene Sicherheitsprozesse: lokale Authentifizierung und Remote -Authentifizierung .
• Lokaler Authentifizierungsprozess [Cookie]:
  • Jede Anfrage [Bei Verwendung der Authentifizierung Middlware] Call Authentication Func [z. Authenticatecookie ]. Basierend auf dem Authentifizierungsergebnis die Middleware -Set httpcontext.user prop.
  • dann jede Anfrage [bei Verwendung der Autorisierung Middlware] Call Authorization Func [z. Autorisieren ]. Basierend auf dem Ergebnis von Autorisierungsrichtlinien wird entschieden, ob die Anfrage zulässig, nicht authentifiziert/herausgefordert oder nicht autorisiert/verboten ist.
  • Signin-/Unterschrift -Funcs werden für bestimmte Endpunkte/Controller -Aktionen verwendet, die von Entwicklungen implementiert wurden.
• Remote -Authentifizierungsprozess [OAuth2 -Protokoll]:
  • Bei der Aufforderung der Herausforderungsendpunkt [z. Registriert mit Mapfacebook ] Erstellen und senden Sie eine Autorisierungsanforderung an den Autorisierungsserver.
  • Nach der Verarbeitung der Autorisierungsanforderung die Reaktion des Autorisierungsservers auf den Callback -Endpunkt [z. Registriert mit Mapfacebook ]. Dieser Endpunkt empfängt die Reaktion des Autorisierungsservers und Callback -Func [z. CALLBACKFACEBOOK , CALLBACKOAUTH ]. Der Rückruffunktion hat 2 Schritte:
    • Authentifizierung: AuthenticateOAuth OAuth Authentication Func hat 3 Untersetzer:
      • Postauthorisierung - Validieren Sie den Autorisierungscode und die Anforderung vom Autorisierungsserver [lokal].
      • ExchangeCodeFortoKens - Austausch mit dem Autorisierungsserver Der Autorisierungscode für den Zugriff [und Aktualisierung] Token [Remote].
      • AccessUserInfo - Die Verwendung von Access -Token erhält die Benutzerinformationen [Remote] aus dem Autorisierungsserver.
      • Die Authentifizierungsschritt verwandeln Benutzerinformationen, die vom Autorisierungsserver empfangen werden, in Sicherheitsansprüche, fügen Sie sie zur Identität von Ansprüchen hinzu, erstellen Sie ein Authentifizierungs -Ticket und senden Sie die Authentifizierung zurück.
    • Signin: Nach der Authentifizierung des Authentifizierung, wenn die Authentifizierung abgelaufen ist, heißt der Signin -Func [zB. *Sigincookie^, SigninBeererToken ]. Signin Func ist auf die Registrierung von OAuth -Endpunkten eingestellt.
  • Nach der Umleitung von Callback werden die nächsten Anfragen den lokalen Authentifizierungsprozess verwenden.

Anmerkungen

• vollständig umgeschriebene Authentifizierungsmechanismus.
• teilweise umgeschriebene Autorisierungsmechanismus [Mechanismus der ASPNET -Autorisierungspolitik beibehalten].
• Cookie Authentication Services implementieren chirurgische Funktionen basierende Cookies-Funktionen [mit isssionBasedcookie func]. Authentifizierung, Signier- und Unterzeichnungsdienste sind sich gegenseitig unabhängig [keine Abhängigkeiten von HTTPContext -Funktionen]. AuthenticationSessionCookie , SignInSessionCookie und SignoutSessionCookie -basierte Cookies-Dienste sind vollständig isoliert von Versionen ohne Sitzung.
• Die Implementierung der Authentifizierungsoptionen enthält nur Daten [z. CookieauthenticationOptions ]. Cookie Authentication Services [nicht di-basierte] empfangen alle Abhängigkeiten als Parameter.
• Die Implementierung von Microsoft ASPNET -Authentifizierungsoptionen enthält Daten und Verhalten/Dienste [z. SessionStore , TicketDataFormat , Systemclock für CookieAuthenticationOptions ]. Dieses Design hat einige Vorteile im Vergleich zu meiner Implementierung, die Optionen zulässt:
  • unterschiedliche Dienste von denen, die auf DI registriert sind.
  • Um diese Dienste durch den Authentifizierungsprozess zu inkapseln und weiterzusetzen [Reduktion der Anzahl der Parameter so].
• AuthenticateOAuth OAuth Authentication Func Verwenden Sie das Design -Muster von Vorlagenmethoden, mit dem OAuth -Bibliotheken überschreiben/dekorieren können, wenn neccessary postauthenticate , thesedecodeFortokens oder AccessSerinFO -Authentifizierung Sekundgeräte [z. Authenticatetwitter , authenticatefacebook ].
• Umleitung von Bemerkungen:
  • ChallengeOAUTH und Challengeoidc -Funcs leiten auf Autorisierungsserver [ ChallengeOidc aus, das Form anstelle der Umleitung verwenden kann].
  • CallbackoAuth- und Callbackoidc -Funcs leiten auf ursprüngliche URL oder wenn Callback -Authentifizierungsfehler zu AccessDeniedPhingPath oder Fehlerpath -Authentifizierungsoptionen Requisiten abhängig vom Fehlertyp ausgeleitet werden.
  • Signincookie , Signoutcookie , Challenge *, Forbid * usw. Keine Umleitungen [Webapi -orientierte Funktionalität]. Wenn Umleitungen erforderlich sind, können diese Funktionen dekoriert und in Authentifizierungsproperties umgeleitet werden. REDirEcturi oder Authentifizierungsparameter .
• Kekse Bemerken:
  • AuthenticationCookieOptions​
  • AuthenticationCookieOptions.CookIename Single Place zur Kontrolle von Cookies -Namen.
• OIDC Bemerkungen:
  • PKCE ist die empfohlene Lösung in Bezug auf die Sicherheit für den Codesfluss des Autorisierungscode .
  • Implizite und Hybridströme , die nicht auf der Grundlage von OIDC -Best Practices unterstützt werden [sogar von OIDC RFC unterstützt].
  • Nonce ist nicht merkwürdig, da implizite und Hybrid nur mit dem erforderlichen Nonce -Parameter fließt.

Projektziele

• Entwirren/Demystifizieren der ASPNET -Authentifizierungs-/Autorisierungsmechanismen und lokalen/Remote -Prozesse.
• Vereinfachen Sie die Authentifizierungs-/Autorisierungsmechanismen [ASPNET-Schema-basierter freier Mechanismus].
• Nachweis einer funktionalen Programmierungsimplementierung.
• eine praktische Alternative zu OOP zu demonstrieren.

Benchmark

Verfahren	InvocationCount	Bedeuten	Fehler	Stddev	Mittlere	Verhältnis	Verhältnisse	Gen0	Gen1	Gen2	Zugewiesen	Alloc -Verhältnis
Fpsignin	128	64,34 μs	1,196 μs	1,119 μs	64,69 μs	1.00	0,00	- -	- -	- -	7,96 kb	1.00
Oopsignin	128	79,98 μs	3,247 μs	9,212 μs	79,56 μs	1.13	0,14	7.8125	7.8125	7.8125	116.21 kb	14.59
Fpsignin	512	45,75 μs	5,065 μs	14,934 μs	39,12 μs	1.00	0,00	1,9531	- -	- -	7,96 kb	1.00
Oopsignin	512	97,08 μs	7,432 μs	21,679 μs	95,52 μs	2.41	1.12	9.7656	9.7656	9.7656	445,7 kb	56.01
Fpsignin	1024	28,83 μs	2,009 μs	5,533 μs	26,26 μs	1.00	0,00	1,9531	- -	- -	7,95 kb	1.00
Oopsignin	1024	186,15 μs	26,776 μs	78,949 μs	211.04 μs	6.32	3.02	14.6484	13.6719	13.6719	915.64 kb	115.12

• Für den Aufladungscount> 2048 OOP Benchmark wird extrem langsam ausgeführt.