กลยุทธ์การตรวจสอบความถูกต้องของ Microservice


142

ฉันมีปัญหาในการเลือกกลยุทธ์การตรวจสอบสิทธิ์ที่เหมาะสม / ปลอดภัยสำหรับสถาปัตยกรรมไมโครเซอร์วิส โพสต์ SO เดียวที่ฉันพบในหัวข้อนี้คือSingle Sign-On ใน Microservice Architecture

ความคิดของฉันที่นี่คือการมีในแต่ละบริการ (เช่นการรับรองความถูกต้องการส่งข้อความการแจ้งเตือนโปรไฟล์ ฯลฯ ) การอ้างอิงที่ไม่ซ้ำกันสำหรับผู้ใช้แต่ละคน (ค่อนข้างมีเหตุผลแล้วของเขาuser_id) และความเป็นไปได้ที่จะรับผู้ใช้ปัจจุบันidหากเข้าสู่ระบบ

จากการวิจัยของฉันฉันเห็นว่ามีสองกลยุทธ์ที่เป็นไปได้:

1. สถาปัตยกรรมที่ใช้ร่วมกัน

สถาปัตยกรรมที่ใช้ร่วมกัน

ในกลยุทธ์นี้แอปตรวจสอบความถูกต้องเป็นหนึ่งในบริการอื่น ๆ แต่แต่ละบริการต้องสามารถทำการแปลงsession_id=> ได้user_idดังนั้นจึงต้องตายง่ายๆ นั่นเป็นเหตุผลที่ฉันนึกถึง Redis ซึ่งจะเก็บคีย์: ค่าsession_id:user_idไว้

2. สถาปัตยกรรมไฟร์วอลล์

สถาปัตยกรรมไฟร์วอลล์

ในกลยุทธ์นี้การจัดเก็บเซสชันไม่ได้มีความสำคัญมากนักเนื่องจากได้รับการจัดการโดยแอปตรวจสอบสิทธิ์เท่านั้น จากนั้นuser_idสามารถส่งต่อไปยังบริการอื่น ๆ ฉันนึกถึง Rails + Devise (+ Redis หรือ mem-cached หรือที่เก็บคุกกี้ ฯลฯ ) แต่มีความเป็นไปได้มากมาย สิ่งเดียวที่สำคัญคือ Service X ไม่จำเป็นต้องตรวจสอบสิทธิ์ผู้ใช้


วิธีการแก้ปัญหาทั้งสองนี้เปรียบเทียบกันอย่างไรในแง่ของ:

  • ความปลอดภัย
  • ความแข็งแกร่ง
  • ความสามารถในการปรับขนาดได้
  • สะดวกในการใช้

หรือคุณอาจจะแนะนำวิธีแก้ปัญหาอื่นที่ฉันไม่ได้กล่าวถึงที่นี่?

ฉันชอบโซลูชัน # 1 ที่ดีกว่า แต่ไม่พบการใช้งานเริ่มต้นมากนักที่จะทำให้ฉันปลอดภัยในความจริงที่ว่าฉันไปในทิศทางที่ถูกต้อง

ฉันหวังว่าคำถามของฉันจะไม่ถูกปิด ฉันไม่รู้จะถามมันที่ไหนดี

ขอบคุณล่วงหน้า


1
คุณช่วยขอรายละเอียดเพิ่มเติมเกี่ยวกับสิ่งที่คุณพยายามบรรลุได้หรือไม่? ในกรณีแรกการรับรองความถูกต้องเกิดขึ้นกับ Redis หรือในบริการเอง? Redis หายไปในแผนภาพที่สองนี่เป็นเจตนาหรือไม่?
Plamen Petrov

ฉันได้เพิ่มข้อมูลบางอย่าง โปรดแจ้งให้เราทราบว่ามันยังไม่ชัดเจน ขอบคุณ!
Augustin Riedinger

คุณคิดเกี่ยวกับแนวคิดในการสร้างไมโครเซอร์วิสที่ใช้โปรโตคอล OAuth และบริการอื่น ๆ ของคุณที่ใช้โทเค็น
Tiarê Balbi

ฉันอยากรู้เกี่ยวกับวิธีแก้ปัญหานี้ แต่ฉันยังไม่เข้าใจว่าจะได้ผลในทางปฏิบัติอย่างไร คุณรู้หรือไม่ว่าฉันจะหาการใช้งานมาตรฐานได้จากที่ใด
Augustin Riedinger

