ระบบการอนุญาตและการรับรองความถูกต้องสำหรับไมโครไซต์และผู้บริโภค

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

เราไม่แน่ใจว่าจะจัดการกับบทบาทและขอบเขตอย่างไร แนวคิดคือการสร้างบทบาทผู้ใช้พื้นฐาน 3 ประการเช่นผู้ดูแลระบบตัวแทนและผู้ใช้ขั้นปลายและให้แอพสำหรับผู้บริโภคปรับขอบเขตหากจำเป็น

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

สมมติว่าตัวแทนโดยค่าเริ่มต้นสามารถสร้างอ่านและอัปเดตแต่ละทรัพยากรสำหรับ บริษัท ของพวกเขาและนั่นคือขอบเขตสูงสุดของพวกเขาซึ่งสามารถขอโทเค็น / เซสชั่นของพวกเขา แต่นักพัฒนาของลูกค้า (ผู้บริโภค API) ได้ตัดสินใจว่า อ่านและสร้างทรัพยากรบางอย่างเท่านั้น

เป็นวิธีปฏิบัติที่ดีกว่าในการจัดการเรื่องนี้ในการรักษาความปลอดภัยภายในของเราหรือไม่และปล่อยให้พวกเขาเขียนข้อมูลนั้นในฐานข้อมูลของเราหรือให้ลูกค้าจัดการกับสิ่งนั้นภายในโดยการร้องขอโทเค็นที่มีขอบเขตน้อยกว่า ? วิธีนี้เราจะต้องติดตามขอบเขตโทเค็นเท่านั้น

ข้อเสียของสิ่งนี้คือทีมของเราจะต้องสร้างกลไกการเข้าถึงที่ปรับแต่งในแอปพลิเคชันภายในของเรา

ด้วยวิธีคิดนี้บริการไมโครและระบบการอนุญาตไม่ควรใส่ใจกับความต้องการของลูกค้าเพราะพวกเขาเป็นเพียงผู้บริโภคและไม่ได้เป็นส่วนหนึ่งของระบบ (แม้ว่าผู้บริโภคเหล่านั้นจะเป็นแอพภายในของเราเอง)?

การมอบหมายนี้เป็นแนวทางที่ดีหรือไม่?

การรับรองความถูกต้องและการอนุญาตเป็นหัวข้อที่ดีเสมอ

ฉันจะพยายามอธิบายให้คุณทราบว่าเราจัดการกับการอนุญาตในบริการหลายผู้เช่าในปัจจุบันที่ฉันทำงานอยู่ได้อย่างไร การพิสูจน์ตัวตนและการอนุญาตใช้โทเค็นโดยใช้ JSON Web Token open standard บริการนี้เปิดเผย REST API ที่แอปพลิเคชันบนเว็บมือถือและเดสก์ท็อปทุกประเภทสามารถเข้าถึงได้ เมื่อผู้ใช้ได้รับการรับรองความถูกต้องเรียบร้อยแล้วบริการจะให้โทเค็นการเข้าถึงที่ต้องส่งในแต่ละคำขอไปยังเซิร์ฟเวอร์

ดังนั้นให้ฉันแนะนำแนวคิดบางอย่างที่เราใช้ตามวิธีที่เรารับรู้และปฏิบัติต่อข้อมูลในแอปพลิเคชันเซิร์ฟเวอร์

ทรัพยากร : เป็นหน่วยหรือกลุ่มข้อมูลใด ๆ ที่ลูกค้าสามารถเข้าถึงผ่านบริการ สำหรับทรัพยากรทั้งหมดที่เราต้องการควบคุมเรากำหนดชื่อเดียว ตัวอย่างเช่นการมีกฎปลายทางปลายทางถัดไปเราสามารถตั้งชื่อได้ดังนี้:

product

/products
/products/:id

payment

/payments/
/payments/:id

order

/orders
/orders/:id
/orders/:id/products
/orders/:id/products/:id

สมมุติว่าเรามีทรัพยากรสามอย่างในบริการของเรา product, และpaymentorder

การดำเนินการ : เป็นการดำเนินการที่สามารถดำเนินการกับทรัพยากรเช่นอ่านสร้างอัปเดตลบ ฯลฯ ไม่จำเป็นต้องเป็นแค่การดำเนินการ CRUD แบบคลาสสิกคุณสามารถมีการดำเนินการชื่อfollowเช่นหากคุณ ต้องการเปิดเผยบริการที่เผยแพร่ข้อมูลบางประเภทโดยใช้ WebSockets

ความสามารถ : ความสามารถในการที่จะดำเนินการในaction resourceตัวอย่างเช่น อ่านผลิตภัณฑ์สร้างผลิตภัณฑ์ ฯลฯ เป็นเพียงคู่ทรัพยากร / การกระทำ แต่คุณสามารถเพิ่มชื่อและคำอธิบายได้ด้วย

บทบาท : ชุดของความสามารถที่ผู้ใช้สามารถเป็นเจ้าของได้ ตัวอย่างเช่นบทบาทCashierอาจมีความสามารถ "อ่านการชำระเงิน", "สร้างการชำระเงิน" หรือบทบาทSellerสามารถมีความสามารถ "อ่านผลิตภัณฑ์", "อ่านคำสั่งซื้อ", "อัปเดตคำสั่ง", "ลบคำสั่งซื้อ"

