backend security

OpenIdConnect WIP

Perpustakaan Keamanan Aspnet

• Perpustakaan Aspnet Security yang disederhanakan.
• ditulis ulang dari awal perpustakaan keamanan aspnet.
• Perpustakaan gaya fungsional "ringan" [90% bebas OOP].

Perpustakaan Keamanan

• Authentication.Cookies.
• Authentication.facebook.
• Authentication.google.
• Authentication.twitter.
• Otentikasi.BearerToken.
• Authentication.OAuth2.
• Authentication.OpenIDConnect.
• Otorisasi.
• Perlindungan datapran.

Desain

• Layanan Keamanan [Layanan Otentikasi dan Otorisasi] mewakili tulang punggung mekanisme .
• Layanan Keamanan [Fungsi Tingkat Tinggi ] bertindak sebagai pengontrol perilaku keamanan dan mewakili API publik.
• Perpustakaan keamanan ditulis mengikuti beberapa prinsip FP [fungsi murni, fungsi tingkat tinggi, keabadian, pemisahan data/perilaku, metode/fungsi statis sebagai warga negara kelas satu, pola hasil].
• DI digunakan sebagai lapisan tipis biasanya lebih dari layanan keamanan fungsional [misalnya. Signincookie memiliki 2 implementasi dengan/tanpa layanan DI]. Implementasi Layanan DI Disahkan seperti biasa dengan ekstensi metode spesifik [misalnya. AddCookiesservices , AddFacebookBookServices ].
• Mekanisme keamanan didasarkan pada layanan keamanan [skema otentikasi mekanisme bebas]:
  • Middleware otentikasi menerima layanan otentikasi sebagai param [ekstensi useAuthentication ].
  • Middleware otorisasi menerima tantangan dan melarang layanan sebagai params [ekstensi useauthorization ].
  • OAuth Callback Endpoints menerima layanan SignIn sebagai param [mis. MapFacebook ].
• Perpustakaan otentikasi mengimplementasikan layanan otentikasi spesifik [mis. AuthenticateCookie , Signincookie , ChallengeGoogle , AuthenticateFacebook ].
• PERPUSTAKAAN Otorisasi Menerapkan Layanan Otorisasi [mis. Otorisasi ].
• Fungsi tingkat tinggi biasanya menggunakan gaya deklaratif [mis. Signincookie ].
  • biasanya fungsi tidak murni [dengan efek samping].
  • dibangun di atas fungsi tingkat rendah dan tingkat menengah .
• Fungsi tingkat menengah menggunakan gaya imperatif/deklaratif [mis. SetauthorizationParams ].
• Fungsi tingkat rendah biasanya menggunakan gaya imperatif dan satu kalimat [misalnya. IssecuredCookie ].
  • biasanya murni [tanpa efek samping] atau fungsi semi-murni [efek samping pada parameter].
• Desain hierarki tingkat rendah-rendah saya menamakan prinsip LEGO . Itu bisa dilihat juga sebagai fungsi piramida yang memiliki fungsi tingkat rendah .
• Tidak ada lagi strategi [0 (nol) cabang lain].

Proses

• Ada 2 proses keamanan yang berbeda: otentikasi lokal dan otentikasi jarak jauh .
• Proses otentikasi lokal [cookie]:
  • Setiap permintaan [saat menggunakan otentikasi middlware] hubungi fungsi otentikasi [misalnya. AuthenticateCookie ]. Berdasarkan hasil otentikasi, set middleware httpcontext.user prop.
  • kemudian setiap permintaan [saat menggunakan otorisasi middlware] hubungi fungsi otorisasi [misalnya. Otorisasi ]. Berdasarkan kebijakan otorisasi, hasilnya diputuskan jika permintaan diizinkan, tidak autentikasi/ditantang atau tidak sah/terlarang.
  • Fungsi Signin/Signout digunakan pada titik akhir/tindakan pengontrol tertentu yang diimplementasi oleh devs.
• Proses Otentikasi Jarak Jauh [Protokol OAuth2]:
  • Ketika dipanggil, titik akhir tantangan [mis. Terdaftar dengan MapFacebook ] Bangun dan kirim permintaan otorisasi ke server otorisasi.
  • Setelah memproses permintaan otorisasi, server otorisasi mengarahkan respons ke titik akhir panggilan balik [misalnya. terdaftar dengan MapFacebook ]. Titik akhir itu menerima respons server otorisasi dan panggilan panggilan balik [mis. CallbackFacebook , CallbackoAuth ]. The Callback Func memiliki 2 langkah:
    • Otentikasi: OtenticateOAuth OAuth Authentication Func memiliki 3 Substeps:
      • PosTauthorization - Validasi kode otorisasi dan permintaan dari server otorisasi [Lokal].
      • ExchangeCodefortokens - Exchange dengan server otorisasi kode otorisasi untuk akses [dan penyegar] Token [jarak jauh].
      • AccessUserInfo - Menggunakan Token Akses Mendapat dari Server Otorisasi Informasi Pengguna [Remote].
      • Langkah otentikasi mengubah informasi pengguna yang diterima dari server otorisasi menjadi klaim keamanan, menambahkannya ke identitas klaim, membuat tiket otentikasi dan mengembalikan AuthenticationResult .
    • Signin: Setelah langkah otentikasi oAuth ketika otentikasi berhasil maka fungsi Signin disebut [mis. *Siginincookie^, SignInbeaterToken ]. Signin Func diatur pada pendaftaran titik akhir OAuth.
  • Setelah pengalihan panggilan balik, permintaan berikutnya akan menggunakan proses otentikasi lokal .

