OpenIdConnect WIP
Aspnet Security Libraries
- ไลบรารีที่คล้ายกัน ASPNET Security
- เขียนใหม่จากศูนย์ความปลอดภัย ASPNET
- "Light" ไลบรารีสไตล์การใช้งาน [90% OOP-Free]
ห้องสมุดความปลอดภัย
- Authentication.cookies
- Authentication.facebook
- Authentication.google
- Authentication.twitter
- การรับรองความถูกต้อง
- Authentication.oauth2
- Authentication.openidConnect
- การอนุญาต
- Dataprotection
ออกแบบ
- บริการรักษาความปลอดภัย [การรับรองความถูกต้องและบริการการอนุญาต] เป็นตัวแทนของ กลไกกระดูกสันหลัง
- บริการรักษาความปลอดภัย [ฟังก์ชั่น ระดับสูง ] ทำหน้าที่เป็น ตัวควบคุมพฤติกรรมความปลอดภัย และเป็นตัวแทนของ API สาธารณะ
- ห้องสมุดความปลอดภัยถูกเขียนขึ้นตาม หลักการ FP บางอย่าง [ฟังก์ชั่นบริสุทธิ์ฟังก์ชั่นการสั่งซื้อสูงการไม่เปลี่ยนแปลงข้อมูล/พฤติกรรมวิธีการ/ฟังก์ชั่นแบบคงที่เป็นพลเมืองชั้นหนึ่งรูปแบบผลลัพธ์]
- DI ใช้เป็น ชั้นบาง ๆ มักจะมากกว่าบริการรักษาความปลอดภัยที่ใช้งานได้ [เช่น Signincookie มี 2 การใช้งานที่มี/ไม่มีบริการ DI] การใช้งานบริการ DI ได้รับการลงทะเบียนตามปกติด้วยส่วนขยายวิธีการเฉพาะ [เช่น AddCookiesservices , AddFacebookServices ]
- กลไกการรักษาความปลอดภัย ขึ้นอยู่กับบริการรักษาความปลอดภัย
- มิดเดิลแวร์การตรวจสอบความถูกต้องได้ รับบริการการตรวจสอบความถูกต้องเป็น param [ useauthentication Extension]
- มิดเดิลแวร์ที่ได้รับอนุญาต ได้ รับความท้าทายและบริการห้ามเป็นพารามิเตอร์
- จุดสิ้นสุดการโทรกลับของ OAuth ได้รับบริการ Signin เป็น param [เช่น MapFacebook ]
- ไลบรารีการตรวจสอบความถูกต้องใช้บริการการตรวจสอบความถูกต้องเฉพาะ [เช่น Authenticatecookie , Signincookie , Challenge -oogle , AuthenticateFacebook ]
- ห้องสมุดการอนุญาตใช้บริการการอนุญาต [เช่น อนุญาต ].
- ฟังก์ชั่น ระดับสูง มักจะใช้สไตล์การประกาศ [เช่น Signincookie ]
- มักจะฟังก์ชั่นที่ไม่บริสุทธิ์ [กับผลข้างเคียง]
- สร้างขึ้นบนฟังก์ชั่น ระดับต่ำ และ ระดับกลาง
- ฟังก์ชั่น ระดับกลาง ใช้สไตล์ที่จำเป็น/การประกาศ [เช่น SetAuthorizationParams ]
- ฟังก์ชั่น ระดับต่ำ มักจะใช้สไตล์ที่จำเป็นและเป็นหนึ่งตอร์ปิโด [เช่น IssecuredCookie ]
- มักจะบริสุทธิ์ [ไม่มีผลข้างเคียง] หรือฟังก์ชั่นกึ่งพ่วง [ผลข้างเคียงที่มีต่อพารามิเตอร์]
- การออกแบบลำดับชั้น ระดับสูงระดับสูง ฉันตั้งชื่อมันว่ามัน เป็นหลักการเลโก้ มันจะเห็นได้ว่าเป็น ฟังก์ชั่นปิรามิด ที่มีฟังก์ชั่น ระดับต่ำ พื้นฐาน
- ไม่มีกลยุทธ์อื่น [0 (ศูนย์) สาขาอื่น]
กระบวนการ
- มีกระบวนการรักษาความปลอดภัยที่แตกต่างกัน 2 กระบวนการ: การรับรองความถูกต้องในท้องถิ่น และ การตรวจสอบความถูกต้องระยะไกล
- กระบวนการตรวจสอบความถูกต้องในท้องถิ่น [คุกกี้]:
- แต่ละคำขอ [เมื่อใช้การตรวจสอบความถูกต้อง middlware] การโทรหา การรับรองความถูกต้อง func [เช่น Authenticatecookie ] ขึ้นอยู่กับผลการตรวจสอบความถูกต้องชุดมิดเดิลแวร์ httpcontext.user prop
- จากนั้นแต่ละคำขอ [เมื่อใช้การอนุมัติมิดเดิลแวร์] การเรียกร้อง การโทร func [เช่น อนุญาต ]. จากผลนโยบายการอนุญาตได้รับการตัดสินหากได้รับอนุญาตให้มีการร้องขอหรือไม่ที่ไม่ได้รับการรับรอง/ท้าทายหรือไม่ได้รับอนุญาต/ต้องห้าม
- Signin/Signout Funcs ใช้กับจุดสิ้นสุด/การกระทำที่เฉพาะเจาะจงของคอนโทรลเลอร์
- กระบวนการตรวจสอบระยะไกล [OAUTH2 Protocol]:
- เมื่อเรียกว่า จุดสิ้นสุดความท้าทาย [เช่น ลงทะเบียนกับ MapFacebook ] สร้างและส่งคำขอการอนุญาตไปยังเซิร์ฟเวอร์การอนุญาต
- หลังจากประมวลผลการขออนุญาตคำขอเซิร์ฟเวอร์การอนุญาตเปลี่ยนเส้นทางการตอบกลับไปยัง จุดสิ้นสุดการโทรกลับ [เช่น ลงทะเบียนกับ MapFacebook ] จุดสิ้นสุดนั้นได้รับการตอบกลับเซิร์ฟเวอร์การอนุญาตและการโทร กลับ func [เช่น callbackfacebook , callbackoauth ] Func การโทรกลับ มี 2 ขั้นตอน:
- การรับรองความถูกต้อง: AuthenticateOauth OAuth Authentication Func มี 3 substeps:
- Postauthorization - ตรวจสอบรหัสการอนุญาตและคำขอจากเซิร์ฟเวอร์การอนุญาต [local]
- ExchangeCodefortokens - แลกเปลี่ยนกับเซิร์ฟเวอร์การอนุญาตรหัสการอนุญาตสำหรับโทเค็นการเข้าถึง [และรีเฟรช] [ระยะไกล]
- AccessUserInfo - การใช้โทเค็นการเข้าถึงได้รับจากเซิร์ฟเวอร์การอนุญาตข้อมูลผู้ใช้ [ระยะไกล]
- ขั้นตอนการรับรองความถูกต้องแปลงข้อมูลผู้ใช้ที่ได้รับจากเซิร์ฟเวอร์การอนุญาตเป็นข้อเรียกร้องความปลอดภัยเพิ่มลงในตัวตนการเรียกร้องสร้างตั๋วตรวจสอบสิทธิ์และส่งคืน การรับรองความถูกต้อง
- Signin: หลังจากขั้นตอนการตรวจสอบความถูกต้องของ OAuth เมื่อการตรวจสอบความถูกต้องสำเร็จจากนั้น Signin Func เรียกว่า [เช่น *siginincookie^, signinbearertoken ] Signin Func ตั้งอยู่ในการลงทะเบียน OAuth Endpoints
- หลังจากการเปลี่ยนเส้นทางการโทรกลับคำขอครั้งต่อไปจะใช้ กระบวนการตรวจสอบความถูกต้องในท้องถิ่น
ข้อสังเกต
- กลไกการรับรองความถูกต้องที่เขียนใหม่ อย่างสมบูรณ์
- การอนุมัติการอนุญาต บางส่วน mechamism [รักษาความเข้ากันได้กับกลไกนโยบายการอนุญาต ASPNET]
- บริการตรวจสอบความถูกต้องของคุกกี้ใช้คุณสมบัติคุกกี้ที่ใช้ เซสชัน [โดยใช้ การออก iscessionbasedcookie func] การตรวจสอบสิทธิ์การลงนามและการลงนามในบริการเป็นอิสระซึ่งกันและกันอย่างสมบูรณ์ [ไม่มีการพึ่งพาบนคุณสมบัติ httpContext] AuthenticationsessionCookie , SignInsessionCookie และ SignoutsessionCookie Session Cookies Services นั้นแยกได้อย่างสมบูรณ์จากรุ่นที่ไม่ใช่เซสชัน
- การใช้งานการตรวจสอบตัวเลือกการใช้งานมีเฉพาะข้อมูล [เช่น CookieAuthenticationOptions ] บริการตรวจสอบความถูกต้องของคุกกี้ [ที่ไม่ใช่ DI-based] ได้รับการอ้างอิงทั้งหมดเป็นพารามิเตอร์
- การใช้งานการตรวจสอบความถูกต้องของ Microsoft ASPNET มีข้อมูลและพฤติกรรม/บริการ [เช่น SessionStore , TicketDataFormat , SystemClock สำหรับ CookieAuthenticationOptions ] การออกแบบนี้มีข้อได้เปรียบบางประการเมื่อเปรียบเทียบกับการใช้งานของฉันที่อนุญาตให้มีตัวเลือก:
- จะมีบริการที่แตกต่างจากที่ลงทะเบียนใน DI
- ในการห่อหุ้มและดำเนินการบริการเหล่านั้นผ่านกระบวนการตรวจสอบ [ลดจำนวนพารามิเตอร์ดังนั้น]
- AuthenticateOauth OAUTH การตรวจสอบความถูกต้อง Func ใช้วิธีการออกแบบแบบแม่แบบช่วยให้ไลบรารี OAUTH สามารถแทนที่/ตกแต่งเมื่อ postauthenticate , ExchangeCodefortokens หรือ AccessUserInfo Authentication SUMSPS [เช่น AuthenticatetWitter , AuthenticateFacebook ]
- การเปลี่ยนเส้นทางคำพูด:
- ChallengeOauth และ Challengeoidc Funcs เปลี่ยนเส้นทางไปยังเซิร์ฟเวอร์การอนุญาต [ Challengeoidc สามารถใช้แบบฟอร์มแทนการเปลี่ยนเส้นทาง]
- CallBackoauth และ Callbackoidc funcs เปลี่ยนเส้นทางไปยัง URL ดั้งเดิมหรือเมื่อข้อผิดพลาดการตรวจสอบสิทธิ์การโทรกลับไปยัง AccessDeniedPath หรือตัวเลือกการตรวจสอบความถูกต้องของ ข้อผิดพลาด อุปกรณ์ประกอบการขึ้นอยู่กับประเภทข้อผิดพลาด
- Signincookie , SignoutCookie , Challenge *, Forbid * ฯลฯ ไม่มีการเปลี่ยนเส้นทาง เมื่อการเปลี่ยนเส้นทางเป็นสิ่งที่จำเป็นสำหรับ funcs เหล่านั้นสามารถตกแต่งและเปลี่ยนเส้นทางไปยัง AuthenticationProperties.redirecturi หรือ AuthenticationOptions.returnurlParameter พารามิเตอร์การสืบค้น
- คำพูดคุกกี้:
- AuthenticationCookieOptions.expiresafter สถานที่เดียวเพื่อควบคุม การรับรองความถูกต้องของ [คุกกี้] การคงอยู่
- AuthenticationCookieOptions.cookiename สถานที่เดียวเพื่อควบคุมชื่อคุกกี้
- ข้อสังเกต OIDC:
- PKCE เป็นโซลูชันที่แนะนำเกี่ยวกับความปลอดภัยสำหรับการไหล ของรหัสการอนุญาต
- การไหล โดยปริยาย และ ไฮบริด ไม่รองรับตามแนวทางปฏิบัติที่ดีที่สุดของ OIDC [แม้กระทั่งรองรับโดย OIDC RFC]
- Nonce ไม่ได้เป็นสิ่งจำเป็นเพราะ โดยปริยาย และ ไฮบริด จะไหลด้วยพารามิเตอร์ Nonce ที่จำเป็นเท่านั้น
เป้าหมายโครงการ
- เพื่อแก้ปัญหา/demystify กลไกการรับรองความถูกต้อง/การอนุญาต ASPNET และกระบวนการท้องถิ่น/ระยะไกล
- เพื่อลดความซับซ้อนของกลไกการรับรองความถูกต้อง/การอนุญาต [กลไกอิสระจาก ASPNET Schema]
- เพื่อแสดงให้เห็นถึงการใช้งานการเขียนโปรแกรมที่ใช้งานได้
- เพื่อแสดงให้เห็นถึงทางเลือกที่เป็นประโยชน์สำหรับ OOP
เกณฑ์มาตรฐาน
| วิธี | การเรียกร้อง | หมายถึง | ข้อผิดพลาด | stddev | ค่ามัธยฐาน | อัตราส่วน | อัตราส่วน | Gen0 | Gen1 | Gen2 | จัดสรร | อัตราส่วนการจัดสรร |
|---|
| 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 |
- สำหรับ InvocationCount> 2048 OOP Benchmark เริ่มทำงานช้ามาก