ในที่สุดผู้ใช้สามารถมีบทบาทต่าง ๆ ที่ได้รับมอบหมาย

คำอธิบาย

ดังที่ฉันพูดก่อนหน้านี้เราใช้ JSON Web Token และความสามารถที่ผู้ใช้มีอยู่จะถูกประกาศในส่วนของโทเค็น สมมติว่าเรามีผู้ใช้ที่มีบทบาทเป็นแคชเชียร์และผู้ขายในเวลาเดียวกันสำหรับร้านค้าปลีกขนาดเล็ก เพย์โหลดจะมีลักษณะดังนี้:

{
    "scopes": {
        "payment": ["read", "create"],
        "order": ["read", "create", "update", "delete"]
    }
}

ดังที่คุณเห็นในการscopesอ้างสิทธิ์เราไม่ได้ระบุชื่อของบทบาท (แคชเชียร์ผู้ขาย) แทนเฉพาะทรัพยากรและการกระทำที่เกี่ยวข้อง เมื่อไคลเอนต์ส่งการร้องขอไปยังปลายทางบริการควรตรวจสอบว่าโทเค็นการเข้าถึงมีทรัพยากรและการกระทำที่จำเป็น ตัวอย่างเช่นการGETร้องขอไปยังจุดสิ้นสุด/payments/88จะสำเร็จ แต่การDELETEร้องขอไปยังจุดสิ้นสุดเดียวกันจะต้องล้มเหลว

• วิธีจัดกลุ่มและตั้งชื่อทรัพยากรและวิธีการกำหนดและตั้งชื่อการกระทำและความสามารถจะเป็นการตัดสินใจของนักพัฒนา

• อะไรคือบทบาทและความสามารถอะไรที่จะมีบทบาทเหล่านั้นคือการตัดสินใจของลูกค้า

แน่นอนคุณต้องเพิ่มคุณสมบัติพิเศษให้กับเพย์โหลดเพื่อระบุผู้ใช้และลูกค้า (ผู้เช่า) ที่ออกโทเค็น

{
    "scopes": {
        ...
    },
    "tenant": "acme",
    "user":"coyote"
}

ด้วยวิธีนี้คุณสามารถปรับแต่งการเข้าถึงบัญชีผู้ใช้บริการของคุณ และที่สำคัญที่สุดคุณไม่จำเป็นต้องสร้างบทบาทที่กำหนดไว้ล่วงหน้าและแบบสแตติกต่าง ๆ เช่นผู้ดูแลระบบตัวแทนและผู้ใช้ปลายทางตามที่คุณชี้ให้เห็นในคำถามของคุณ Super Userจะเป็นผู้ใช้ที่เป็นเจ้าของที่roleมีทั้งหมดresourcesและactionsการให้บริการที่ได้รับมอบหมาย

ทีนี้จะเกิดอะไรขึ้นถ้ามีทรัพยากร 100 อย่างและเราต้องการบทบาทที่ให้การเข้าถึงทั้งหมดหรือเกือบทั้งหมด? โทเค็นของเรามีปริมาณมาก นั่นคือแก้ไขโดยซ้อนทรัพยากรและเพียงเพิ่มทรัพยากรหลักในขอบเขตโทเค็นการเข้าถึง

การอนุญาตเป็นหัวข้อที่ซับซ้อนซึ่งจะต้องได้รับการแก้ไขทั้งนี้ขึ้นอยู่กับความต้องการของแต่ละแอปพลิเคชัน

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

เนื่องจากผู้โทรทุกคนต้องแสดงหลักฐานการบริการไมโครซอฟท์ของคุณว่าพวกเขาได้รับการรับรองความถูกต้องแล้วคุณอาจผูกสิทธิ์ในการตรวจสอบสิทธิ์นั้น หากคุณให้ความสามารถในการผูกผู้ใช้กับกลุ่มการเข้าถึงโดยพลการ (หรือกลุ่มหากคุณต้องการจินตนาการ แต่สิทธิ์ที่เพิ่มเมื่อเทียบกับการลบก็ยากที่จะจัดการกับที่นี่) จะมีคำถามจากลูกค้าของคุณน้อยลงเกี่ยวกับสาเหตุที่ผู้ใช้ x สามารถทำการดำเนินการที่ไม่ต้องการได้ ไม่ว่าในกรณีใด ๆ บางคนต้องทำการตรวจสอบรายการการเข้าถึงสำหรับแต่ละบริการดังนั้นอาจเป็นคุณก็ได้ มันเป็นสิ่งที่จะเขียนโค้ดได้ง่ายมากในตอนต้นของบริการทั้งหมดif ( !TokenAuthorized(this.ServiceName, this.token) { Raise error }) ให้คุณทำเช่นนั้นและติดตามกลุ่มผู้ใช้ด้วยตัวคุณเอง เป็นความจริงที่คุณจะต้องมีผู้จัดการกลุ่มการอนุญาตและทำงานใน UI การจัดการผู้ใช้ (ใช้ที่มีอยู่ / สร้างกลุ่มใหม่สำหรับการอนุญาตผู้ใช้) แสดงรายการผู้ใช้ที่เชื่อมโยงกับกลุ่มแน่นอนเมื่อคุณแก้ไขคำนิยามเพื่อหลีกเลี่ยงความสับสน . แต่มันไม่ใช่งานยาก เพียงแค่มีข้อมูลเมตาสำหรับบริการทั้งหมดและผูกการค้นหาการแมประหว่างกลุ่มและบริการในการจัดการโทเค็นรับรองความถูกต้อง

