backend security

OpenIdConnect WIP

Bibliotecas de segurança Aspnet

• Bibliotecas simplificadas do tipo ASPNET em forma de segurança.
• Reescrito das bibliotecas de segurança da ASPNET do zero.
• Bibliotecas de estilo funcional "leves" [90% sem OOP].

Bibliotecas de segurança

• Autenticação.cookies.
• Autenticação.facebook.
• Autenticação.google.
• Autenticação.twitter.
• Authentication.beareToken.
• Autenticação.oauth2.
• Autenticação.openidConnect.
• Autorização.
• Dataprotecção.

Projeto

• Serviços de segurança [serviços de autenticação e autorização] representam o mecanismo de backbone .
• Os serviços de segurança [funções de alto nível ] atuam como controladores de comportamento de segurança e representam a API pública.
• As bibliotecas de segurança foram escritas seguindo alguns dos princípios de FP [funções puras, funções de alta ordem, imutabilidade, separação de dados/comportamento, métodos/funções estáticas como cidadãos de primeira classe, padrão de resultado].
• O DI é usado como camada fina geralmente sobre serviços de segurança funcionais [por exemplo. Signincookie tem 2 implementações com/sem serviços de DI]. As implementações de serviços de DI são registradas como de costume, com extensões de método específicas [por exemplo. AddCookiesServices , addfacebookServices ].
• O mecanismo de segurança é baseado em serviços de segurança [esquema de autenticação livre-mecanismo]:
  • Middleware de autenticação Receba serviço de autenticação como param [ useauthentication extension].
  • O middleware de autorização recebe desafio e proíbe serviços como parâmetros [extensão de autorização de uso ].
  • OAuth Retorno de retorno de chamada Receba Serviço de Signin como param [por exemplo. Mapfacebook ].
• As bibliotecas de autenticação implementam serviços de autenticação específicos [por exemplo. Autenticatecookie , Signincookie , ChallengeGoogle , AuthenticateFacebook ].
• Biblioteca de Autorização Implementar Serviços de Autorização [Por exemplo. Autorize ].
• Funções de alto nível geralmente usam estilo declarativo [por exemplo. Signincookie ].
  • Funções geralmente impuras [com efeitos colaterais].
  • Construído sobre as funções de nível baixo e intermediário .
• As funções de nível intermediário usam estilo imperativo/declarativo [por exemplo. SetAuthorizationParams ].
• Funções de baixo nível geralmente usam estilo imperativo e são frases de uma vez [por exemplo. ISSELECUREDCOOKIE ].
  • geralmente funções puras [sem efeitos colaterais] ou semi-pura [efeitos colaterais nos parâmetros].
• Design de hierarquia de alto nível de alto nível, eu o nomeei LEGO Princípio . Pode ser visto também como uma pirâmide de funções tendo nas funções básicas de baixo nível .
• Não mais estratégia [0 (zero) else ramificações].

Processos

• Existem 2 processos de segurança diferentes: autenticação local e autenticação remota .
• Processo de autenticação local [Cookie]:
  • Cada solicitação [ao usar a autenticação MIDDLware] Chamada de autenticação func [por exemplo. Autenticatecookie ]. Com base no resultado da autenticação, o Middleware Set HttpContext.User Prop.
  • Em seguida, cada solicitação [ao usar a autorização MIDDLware] Chamada Func [por exemplo. Autorize ]. Com base nas políticas de autorização, o resultado é decidido se a solicitação for permitida, não autenticada/desafiada ou não autorizada/proibida.
  • As funções de assinatura/inscrição são usadas em pontos de extremidade/ações do controlador específicos implementados por desenvolvedores.