@AugustinRiedinger ขอบคุณที่วางเรื่องนี้ ฉันยังทำลายเว็บแอปพลิเคชันเสาหินให้เป็นบริการขนาดเล็กโดยทำตามขั้นตอนของทารก ในกรณีของคุณคือ Services 1-n stateless หรือ state-full ในกรณีที่มีสถานะครบถ้วนคุณเคยคิดเกี่ยวกับการจัดการเซสชันในแต่ละบริการเหล่านี้หรือไม่ ขอบคุณ
Manchanda P

คำตอบ:


62

จากสิ่งที่ฉันเข้าใจวิธีที่ดีในการแก้ไขคือใช้โปรโตคอล OAuth 2 (คุณสามารถค้นหาข้อมูลเพิ่มเติมเล็กน้อยเกี่ยวกับเรื่องนี้ได้ที่http://oauth.net/2/ )

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

OAuth 2 รุ่น

ตัวอย่างการออกแบบ Chained Microservice แบบจำลองสถาปัตยกรรม

แหล่งข้อมูล:


1
ขอบคุณมากมันชัดเจน ฉันพบว่าบทความที่ดีมากนี้แตกสลายวิธีแก้ปัญหาเดียวกัน: dejanglozic.com/2014/10/07/…
Augustin Riedinger

16
คำตอบของคุณดีมาก แต่โทเค็นที่สร้างจาก API เกตเวย์ (จากภายในหรือใน AuthMicroService) สามารถจัดการโดยไมโครเซอร์วิสแบบสุ่มซึ่งมีจุดมุ่งหมายเพื่อไม่ให้ตรวจสอบสิทธิ์และอาจไม่มีการจัดการ oauth ภายใน รหัสธุรกิจของเขา?
mfrachet

ตัวอย่างเช่นคุณสามารถใช้ Netflix Zuul เพื่อส่งโทเค็นที่ได้รับในเกตเวย์ไปยังบริการทั้งหมดและพวกเขาจะทราบข้อมูลผู้ใช้ docs.spring.io/spring-boot/docs/current/reference/htmlsingle/…
Tiarê Balbi

สิ่งที่ดีอีกอย่างเกี่ยวกับการใช้ OAuth2 ระหว่างบริการคือคุณสามารถมีจุดสิ้นสุดที่แยกความแตกต่างระหว่างการดำเนินการที่ตรวจสอบสิทธิ์บริการและการตรวจสอบสิทธิ์ของผู้ใช้
cmp

2
OAuth เป็นข้อมูลเพิ่มเติมเกี่ยวกับการอนุญาตให้ระบบเข้าถึงข้อมูลของผู้ใช้ที่อยู่ในระบบอื่น สำหรับฉันดูเหมือนจะเป็นกรณีที่ดีสำหรับ SAML
Rob Grant

8

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

  1. พิสูจน์ตัวตนกับผู้ให้บริการ ID
  2. เก็บโทเค็นการเข้าถึงไว้ในคุกกี้
  3. เข้าถึงหน้าใน webapp
  4. โทรหาบริการ

แผนภาพด้านล่างแสดงส่วนประกอบที่จำเป็น สถาปัตยกรรมดังกล่าวแยกเว็บและ API ข้อมูลออกจากกันจะให้ความยืดหยุ่นความยืดหยุ่นและเสถียรภาพที่ดี

ป้อนคำอธิบายภาพที่นี่


AWS Lambda ไม่ "เย็น" และต้องใช้เวลาในการเริ่มต้นใช้งานใช่หรือไม่ นั่นจะทำให้การเข้าสู่ระบบช้าใช่หรือไม่?
tsuz

@tsuz ขณะนี้ AWS ได้เปิดตัวคุณลักษณะการทำงานพร้อมกันในแลมบ์ดาซึ่งคุณสามารถจองการทำงานพร้อมกันได้ ด้วยวิธีนี้คุณสามารถแก้ไขปัญหาการสตาร์ทเย็นได้ docs.aws.amazon.com/lambda/latest/dg/…
Sandeep Nair

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

@ แซนดีปฉันคิดว่าคุณกำลังอ้างถึงการเตรียมการพร้อมกันและไม่ได้สงวนไว้
Anil Kumar

-2

คุณสามารถใช้idenitty server 4เพื่อวัตถุประสงค์ในการพิสูจน์ตัวตนและการอนุญาต

คุณต้องใช้ สถาปัตยกรรมไฟร์วอลล์ด้วยเหตุนี้คุณจึงสามารถควบคุมความปลอดภัยความแข็งแกร่งความยืดหยุ่นและความสะดวกในการใช้งานได้มากขึ้น

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