การอนุญาตที่เหมาะสมในสถาปัตยกรรมแบบเลเยอร์


24

โดยทั่วไปแล้วฉันจะตัดสินใจเรื่องการอนุญาตในตัวควบคุมฝั่งเซิร์ฟเวอร์ของฉัน สิ่งเหล่านี้เป็นจุดสิ้นสุดที่สงบเมื่อเร็ว ๆ นี้ แต่ฉันคิดว่าเหมือนกันกับสถาปัตยกรรมประเภท MVC เพื่อประโยชน์ในการโต้แย้งสมมติว่ามันเป็นสิทธิ์ตามบทบาท วิธีการป้องกันจะได้รับการอธิบายประกอบหรือทำการตรวจสอบและส่งคืน 403s หากจำเป็น

ตอนนี้เนื่องจากการให้สิทธิ์นั้นเป็นกฎทางธุรกิจจริง ๆ - ตัวอย่างเช่น "ผู้ดูแลระบบเท่านั้นที่สามารถแสดงรายการ X" ได้ฉันคิดว่าพวกเขาควรถูกเลเยอร์ลง เมื่อผู้ควบคุมขอให้ชั้นธุรกิจทำการดำเนินการบริการหรือชั้นธุรกิจจะแจ้งให้ผู้ควบคุมทราบว่าไม่ได้รับอนุญาต

นี่เป็นแนวทางที่สมเหตุสมผลหรือไม่? มีข้อเสียนี้หรือไม่?

ฉันไม่ชอบที่จะมี AuthorisationService ซึ่งเป็นส่วนหนึ่งของกฎการเข้ารหัสแบบสแตติกขั้นตอนเพื่อทำสิ่งนี้ แต่บางทีมันก็สมเหตุสมผลที่จะเก็บตรรกะการเข้าถึงทั้งหมดไว้ในที่เดียว มันเป็นความกังวลข้ามตัดที่ควรแยกจากกัน?

ดังนั้นฉันจึงถามว่ามีใครทำเช่นนี้หรือไม่และวิธีการที่พวกเขาประสบความสำเร็จในวิธีที่สะอาดหรือว่ามีแหล่งข้อมูลที่ดีที่ฉันสามารถอ่านได้ ฉันใช้ Java fwiw แต่นี่เป็นคำถามที่ไม่เชื่อเรื่องภาษา

ฉันได้ตรวจสอบคำถามที่เกี่ยวข้องที่นี่และพวกเขาบางมากบนพื้นและคำตอบ ตัวอย่างเช่น: การตรวจสอบและการอนุญาตในรูปแบบโดเมนและดำเนินการผ่าน Service Layer ถึง MVC

ฉันกำลังอ่านเอกสารเกี่ยวกับความปลอดภัยของฤดูใบไม้ผลิซึ่งทำให้เกิดข้อโต้แย้งที่ดีเกี่ยวกับเรื่องนี้ซึ่งเป็นประเด็นที่ต้องคำนึงถึง แต่ฉันกังวลว่ามันเป็นเพียงแค่ "วิธีการในฤดูใบไม้ผลิ" และต้องการมุมมองที่กว้างขึ้น นอกจากนี้ยังเชื่อมโยงแอปพลิเคชันของคุณเข้ากับกรอบงานเฉพาะ


1
สถานะ 403 ไม่ถูกต้องสำหรับปัญหาการอนุญาต ใช้ 401.
gnasher729

@ gnasher729 ฉันคิดว่ามันล้าหลัง 401 หมายถึงการรับรองความถูกต้องล้มเหลวหรือไม่ได้ให้ 403 หมายความว่าคุณไม่มีสิทธิ์การเข้าถึง: stackoverflow.com/questions/3297048/…
JimmyJames

@JimmyJames มีโรงเรียนแห่งความคิดอีกแห่งที่คุณควรใช้เพียงหนึ่งในนั้นสำหรับการตรวจสอบสิทธิ์และความล้มเหลวในการอนุญาตเนื่องจากไม่อนุญาตให้เครื่องมืออัตโนมัติอนุมานตรรกะทางธุรกิจได้อย่างง่ายดาย มีบางอย่างที่คั่งค้างอยู่
Berin Loritsch

