backend security

OpenIdConnect WIP

Bibliotecas de seguridad ASPNET

• Bibliotecas de seguridad ASPNET simplificadas.
• Reescritado desde cero Bibliotecas de seguridad Aspnet.
• Bibliotecas de estilo funcional "ligero" [90% sin OOP].

Bibliotecas de seguridad

• Autenticación.
• Autenticación.facebook.
• Autenticación.google.
• Autenticación.twitter.
• Autenticación.BearerToken.
• Autenticación.oauth2.
• Autenticación.openIdconnect.
• Autorización.
• Dataprotection.

Diseño

• Los servicios de seguridad [servicios de autenticación y autorización] representan la columna vertebral del mecanismo .
• Los servicios de seguridad [funciones de alto nivel ] actúan como controladores de comportamiento de seguridad y representan API pública.
• Las bibliotecas de seguridad se escribieron siguiendo algunos de los principios de FP [funciones puras, funciones de alto orden, inmutabilidad, separación de datos/comportamiento, métodos/funciones estáticas como ciudadanos de primera clase, patrón de resultados].
• DI se usa como capa delgada generalmente sobre servicios de seguridad funcionales [por ejemplo. SigninCookie tiene 2 implementaciones con/sin servicios DI]. Las implementaciones de servicios DI se registran como de costumbre con extensiones de métodos específicos [por ejemplo. AddcookiesServices , addfacebookServices ].
• El mecanismo de seguridad se basa en servicios de seguridad [esquema de autenticación-mecanismo libre]:
  • Autenticación Middleware Recibe servicio de autenticación como Param [Extensión de uso de usas ].
  • Autorización El middleware recibe el desafío y prohíbe los servicios como parámetros [extensión de usauthorización ].
  • OAUTH Los puntos finales de devolución de llamada reciben el servicio de firmar como param [por ejemplo. MAPFACEBOOK ].
• Las bibliotecas de autenticación implementan servicios de autenticación específicos [por ejemplo. AuthenticateCookie , SigninCookie , ChallengeGoogle , AuthenticateFaceBook ].
• Servicios de autorización de la biblioteca de autorización [por ejemplo. Autorizar ].
• Las funciones de alto nivel generalmente usan estilo declarativo [por ejemplo. Signincookie ].
  • Por lo general, las funciones impuras [con efectos secundarios].
  • construido sobre las funciones de bajo nivel e intermedio .
• Las funciones de nivel intermedio usan estilo imperativo/declarativo [por ejemplo. SetAuthorizationParams ].
• Las funciones de bajo nivel generalmente usan un estilo imperativo y son frases individuales [por ejemplo. ISSACURADOCOOKIE ].
  • Por lo general, puro [sin efectos secundarios] o funciones semi-puras [efectos secundarios sobre los parámetros].
• Diseño de jerarquía de nivel intermedio de alto nivel I Llamo It LEGO Principle . Se podría ver también como una pirámide de funciones que tiene en la base de funciones de bajo nivel .
• No otra estrategia [0 (cero) más ramas].

Procesos

• Hay 2 procesos de seguridad diferentes: autenticación local y autenticación remota .
• Proceso de autenticación local [cookie]:
  • Cada solicitud [cuando use autenticación middlware] Llame a la autenticación de funciones [por ejemplo. Autenticatecookie ]. Basado en el resultado de la autenticación, el middleware establece httpcontext.user prop.
  • Luego, cada solicitud [cuando use la autorización MidDLware] Llame de autorización de la llamada [por ejemplo. Autorizar ]. Según el resultado de las políticas de autorización, se decide si la solicitud está permitida, no autenticada/desafiada o no autorizada/prohibida.
  • Los funciones de firma/firma se utilizan en puntos finales específicos/acciones del controlador implementados por devs.
• Proceso de autenticación remota [Protocolo OAuth2]:
  • Cuando se le llama, el punto final de desafío [por ejemplo. Registrado con MAPACEBOOK ] Build y envíe una solicitud de autorización al servidor de autorización.
  • Después de procesar la solicitud de autorización, la respuesta de redirección del servidor de autorización al punto final de devolución de llamada [por ejemplo. Registrado con MapFacebook ]. Ese punto final recibe la respuesta del servidor de autorización y la devolución de llamada de llamada Func [por ejemplo. CallbackfaceBook , callbackoauth ]. La devolución de llamada tiene 2 pasos:
    • Autenticación: AuthenticateOauth Oauth Authentication Func tiene 3 subtepes:
      • PostAuthorización : valida el código de autorización y la solicitud del servidor de autorización [local].
      • ExchangeCodefortOkens : intercambie con el servidor de autorización El código de autorización para los tokens de acceso [y actualización] [remoto].
      • AccessUserInfo : utilizando el token de acceso se obtiene del servidor de autorización, la información del usuario [remoto].
      • El paso de autenticación transforma la información del usuario recibida del servidor de autorización en reclamos de seguridad, agrégalos a la identidad de reclamos, cree un ticket de autenticación y devuelva la autenticación .
    • Significar: después del paso de autenticación de OAUTH cuando la autenticación se sucederá, entonces se llama FUNC de firma [por ejemplo. *Siginincookie^, SigninbearerToken ]. Signin FUNC se establece en el registro de puntos finales de OAuth.
  • Después de la redirección de devolución de llamada, las siguientes solicitudes utilizarán el proceso de autenticación local .

