SSO ด้วย CAS หรือ OAuth?

ฉันสงสัยว่าฉันควรใช้โปรโตคอลCASหรือOAuth + ผู้ให้บริการการพิสูจน์ตัวตนบางรายสำหรับการลงชื่อเข้าใช้ครั้งเดียวหรือไม่

ตัวอย่างสถานการณ์:

1. ผู้ใช้พยายามเข้าถึงทรัพยากรที่มีการป้องกัน แต่ไม่ได้รับการรับรองความถูกต้อง
2. แอปพลิเคชันเปลี่ยนเส้นทางผู้ใช้ไปยังเซิร์ฟเวอร์ SSO
3. หากการผึ้งรับรองความถูกต้องผู้ใช้จะได้รับโทเค็นจากเซิร์ฟเวอร์ SSO
4. SSO เปลี่ยนเส้นทางไปยังแอปพลิเคชันดั้งเดิม
5. แอปพลิเคชันดั้งเดิมตรวจสอบโทเค็นกับเซิร์ฟเวอร์ SSO
6. หากโทเค็นตกลงการเข้าถึงจะได้รับอนุญาตและแอปพลิเคชันจะรู้รหัสผู้ใช้
7. ผู้ใช้ทำการล็อกเอาต์และออกจากแอพพลิเคชั่นที่เชื่อมต่อทั้งหมดพร้อมกัน (การลงชื่อออกครั้งเดียว)

เท่าที่ฉันเข้าใจว่าเป็นสิ่งที่ CAS คิดค้นขึ้นมา ลูกค้า CAS ต้องใช้โปรโตคอล CAS เพื่อใช้บริการตรวจสอบความถูกต้อง ตอนนี้ฉันสงสัยว่าจะใช้ CAS หรือ OAuth ที่ไซต์ลูกค้า (ผู้บริโภค) OAuth เป็นส่วนทดแทนสำหรับ CAS นั้นหรือไม่ OAuth ในฐานะมาตรฐานความเป็นจริงใหม่ควรเป็นที่ต้องการหรือไม่ มีการใช้งานง่าย (ไม่ใช่ Sun OpenSSO!) แทนส่วนการรับรองความถูกต้องของ CAS ที่รองรับวิธีการที่แตกต่างกันเช่นชื่อผู้ใช้ / รหัสผ่าน OpenID ใบรับรอง TLS ... หรือไม่

บริบท:

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

ฉันเพิ่งค้นพบ WRAPซึ่งสามารถเป็นผู้สืบทอด OAuth ได้ เป็นโปรโตคอลใหม่ที่ระบุโดย Microsoft, Google และ Yahoo

ภาคผนวก

ฉันได้เรียนรู้ว่า OAuth ไม่ได้ออกแบบมาสำหรับการรับรองความถูกต้องแม้ว่าจะสามารถใช้ในการใช้งาน SSO ได้ แต่ร่วมกับบริการ SSO อย่าง OpenID เท่านั้น

OpenID ดูเหมือนว่าฉันจะเป็น "CAS ใหม่" CAS มีคุณลักษณะบางอย่างที่พลาดไปจาก OpenID (เช่นการลงชื่อออกครั้งเดียว) แต่ก็ไม่ควรที่จะเพิ่มส่วนที่ขาดหายไปในสถานการณ์เฉพาะ ฉันคิดว่า OpenID ได้รับการยอมรับอย่างกว้างขวางและเป็นการดีกว่าที่จะรวม OpenID เข้ากับแอพพลิเคชันหรือเซิร์ฟเวอร์แอปพลิเคชัน ฉันรู้ว่า CAS ยังรองรับ OpenID ด้วย แต่ฉันคิดว่า CAS สามารถใช้กับ OpenID ได้

OpenID ไม่ใช่ 'ผู้สืบทอด' หรือ 'ผู้แทนที่' สำหรับ CAS พวกเขาแตกต่างกันโดยเจตนาและในการนำไปใช้

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