1
@BerinLoritsch ขออภัยคุณกำลังบอกว่ามีความคิดที่จะทำให้มันยากที่จะเข้าใจถ้ามันเป็นปัญหาการตรวจสอบหรือการอนุมัติ? RFC ดูเหมือนจะค่อนข้างชัดเจน แต่คุณสามารถใช้ 404 แทน 403 หากคุณไม่ต้องการเปิดเผยข้อมูลมากเกินไป มีการอ้างอิงที่คุณสามารถให้สำหรับอาร์กิวเมนต์สำหรับการใช้ 401 แทน 403 หรือไม่?
JimmyJames

@JimmyJames ใช่ กระบวนการคิดนี้มาจากผู้เชี่ยวชาญด้านความปลอดภัยไม่ใช่นักพัฒนา และฉันก็ได้เห็นข้อเสนอแนะของคุณที่ 404 เพื่อซ่อนข้อมูลอย่างสมบูรณ์เพื่อซ่อนว่าทรัพยากรมีอยู่จริง
Berin Loritsch

คำตอบ:


9

แนวปฏิบัติที่ดีในการเปิดเผยเฉพาะตัวเลือกที่ผู้ใช้ได้รับอนุญาต

สิ่งนี้ทำให้การอนุญาตเป็นเรื่องที่ต้องคำนึงถึง "มุมมอง" จำเป็นต้องรู้ว่าผู้ใช้ได้รับอนุญาตให้ทำอะไรก่อนที่จะสามารถสร้างตัวเลือกและเมนูสำหรับแสดงผล

ส่วนหลังไม่ควรเชื่อถือส่วนหน้าในการตัดสินใจด้านความปลอดภัยดังนั้นจึงต้องตรวจสอบสิทธิ์ด้วยตนเอง

อาจมีกฎเกณฑ์ทางธุรกิจที่มีผลบังคับใช้ขึ้นอยู่กับข้อมูลเช่น "ผู้ใช้ที่มียอดคงเหลือมากกว่า $ 5,000 เท่านั้นที่สามารถเรียกใช้การโอนสกุลเงินต่างประเทศ" หรือ "เฉพาะผู้ใช้ที่สำนักงานใหญ่เท่านั้นที่สามารถดูบัญชีเหล่านี้" ดังนั้นจึงจำเป็นต้องใช้ตรรกะการอนุญาตภายในตรรกะทางธุรกิจ

นอกจากนี้ยังมีการอนุญาตทางเทคนิคเพื่อพิจารณา - ใครได้รับอนุญาตให้ดูบันทึกที่สามารถสำรอง / กู้คืนฐานข้อมูลเป็นต้น

ดังนั้นในที่สุดทุกองค์ประกอบในของคุณอาจมีข้อกำหนดด้านความปลอดภัยและ / หรือการอนุญาตที่เฉพาะเจาะจงในทางปฏิบัติแทบเป็นไปไม่ได้ที่จะรวมสิ่งนี้ลงใน "ชั้นการอนุญาต" แยกต่างหาก


7

ฉันคิดว่ามันเป็นวิธีการที่สมเหตุสมผลอย่างยิ่งในการอนุมัติการให้สิทธิ์ในชั้นบริการของคุณ คุณต้องปกป้องบริการของคุณจากการทำกิจกรรมที่ไม่ได้รับอนุญาต (โดยเฉพาะการแก้ไขข้อมูล) ชั้นบริการของคุณอาจอยู่ในห้องสมุดเดียวและถูกใช้โดยชั้นการนำเสนอที่แตกต่างกัน (คุณอาจมีแอปพลิเคชัน UI ที่แตกต่างกันซึ่งใช้ชั้นบริการเดียวกัน) และคุณไม่สามารถพึ่งพาความจริงที่ว่าเลเยอร์การนำเสนอที่เฉพาะเจาะจงทำการตรวจสอบที่จำเป็น นี่เป็นสิ่งสำคัญอย่างยิ่งหากคุณจะตัดสินใจย้าย Service เลเยอร์ของคุณไปยังกระบวนการแยกต่างหากในภายหลัง (เช่นทำตามวิธี SOA)

ตอนนี้เกี่ยวกับวิธีการบรรลุสิ่งนี้ใน "วิธีที่สะอาด" ฉันไม่ชอบความคิดเกี่ยวกับตรรกะทางธุรกิจที่ทิ้งขยะด้วยการตรวจสอบการอนุญาตดังนั้นการดำเนินการบางอย่างที่เฉพาะเจาะจงของการเขียนโปรแกรมเชิงแนวทางสามารถช่วยได้: มันอาจเป็นการตกแต่งวิธีการบริการที่มีคุณลักษณะพิเศษหรือใช้พร็อกซี่แบบไดนามิก