Observaciones

• Mecanismo de autenticación completamente reescrito.
• Mechamismo de autorización parcialmente reescrito [manteniendo la compatibilidad con el mecanismo de políticas de autorización de ASPNET].
• Los servicios de autenticación de cookies implementan quirúrgicamente la función de cookies basadas en sesiones [utilizando la Funchookie de IssessionBassed ]. Los servicios de autenticación, firmación y firmación son completamente independientes entre sí [sin dependencias de las funciones HTTPContext]. Authenticationsessioncookie , SigninsessionCookie y SemotsessionCookie Sessing Services basados ​​en la sesión están completamente aislados de las versiones no basadas en la sesión.
• La implementación de opciones de autenticación contiene solo datos [por ejemplo. CookieAuthenticationOptions ]. Los servicios de autenticación de cookies [no basados ​​en DI] reciben todas las dependencias como parámetros.
• La implementación de Opciones de autenticación de Microsoft Aspnet contiene datos y comportamientos/servicios [por ejemplo. SessionStore , TicketDataFormat , SystemClock para CookieAuthenticationOptions ]. Este diseño tiene algunas ventajas en comparación con mi implementación que permite opciones:
  • tener diferentes servicios de los registrados en DI.
  • para encapsular y continuar esos servicios a través del proceso de autenticación [reduciendo el número de parámetros SO].
• AuthenticateOauth Oauth Authentication FUNC Use el patrón de diseño del método de plantilla que permite a las bibliotecas OAuth anular/decorar cuando es necesario postautenticarse , intercambiar a los subtrepadores de autenticación de la autenticación accessuarios [por ejemplo. AutenticateTwitter , autenticateFaceBook ].
• Redireccionando Observaciones:
  • ChallengeOauth y ChallengeOdc funcionan redirigidos al servidor de autorización [ ChallengeOdc podría usar la forma en lugar de la redirección].
  • CallbackOauth y Callbackoidc funcionan a la URL original o cuando la devolución de llamada Error de autenticación de AccessDeniedPath o Opciones de autenticación de ErrorPath Props dependiendo del tipo de error.
  • SigninCookie , SignOutcookie , Challenge *, Prohibir * etc. Sin redirecciones [funcionalidad orientada a WebAPI]. Cuando las redirecciones son necesarias, esas funciones podrían decorarse y redirigirse a la autenticación Properties. Redirecturi o a la autenticación.
• Observaciones de cookies:
  • AutenticationCookieOptions.ExpiresAfter Single Place para controlar la persistencia de AuthenticationTicket [cookies].
  • AutenticaciónCOOKIEOPTIONS.COOKIENAME Single Place para controlar los nombres de las cookies.
• OIDC Observaciones:
  • PKCE es la solución recomendada con respecto a la seguridad para el flujo del código de autorización .
  • Flujos implícitos e híbridos no respaldados según las mejores prácticas de OIDC [incluso respaldados por OIDC RFC].
  • El nonce no es necesario porque implícitos e híbridos son solo flujos con el parámetro Nonce requerido.

Proyecto de objetivos

• Desenmar/desmitificar los mecanismos de autenticación/autorización de ASPNET y procesos locales/remotos.
• Para simplificar los mecanismos de autenticación/autorización [mecanismo libre basado en esquemas de ASPNET].
• Para demostrar una implementación de programación funcional.
• Para demostrar una alternativa práctica a OOP.

Punto de referencia

Método	Invocación	Significar	Error	Stddev	Mediana	Relación	Ratiosd	Gen0	Gen1	Gen2	Asignado	Asignación de la relación
Fpsignina	128	64.34 μs	1.196 μs	1.119 μs	64.69 μs	1.00	0.00	-	-	-	7.96 kb	1.00
Oopsignina	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
Fpsignina	512	45.75 μs	5.065 μs	14.934 μs	39.12 μs	1.00	0.00	1.9531	-	-	7.96 kb	1.00
Oopsignina	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
Fpsignina	1024	28.83 μs	2.009 μs	5.533 μs	26.26 μs	1.00	0.00	1.9531	-	-	7.95 kb	1.00
Oopsignina	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

• Para InvocationCount> 2048 OOP Benchmark comienza a correr extremadamente lento.