ตกลงดังนั้นมีรายละเอียดค่อนข้างน้อย แต่ลูกค้าของคุณแต่ละคนที่ต้องการฟังก์ชั่นนี้จะต้องใช้รหัสนี้ในทุกกรณีและหากคุณสนับสนุนการอนุญาตผู้ใช้สามระดับคุณก็อาจขยายให้เป็นการเข้าถึงของผู้ใช้แต่ละคน กลุ่ม อาจเป็นจุดตัดทางตรรกะระหว่างสิทธิ์ของกลุ่มฐานและสิทธิ์เฉพาะของผู้ใช้จะเป็นการรวมที่ถูกต้อง แต่ถ้าคุณต้องการที่จะเพิ่มและนำไปใช้สิทธิ์พื้นฐานของ Admin, Agent, สิทธิ์พื้นฐานของผู้ใช้ปลายทางคุณจะต้องทำ การตั้งค่าสถานะ tri-state ususal ในกลุ่มสิทธิ์: เพิ่มสิทธิ์ปฏิเสธสิทธิ์อนุญาตเริ่มต้นและรวมสิทธิ์ที่เหมาะสม

(โปรดทราบว่าสิ่งนี้ควรเกิดขึ้นกับบางสิ่งบางอย่างเช่น SSL หรือ SSL แบบสองทางหากคุณกังวลเกี่ยวกับความปลอดภัยของการสนทนาทั้งสองด้านหากคุณ "รั่วไหล" โทเค็นเหล่านี้กับผู้โจมตี d รหัสผ่านที่ถอดรหัส)

มุมมองของฉันคือคุณมีสองทางเลือกที่นี่

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

• หากลูกค้าของคุณกำลังพัฒนาแอปพลิเคชันของตนเองพวกเขาควรแนะนำ API กลางของพวกเขาเอง ซึ่งเชื่อมต่อกับคุณในฐานะผู้ดูแลระบบ แต่ตรวจสอบคำขอขาเข้ากับข้อกำหนดการรับรองความถูกต้องที่กำหนดเองของพวกเขาก่อนที่จะเรียกบริการของคุณ

การพิจารณาความปลอดภัย

หากฉันเข้าใจการออกแบบของคุณเป็นอย่างดีคุณตั้งใจจะมอบหมายกลไกการควบคุมการเข้าถึงทรัพยากรให้กับฝั่งไคลเอ็นต์นั่นคือแอพที่ใช้งานมากจะช่วยลดรายการที่ผู้ใช้สามารถเห็นได้ สมมติฐานของคุณคือ:

บริการไมโครและระบบการอนุญาตไม่ควรรบกวนความต้องการของลูกค้าเพราะพวกเขาเป็นเพียงผู้บริโภคและไม่ได้เป็นส่วนหนึ่งของระบบ

ฉันเห็นปัญหาร้ายแรงสองข้อสำหรับธุรกิจที่จริงจัง:

• จะเกิดอะไรขึ้นถ้ามีผู้ใช้ที่หลอกลวง (ตัวอย่างเช่นในโรงงานของคู่ของคุณ) ทำวิศวกรรมย้อนกลับแอปลูกค้าและค้นหาข้อมูลเกี่ยวกับ API หลีกเลี่ยงข้อ จำกัด ที่ บริษัท ของเขาวางไว้กับลูกค้าและใช้ข้อมูลนั้นเป็นอันตรายต่อ บริษัท ของคุณ บริษัท ของคุณจะเรียกร้องค่าเสียหาย แต่ บริษัท พาร์เน่จะอ้างว่าคุณไม่ได้ให้วิธีการในการปกป้องข้อมูลของคุณอย่างเพียงพอ
• โดยทั่วไปแล้วเป็นเพียงคำถามของเวลาที่ข้อมูลสำคัญถูกนำไปใช้ในทางที่ผิด (หรือการตรวจสอบจะค้นพบความเสี่ยง) และฝ่ายบริหารของคุณจะต้องขอควบคุมข้อมูลนั้นอย่างเข้มงวดยิ่งขึ้น

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

หากคุณติดตามตำแหน่งปัจจุบันของคุณโปรดปรึกษาเจ้าหน้าที่รักษาความปลอดภัยข้อมูลของคุณอย่างน้อยที่สุด

วิธีการใช้งาน

คุณมีเคล็ดลับ:

ด้วยวิธีนี้เราจะต้องติดตามขอบเขตโทเค็นเท่านั้น

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

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

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

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