และที่สำคัญฉันต้องยอมรับว่าในโครงการที่ง่ายมาก ๆ คุณอาจจะอยู่ได้โดยปราศจากการรับรองที่แยกจากกันเพื่อทำให้ชีวิตของคุณง่ายขึ้น แต่สิ่งสำคัญคืออย่าพลาดช่วงเวลาที่ "โครงการง่าย" เริ่มกลายเป็น "โครงการที่ซับซ้อน"


7

ฉันชอบผลักดันการตรวจสอบสิทธิ์ต่ำที่สุดเท่าที่จะทำได้! (แต่ไม่เพิ่มเติม!)

คุณยังสามารถเขียนการทดสอบการให้สิทธิ์อัตโนมัติกับเลเยอร์ "ด้านบน" นี้ได้ และกฎบางอย่างอาจใช้งานได้หรือทำให้เข้าใจได้ในเลเยอร์ที่สูงขึ้นเช่นเลเยอร์บริการของคุณ (CanView / CanSerialize?) แต่โดยทั่วไปฉันคิดว่ากลยุทธ์การอนุญาตที่ปลอดภัยที่สุดนั้นก็คือกลยุทธ์ "DRY-est": ให้สิทธิ์ต่ำที่สุดเท่าที่จะทำได้โดยใช้รหัส "ทั่วไป" หรือ "แบ่งปัน" ส่วนใหญ่เท่าที่จะทำได้ (โดยไม่ต้องมีกฎระเบียบที่ซับซ้อนเกินไป)

คิดเกี่ยวกับทางเลือก หากกฎการให้สิทธิ์ของคุณได้รับการทดสอบและบังคับใช้เฉพาะในชั้นบริการออกจากวัตถุโดเมนของคุณไม่ดีจะโค้งงอเพื่อความรู้สึกนึกคิดของวัตถุบริการอารมณ์คุณจะมักจะต้องบังคับใช้กฎแต่ละข้อของแต่ละบุคคลมากกว่าหนึ่งครั้งในวัตถุและหลายหลาย สถานที่ในแต่ละวัตถุและในรหัสที่ซับซ้อนมากขึ้น

นอกจากนี้เมื่อทีมวิเคราะห์ของคุณว่าจ้าง บริษัท ที่ปรึกษาเพื่อเขียนบริการรายงานโดยใช้วัตถุโดเมนของคุณคุณไม่ต้องการเชื่อถือนักพัฒนาเหล่านั้น! (หรือสิ่งที่คุณสร้างบริการเพิ่มเติมหรือโทรมากกว่าวัตถุที่เหมือนกันสำหรับ. ใด ๆ ที่คุณจะไม่ได้ต้องการที่จะแตกเปิดหนังสือเล่มใหญ่ของกฎเกณฑ์ทางธุรกิจและเหตุผล.) ความหวังในการบังคับใช้กฎเหล่านั้นอย่างถูกต้องอีกครั้ง ; คุณต้องการให้โดเมนของคุณรู้จักและบังคับใช้แล้ว


@Shoe ถ้าฉันเข้าใจความกังวลของคุณ - นั่นเป็นประเด็น หากมีเพียง "ผู้ดูแลระบบ" เท่านั้นที่มีสิทธิ์ตามกฎทางธุรกิจในการสร้างWidgetกฎเดียวกันจะมีผลทุกที่ (จึงไม่เสี่ยงปล่อยให้ทุกคนไม่สนใจมัน!) หากกฎไม่ได้ใช้ทุกที่มันไม่ได้จริงๆกฎเกี่ยวกับWidgetsและเพียง Widgets. ผลักกฎลงไปให้ไกลที่สุดเท่าที่จะทำได้ แต่ไม่ไกลเท่าที่ "กฎ" สามารถไป ... ฉันรู้สึกเหมือนฉันไม่ได้ระบุความแตกต่างได้ดี แต่ควรจะมีความแตกต่างที่นั่น
svidgen

จากประสบการณ์ของฉันกฎการให้สิทธิ์มักเป็นส่วนหนึ่งของกฎทางธุรกิจ เช่น "ไกลที่สุด" มักเป็นเลเยอร์โดเมนของฉัน แต่ฉันสงสัยว่าการที่กฎของคุณ "ควร" ตกนั้นเป็นผลมาจากโดเมนของคุณลักษณะของกฎและวิธีที่ธุรกิจพูดถึงพวกเขา
svidgen
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.