• Processo de autenticação remota [protocolo OAuth2]:
  • Quando chamado, o Desafio do Desafio [por exemplo. Registrado no mapfacebook ] Construa e envie uma solicitação de autorização ao servidor de autorização.
  • Após o processamento da solicitação de autorização, o servidor de autorização redireciona a resposta ao ponto de extremidade de retorno de chamada [por exemplo. registrado no mapfacebook ]. Esse endpoint recebe resposta do servidor de autorização e ligue para o retorno de chamada [por exemplo. Callbackfacebook , chamado de chamada ]. O Func de retorno de chamada tem 2 etapas:
    • Autenticação: autentiqueoauth oauth autenticação func tem 3 substaus:
      • Postetorização - Validar o código de autorização e a solicitação do servidor de autorização [local].
      • TrocangeCodefortokens - Exchange com o servidor de autorização O código de autorização para os tokens de acesso [e atualização] [remoto].
      • AccessUserInfo - Usando o token de acesso recebe do servidor de autorização as informações do usuário [remoto].
      • A etapa de autenticação transforma as informações do usuário recebidas do Authorization Server em reivindicações de segurança, adicione -as à identidade de reivindicações, crie um ticket de autenticação e retorne o AuthenticationResult .
    • SignIn: Após a etapa de autenticação do OAuth, quando a autenticação suportada, o Func Signin é chamado [por exemplo. *Siginincookie^, Signinbeartoken ]. A Signin Func está definida no registro do OAuth Endpoints.
  • Após o redirecionamento de retorno de chamada, os próximos solicitações usarão o processo de autenticação local .

Observações

• Mecanismo de autenticação completamente reescrito.
• Mechamismo de autorização parcialmente reescrito [mantendo a compatibilidade com o mecanismo de políticas de autorização da ASPNET].
• Os serviços de autenticação de cookie implementam cirurgicamente o recurso Cookies baseados em sessões [usando o ISSessionBasedcookie func]. Os serviços de autenticação, assinatura e assinatura são completamente independentes entre si [sem dependências dos recursos HTTPContext]. AuthenticationSessionCookie , SignInsessionCookie e SignoutSessionCookie Os serviços de cookies baseados em sessões são completamente isolados de versões não baseadas em sessão.
• A implementação de opções de autenticação contém apenas dados [por exemplo. CookieAuthenticationOptions ]. Os serviços de autenticação de cookies [não baseados em DI] recebem todas as dependências como parâmetros.
• A implementação das opções de autenticação da Microsoft ASPNET contém dados e comportamento/serviços [por exemplo. SessionStore , TicketDataFormat , SystemClock for CookieAuthenticationOptions ]. Este design tem algumas vantagens em comparação com minha implementação, permitindo opções:
  • ter serviços diferentes daqueles registrados na DI.
  • Para encapsular e continuar esses serviços através do processo de autenticação [reduzindo o número de parâmetros assim].
• AuthentateOauth OAuth Func Func Func Modelo Método Padrão de design, permitindo que as bibliotecas OAuth substituam/decorem quando substanciais de autenticação de trocaCodeTokens ou Accessuserinfo [por exemplo. Autenticatetwitter , autenticatefacebook ].
• Redirecionando observações:
  • Os funções desafiáveis ​​e desafios e desafios redirecionam para o Autorization Server [ desafioidc poderia usar o formulário em vez de redirecionamento].
  • O Callbackoauth e o callbackoidc FUNCS redirecionam para o URL original ou quando o erro de autenticação de retorno de chamada para AccessdeniedPath ou Opções de autenticação errorpath , dependendo do tipo de erro.
  • Signincookie , SignoutCookie , Desafio *, Proibir * etc. Não há redirecionamentos [funcionalidade orientada para webapi]. Quando os redirecionamentos são necessários, esses funções podem ser decorados e redirecionados para autenticaçãoProperties.Redirecturi ou AuthenticationOptions.ReturnUrlParameter Parâmetro da consulta.
• Comentários de cookies:
  • AuthenticationCookieOptions.ExpireSaFter Single Place para controlar a AuthenticationTicket [Cookies] Persistência.
  • AuthenticationCookieOptions.Cookiename Single Place para controlar os nomes dos cookies.
• OIDC Observações:
  • O PKCE é a solução recomendada em relação à segurança do fluxo de código de autorização .
  • Os fluxos implícitos e híbridos não suportados com base nas melhores práticas do OIDC [até suportadas pelo OIDC RFC].
  • Nonce não é necessário porque implícito e híbrido são apenas fluxos com parâmetro NONCE necessário.

Objetivos do projeto

• Para desembaraçar/desmistificar os mecanismos de autenticação/autorização da ASPNET e processos locais/remotos.
• Para simplificar mecanismos de autenticação/autorização [mecanismo livre baseado em esquema ASPNET].
• para demonstrar uma implementação funcional de programação.
• para demonstrar uma alternativa prática ao OOP.

Benchmark

Método	InvocationCount	Significar	Erro	Stddev	Mediana	Razão	Razão	Gen0	Gen1	Gen2	Alocado	Razão de alocação
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 Comece a ficar extremamente lento.