backend security

OpenIdConnect WIP

Bibliothèques de sécurité ASPNET

• Les bibliothèques de type sécurité ASPNET simplifiées.
• réécrit à partir des bibliothèques de sécurité Aspnet à zéro.
• Bibliothèques de style fonctionnel "Light" [90% sans OOP].

Bibliothèques de sécurité

• Authentification.cookies.
• Authentication.facebook.
• Authentication.google.
• Authentification.twitter.
• Authentification.begertoken.
• Authentification.oAuth2.
• Authentification.OpenIDConnect.
• Autorisation.
• DataProtection.

Conception

• Les services de sécurité [Services d'authentification et d'autorisation] représentent l' épine dorsale du mécanisme .
• Les services de sécurité [fonctions de haut niveau ] agissent comme des contrôleurs de comportement de sécurité et représentent l'API publique.
• Les bibliothèques de sécurité ont été écrites en suivant certains des principes de FP [fonctions pures, fonctions d'ordre élevé, immuabilité, séparation des données / comportements, méthodes / fonctions statiques en tant que citoyens de première classe, modèle de résultat].
• DI est utilisé comme couche mince généralement sur les services de sécurité fonctionnels [par exemple. SignIncookie a 2 implémentations avec / sans services DI]. Les implémentations des services DI sont enregistrées comme d'habitude avec des extensions de méthode spécifiques [par exemple. Addcookiesservices , addfacebookServices ].
• Le mécanisme de sécurité est basé sur les services de sécurité [schéma d'authentification libre-mécanisme]:
  • Le middleware d'authentification reçoit le service d'authentification en tant que param [extension usUThentification ].
  • Autorisation Middleware reçoit un défi et interdire les services en tant que paramètres [extension UseAuthorization ].
  • Les points de terminaison de rappel OAuth reçoivent le service Signin en tant que param [par exemple. Mapfacebook ].
• Les bibliothèques d'authentification implémentent des services d'authentification spécifiques [par exemple. AuthenticateCookie , SignIncookie , ChallengeGoogle , AuthenticiateFacebook ].
• La bibliothèque d'autorisation implémente les services d'autorisation [par exemple. Autoriser ].
• Les fonctions de haut niveau utilisent généralement un style déclaratif [par exemple. Signincookie ].
  • Fonctions généralement impures [avec des effets secondaires].
  • Construit au-dessus des fonctions de niveau bas et intermédiaire .
• Les fonctions de niveau intermédiaire utilisent un style impératif / déclaratif [par exemple. SetAuthorizationParams ].
• Les fonctions de bas niveau utilisent généralement un style impératif et sont des doublures [par exemple. IssecuredCookie ].
  • Habituellement pur [sans effets secondaires] ou fonctions semi-pure [effets secondaires sur les paramètres].
• Conception de hiérarchie de niveau à haut-intermédiaire Je l'ai nommé Principe LEGO . Il pourrait également être considéré comme une fonction de la pyramide aux fonctions de bas niveau de base.
• Aucune stratégie autre [0 (zéro), les branches].

Processus

• Il existe 2 processus de sécurité différents: l'authentification locale et l'authentification à distance .
• processus d'authentification local [cookie]:
  • Chaque demande [lors de l'utilisation de l'authentification Middlware] appelez l'authentification Func [par exemple. AuthenticateCookie ]. Basé sur le résultat de l'authentification, le middleware set httpcontext.user prop.
  • Ensuite, chaque demande [lors de l'utilisation de l'autorisation middlware] appelez l'autorisation Func [par exemple. Autoriser ]. Sur la base des politiques d'autorisation, le résultat est décidé si la demande est autorisée, non authentifiée / contestée ou non autorisée / interdite.
  • Les funcs de signinage / déconnexion sont utilisés sur des points de terminaison / actions de contrôleur spécifiques implémentés par les développeurs.
• Processus d'authentification à distance [protocole OAuth2]:
  • Lorsqu'il est appelé, le point de terminaison du défi [par exemple. Enregistré auprès de Mapfacebook ] Build et envoyez une demande d'autorisation au serveur d'autorisation.
  • Après le traitement de la demande d'autorisation, la réponse de redirection du serveur d'autorisation vers le point de terminaison de rappel [par exemple. enregistré avec Mapfacebook ]. Ce point de terminaison reçoit une réponse du serveur d'autorisation et des appels func de rappel [par exemple. Callbackfacebook , callbackoAuth ]. La func de rappel a 2 étapes:
    • Authentification: AuthenticiateoAuth OAuth Authentication Func a 3 sous-étapes:
      • Postautorisation - Valider le code d'autorisation et la demande du serveur d'autorisation [local].
      • ExchangeCodeFortOkens - Échange avec le serveur d'autorisation Le code d'autorisation pour les jetons d'accès [et de rafraîchir] [distant].
      • AccessUserInfo - Utilisation d'accès à token provient du serveur d'autorisation Les informations utilisateur [distante].
      • L'étape d'authentification transforme les informations utilisateur reçues du serveur d'autorisation en revendications de sécurité, les ajouter à l'identité des revendications, créent un billet d'authentification et renvoie le Responsable d'authentification .
    • Signine: Après l'étape d'authentification OAuth lorsque l'authentification a succédé, le Signin Func est appelé [par exemple. * Siginincookie ^, Signinberertoken ]. Signin Func est défini sur l'enregistrement des points de terminaison OAuth.
  • Après la redirection de rappel, les demandes des prochaines requêtes utiliseront le processus d'authentification local .

Remarques

• Mécanisme d'authentification complètement réécrit.
• Méchamisme d'autorisation partiellement réécrit [maintenir la compatibilité avec le mécanisme des politiques d'autorisation ASPNET].
• Les services d'authentification des cookies implémentent chirurgicalement la fonctionnalité des cookies basée sur des session [à l'aide de Func d'Issessionbasedcookie ]. L'authentification, la signature et les services de signature sont complètement indépendants [pas de dépendances sur les fonctionnalités httpcontext]. AuthenticationsSessionCooKie , SignNessionCookie et SignoutsessionCookie Session Basé sur la session sont entièrement isolées des versions non basées sur la session.
• L'implémentation des options d'authentification ne contient que des données [par exemple. CookieAuthenticationOptions ]. Les services d'authentification des cookies [non basés sur DI] reçoivent toutes les dépendances en tant que paramètres.
• L'implémentation des options d'authentification Microsoft ASPNET contient des données et des comportements / services [par exemple. SessionStore , TicketDataFormat , SystemClock pour CookieAuthenticationOptions ]. Cette conception présente certains avantages par rapport à mon implémentation permettant des options:
  • avoir différents services de ceux inscrits sur DI.
  • pour résumer et poursuivre ces services via le processus d'authentification [réduisant le nombre de paramètres ainsi].
• AuthenticiateoAuth oauth authentification func utilise le modèle de conception de méthode de conception permettant aux bibliothèques OAuth de remplacer / décorer lorsqu'il est posta-authenticaté nécessaire, échangecodeFortOkens ou AccessUserrinfo Authentication Supertens [par exemple. AuthenticateTwitter , AuthenticiateFacebook ].
• Remarques de redirection:
  • ChallengeoAuth et ChallengeOIDC Funcs Redirection vers Authorization Server [ ChallengeOIDC pourrait utiliser la forme au lieu de la redirection].
  • Les funcs de callbackoauth et de callbackoidc redirigent vers l'URL d'origine ou lors de l'erreur d'authentification de rappel vers AccessDeniedPath ou des options d'authentification ErrorPath , les accessoires en fonction du type d'erreur.
  • SignIncookie , SignoutCookie , Challenge *, interdire * etc. Aucune redirection [fonctionnalité orientée WebAPI]. Lorsque les redirections sont nécessaires, ces funcs pourraient être décorées et redirigées vers AuthenticationProperties.redirerecturi ou sur AuthenticationOptions.Returnurlparamètre le paramètre de requête.
• Remarques des cookies:
  • AuthenticationCooKieOptions .
  • AuthenticationCooKieOptions.cookiename Single Place pour contrôler les noms de cookies.
• Remarques OIDC:
  • PKCE est la solution recommandée concernant la sécurité pour le flux de code d'autorisation .
  • Les flux implicites et hybrides non pris en charge sur la base des meilleures pratiques OIDC [même soutenues par OIDC RFC].
  • NONCE n'est pas nécessaire car implicite et hybride ne sont que des flux avec le paramètre NONCE requis.

Objectifs du projet

• pour démêler / démystifier les mécanismes d'authentification / autorisation ASPNET et les processus locaux / distants.
• pour simplifier les mécanismes d'authentification / autorisation [mécanisme libre basé sur le schéma ASPNET].
• pour démontrer une implémentation de programmation fonctionnelle.
• pour démontrer une alternative pratique à la POO.

Référence

Méthode	Invocation	Signifier	Erreur	Stddev	Médian	Rapport	Ratiosd	Gen0	Gen1	Gen2	Alloué	Ratio alloc
Fpsignin	128	64,34 μs	1,196 μs	1,119 μs	64,69 μs	1,00	0,00	-	-	-	7,96 Ko	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 Ko	14.59
Fpsignin	512	45,75 μs	5,065 μs	14,934 μs	39,12 μs	1,00	0,00	1.9531	-	-	7,96 Ko	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 Ko	56.01
Fpsignin	1024	28,83 μs	2,009 μs	5,533 μs	26,26 μs	1,00	0,00	1.9531	-	-	7,95 Ko	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 Ko	115.12

• Pour InvocationCount> 2048 OOP Benchmark, commencez à fonctionner extrêmement lent.