เชื่อมต่อ Okta
ถ้าบริษัทของคุณใช้ Okta (หรือผู้ให้บริการยืนยันตัวตนแบบ SAML รายอื่น) FortressFlag มอบการเข้าสู่ระบบให้มันทั้งหมดได้ — และให้ไดเรกทอรีของคุณเป็นผู้กำหนดว่าใครมีบัญชีและถือบทบาทอะไร คู่มือนี้เชื่อมต่อสามชั้นตามลำดับที่ทำให้คุณยังเข้าสู่ระบบอยู่ตลอด SSO ก่อน แล้วการจัดสรรบัญชี แล้วการแมปกลุ่มเป็นบทบาท แล้ว — เมื่อทุกอย่างทำงานแล้ว — สวิตช์นโยบาย
คุณต้องเป็น Owner ฝั่ง FortressFlag และเป็นผู้ดูแล Okta อีกฝั่ง FortressFlag พูด SAML สำหรับการเข้าสู่ระบบ และ SCIM 2.0 สำหรับการจัดสรรบัญชี (ไม่รองรับ OIDC)
1. เชื่อมต่อ SSO
หัวข้อที่มีชื่อว่า “1. เชื่อมต่อ SSO”ใน ผู้ดูแล → การยืนยันตัวตน ตั้งค่าการเชื่อมต่อ SSO วาง metadata ของผู้ให้บริการยืนยันตัวตนของคุณ แล้ว FortressFlag จะให้สองค่าที่การตั้งค่าแอป SAML ของ Okta ถามหากลับมา — entity ID ของ service provider (URL ของ metadata) และ ACS URL
สร้างแอป SAML ใน Okta ด้วยค่าเหล่านั้น มอบหมายตัวคุณเองให้แอปนั้น แล้วทดสอบการเข้าสู่ระบบ หน้าจอเข้าสู่ระบบขององค์กรคุณจะมีเส้นทาง single sign-on เพิ่มขึ้นมาข้างฟอร์มรหัสผ่าน ณ จุดนี้ SSO ใช้งานได้ แต่ยังไม่ บังคับ — การเข้าสู่ระบบด้วยรหัสผ่านยังทำงาน ซึ่งเป็นจุดที่คุณควรอยู่ระหว่างทดสอบพอดี
2. เปิดการจัดสรรบัญชี (SCIM)
หัวข้อที่มีชื่อว่า “2. เปิดการจัดสรรบัญชี (SCIM)”ใน ผู้ดูแล → การยืนยันตัวตน เช่นกัน สร้าง โทเค็น SCIM เหมือนคีย์ SDK มันแสดง ครั้งเดียว — คัดลอกลงในการตั้งค่าการจัดสรรของ Okta เป็น bearer token โดยตรง แล้วชี้ Okta ไปที่ SCIM endpoint ของ FortressFlag ของคุณ (พาธ /scim/v2 บนที่อยู่ FortressFlag ของคุณ)
เมื่อเปิดการจัดสรรแล้ว Okta จะสร้างและลบบัญชี FortressFlag เมื่อคนเข้าและออกจากไดเรกทอรีของคุณ
- คนที่ถูกจัดสรรเริ่มเป็น Viewer โดยไม่มีการเข้าถึงโปรเจกต์ — ปลอดภัยโดยค่าเริ่มต้น คุณให้สิทธิ์จากตรงนั้น (หรือให้การแมปกลุ่มทำให้ ในส่วนถัดไป)
- การถอนการจัดสรรลบการเข้าถึงของพวกเขาและออกจากระบบให้ — การ offboard ในไดเรกทอรีของคุณคือการ offboard ที่นี่ รวมเซสชันด้วย
- การเปลี่ยนแปลงที่ทำโดยการจัดสรรปรากฏในบันทึกการตรวจสอบโดยระบุว่าเป็นของโทเค็นการจัดสรร — การกระทำของไดเรกทอรีคุณ บันทึกไว้เช่นนั้น
- มาตรการป้องกันหนึ่งข้อ การจัดสรรไม่มีวันลบ Owner คนสุดท้ายขององค์กรคุณได้
หมายเหตุที่ทีมกฎหมายของคุณจะถาม คนที่ถูกสร้างโดยการจัดสรรไม่เคยเห็นฟอร์มสมัครใช้งาน ผู้ดูแลจึงยอมรับข้อตกลงการให้บริการ ในนามของพวกเขา — แดชบอร์ดจะขอให้ทำ และการยอมรับถูกบันทึกเหมือนการยอมรับอื่น ๆ
3. แมปกลุ่มเป็นบทบาท
หัวข้อที่มีชื่อว่า “3. แมปกลุ่มเป็นบทบาท”ส่งกลุ่ม Okta ของคุณผ่าน SCIM แล้วแผง การแมปกลุ่ม ใน ผู้ดูแล → การยืนยันตัวตน ให้คุณระบุว่า กลุ่มนี้ ⇒ บทบาทนี้ eng-leads ⇒ Admin, engineering ⇒ Developer นับจากนั้น สมาชิกภาพในไดเรกทอรีเป็นผู้กำหนดบทบาทใน FortressFlag
- คนที่อยู่ในหลายกลุ่มที่แมปไว้ได้บทบาทที่แมปไว้ สูงสุด
- บทบาทของสมาชิกที่ถูกแมปแสดงเป็น จัดการโดยผู้ให้บริการยืนยันตัวตนของคุณ ในแดชบอร์ด — ตัวควบคุมบทบาทตรงนั้นถูกปิด เพราะไดเรกทอรีของคุณจะเขียนทับมันอยู่ดี
- กลุ่มที่ไม่ได้แมปไม่ทำอะไร และการแมปไม่มีวันลดบทบาทต่ำกว่า Viewer
4. บังคับใช้ SSO — หลังจากทุกอย่างทำงานแล้ว
หัวข้อที่มีชื่อว่า “4. บังคับใช้ SSO — หลังจากทุกอย่างทำงานแล้ว”กลับไปที่ ผู้ดูแล → การยืนยันตัวตน เปลี่ยนนโยบายขององค์กรเป็น SSO นับจากนี้ การเข้าสู่ระบบด้วยรหัสผ่านถูกปิดสำหรับทุกคน ผู้ให้บริการยืนยันตัวตนคือประตูเดียว
พลิกสวิตช์นี้เป็นอย่างสุดท้าย และอ่านนี่ก่อน เมื่อบังคับใช้ SSO แล้ว การยกเลิกก็ต้องใช้การเข้าสู่ระบบ SSO ที่ใช้งานได้เช่นกัน ถ้าผู้ให้บริการยืนยันตัวตนของคุณเสียขณะที่บังคับใช้ SSO อยู่ — ใบรับรองหมดอายุ แอปถูกลบ — จะไม่มีใครเข้าสู่ระบบได้ รวมถึงคุณ และการกู้คืนคือการคุยกับฝ่ายสนับสนุน ไม่ใช่หน้าตั้งค่า ดังนั้น ยืนยันว่าการเข้าสู่ระบบ SSO ใช้งานได้ ยืนยันว่าคนที่สองเข้าได้ แล้วค่อย บังคับใช้ (แดชบอร์ดยังไม่ยอมให้คุณบังคับใช้ SSO ก่อนที่จะมีการเชื่อมต่อ หรือลบการเชื่อมต่อขณะที่บังคับใช้ SSO อยู่ — มาตรการป้องกันชี้ไปทางเดียวกัน)
ไปต่อที่ไหนดี
หัวข้อที่มีชื่อว่า “ไปต่อที่ไหนดี”- กำหนดให้ใช้การยืนยันตัวตนสองขั้นตอน — นโยบายที่เบากว่า ถ้า SSO มากเกินกว่าที่คุณต้องการ
- บทบาทและความปลอดภัย — บทบาทที่แมปเหล่านั้นให้สิทธิ์อะไร
- เชิญทีมของคุณ — เส้นทางแบบทำเอง ยังอยู่สำหรับผู้รับเหมานอกไดเรกทอรีของคุณ