Perkataan

• Mekanisme otentikasi yang sepenuhnya ditulis ulang.
• Mekhamisme otorisasi yang ditulis ulang sebagian [menjaga kompatibilitas dengan mekanisme kebijakan otorisasi ASPNET].
• Layanan Otentikasi Cookie secara bedah mengimplementasikan fitur cookie berbasis sesi [menggunakan ISSESSIONBASEDCOOKIE FUNC]. Layanan Otentikasi, SigningIn dan Signingout sepenuhnya mandiri [tidak ada dependensi pada fitur HTTPContext]. AuthenticicationSessionCookie , SigninsessionCookie dan Layanan Cookies Berbasis Sesi SignoutSessionCookie benar-benar terisolasi dari versi berbasis non-sesi.
• Implementasi opsi otentikasi hanya berisi data [mis. CookIeAuthenticationOptions ]. Layanan Otentikasi Cookie [yang tidak berbasis DI] menerima semua dependensi sebagai parameter.
• Implementasi Opsi Otentikasi Microsoft ASPNet berisi data dan perilaku/layanan [mis. Sessionstore , ticketDataFormat , systemclock untuk cookieAuthenticationOptions ]. Desain ini memiliki beberapa keuntungan dibandingkan dengan implementasi saya yang memungkinkan opsi:
  • untuk memiliki layanan yang berbeda dari mereka yang terdaftar di DI.
  • untuk merangkum dan melanjutkan layanan tersebut melalui proses otentikasi [mengurangi jumlah parameter jadi].
• AuthenticateOAuth OAuth Authentication Func Gunakan Pola Desain Metode Templat Memungkinkan pustaka oAuth untuk mengganti/menghias ketika postauthenticate yang perlu, Exchangecodefortokens atau AccessUserinfo Otentikasi Substeps [mis. AuthenticateTwitter , AuthenticateFacebook ].
• Mengarahkan ulang komentar:
  • Tantangan dan Fungsi Challengeoidc Redirect ke Server Otorisasi [ Challengeoidc dapat menggunakan formulir alih -alih pengalihan].
  • CallbackoAuth dan Callbackoidc Funcs Redirect ke URL Asli atau Saat Kesalahan Otentikasi Callback ke AccessDeliedPath atau ERRORTPATH ​​Opsi Opsi Otentikasi Props tergantung dari jenis kesalahan.
  • Signincookie , SignoutCookie , tantangan *, melarang * dll. Tidak ada pengalihan [fungsi berorientasi webapi]. Ketika pengalihan tidak perlu, fungsi -fungsi itu dapat didekorasi dan dialihkan ke otentikasi properti.redirectur atau ke authenticationOptions.
• Keterangan Cookie:
  • AuthenticationCookieOptions.Expiresterfter satu tempat untuk mengontrol authenticationTicket [cookies] Kegigihan.
  • AuthenticationCookieOptions.cookiename Tempat tunggal untuk mengontrol nama cookie.
• Keterangan OIDC:
  • PKCE adalah solusi yang disarankan mengenai keamanan untuk aliran kode otorisasi .
  • Aliran implisit dan hibrida tidak didukung berdasarkan praktik terbaik OIDC [bahkan didukung oleh OIDC RFC].
  • Nonce tidak perlu karena implisit dan hibrida hanya mengalir dengan parameter nonce yang diperlukan.

Tujuan proyek

• Untuk mengurai/menghilangkan mekanisme otentikasi/otorisasi ASPNET dan proses lokal/jarak jauh.
• Untuk menyederhanakan mekanisme otentikasi/otorisasi [mekanisme bebas berbasis skema ASPNET].
• untuk menunjukkan implementasi pemrograman fungsional.
• Untuk menunjukkan alternatif praktis untuk OOP.

Benchmark

Metode	DoVocationCount	Berarti	Kesalahan	Stddev	Median	Perbandingan	RasioSd	Gen0	Gen1	Gen2	Dialokasikan	Rasio Alloc
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

• Untuk InvocationCount> 2048 OOP Benchmark mulai berjalan sangat lambat.