OpenID กระจายการพิสูจน์ตัวตน ใช้มันหากคุณต้องการให้แอปพลิเคชันของคุณยอมรับผู้ใช้ที่ลงชื่อเข้าใช้บริการรับรองความถูกต้องใด ๆ ก็ตาม (ผู้ใช้ระบุที่อยู่เซิร์ฟเวอร์ OpenID - อันที่จริง 'ชื่อผู้ใช้' คือ URL ของเซิร์ฟเวอร์)

ไม่มีการอนุญาตจัดการด้านบน (โดยไม่มีส่วนขยายและ / หรือการปรับแต่ง)

OAuth จัดการการให้สิทธิ์ แต่ไม่ใช่การทดแทนสำหรับ 'USER_ROLES table' แบบดั้งเดิม (การเข้าถึงของผู้ใช้) มันจัดการการอนุญาตสำหรับบุคคลที่สาม

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

ดังนั้น OAuth ไม่ได้เกี่ยวกับ Single Sign-On (หรือใช้แทนโปรโตคอล CAS) มันไม่เกี่ยวกับที่คุณควบคุมสิ่งที่เข้าถึงผู้ใช้สามารถ มันเกี่ยวกับการให้ผู้ใช้ควบคุมวิธีการเข้าถึงทรัพยากรของพวกเขาโดยบุคคลที่สาม การใช้งานสองกรณีที่แตกต่างกันมาก

ตามบริบทที่คุณอธิบาย CAS อาจเป็นตัวเลือกที่เหมาะสม

[อัปเดต]

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

ไม่มีวิธีมาตรฐานในการบังคับล็อกเอาต์ (CAS มีคุณสมบัตินี้)

ฉันมักจะคิดแบบนี้:

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

ใช้ OAuth หากคุณต้องการสนับสนุนการตรวจสอบผู้ใช้จากระบบที่คุณไม่ได้เป็นเจ้าของ / สนับสนุน (เช่น Google, Facebook และอื่น ๆ )

OpenIDเป็นโปรโตคอลการตรวจสอบสิทธิ์OAuthและOAuth WRAPเป็นโปรโตคอลการอนุญาต สามารถรวมกับส่วนขยาย OpenID แบบไฮบริดได้ได้

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

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

สำหรับฉันความแตกต่างที่แท้จริงระหว่าง SSO และ OAuth คือการให้สิทธิ์ไม่ใช่การรับรองความถูกต้องเพราะเซิร์ฟเวอร์ที่ใช้ OAuth อย่างชัดเจนมีตรวจสอบสิทธิ์ (คุณต้องลงชื่อเข้าใช้ google, openId หรือ facebook ของคุณเพื่อให้ OAuth เกิดขึ้นกับแอปไคลเอนต์)

ใน SSO ผู้ใช้ขั้นสูง / ผู้ดูแลระบบให้สิทธิ์ผู้ใช้ขั้นสุดท้ายในการเข้าถึงแอปพลิเคชันล่วงหน้าใน "แอป SSO" ใน OAuth ผู้ใช้ขั้นสุดท้ายให้สิทธิ์การเข้าถึงแอปพลิเคชันกับ "ข้อมูล" ของเขาบน "แอป OAuth"

ฉันไม่เห็นสาเหตุที่ไม่สามารถใช้โปรโตคอล OAuth เป็นส่วนหนึ่งของเซิร์ฟเวอร์ SSO เพียงนำหน้าจอการให้สิทธิ์ออกจากโฟลว์และปล่อยให้เซิร์ฟเวอร์ OAuth ค้นหาการอนุญาตจาก backup db

โพสต์เก่า แต่นี่อาจมีประโยชน์:

CAS 3.5 จะรองรับ oAuth ในฐานะลูกค้าและเซิร์ฟเวอร์ ดู: https://wiki.jasig.org/display/CASUM/OAuth