กำหนดค่าผู้ให้บริการยืนยันตัวตน

ใน Ping64 ผู้ให้บริการยืนยันตัวตนใช้กำหนดพารามิเตอร์การเชื่อมต่อสำหรับการยืนยันตัวตนของแอปพลิเคชันธุรกิจ การจัดการอัตลักษณ์รองรับการยืนยันตัวตนผ่าน OAuth 2.0 / OpenID Connect (OIDC) หลังจากกำหนดค่าผู้ให้บริการแล้ว ยังต้องเชื่อมโยงกับแอปพลิเคชันและดำเนินการกำหนดค่าและตรวจสอบที่ฝั่งแอปพลิเคชันธุรกิจ

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

ชื่อรายการหน้าจอที่เป็นตัวหนาในบทนี้อ้างอิงอินเทอร์เฟซภาษาอังกฤษ ชื่อที่แสดงอาจแตกต่างกันเมื่อใช้ภาษาอื่น

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

สิ่งที่ต้องเตรียม

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

สร้างผู้ให้บริการ

1. IAM > Authentication Configuration > Authentication Providers: ในคอนโซล ให้เปลี่ยนไปยังการจัดการอัตลักษณ์ เปิด Authentication Providers ภายใต้ Authentication Configuration แล้วเลือก Create
2. ใน Basic Information ให้ป้อนชื่อและคำอธิบายตามต้องการ โดยต้องระบุชื่อ
3. ใน Protocol Settings ให้เลือก Client Type: Confidential เหมาะกับแอปพลิเคชันที่จัดเก็บ Client Secret ได้อย่างปลอดภัย ส่วน Public เหมาะกับไคลเอนต์ที่ไม่สามารถจัดเก็บ Secret ที่ใช้ร่วมกันได้อย่างปลอดภัย เมื่อสร้างใหม่จะเลือก Confidential เป็นค่าเริ่มต้น ให้ยืนยันตามวิธีเชื่อมต่อจริงของแอปพลิเคชัน
4. ตรวจสอบ Client ID ที่สร้างโดยอัตโนมัติ ไคลเอนต์แบบ Confidential จะแสดง Client Secret ด้วย ก่อนสร้าง ID หรือ Secret ใหม่ ให้ประเมินผลกระทบต่อการเชื่อมต่อและส่งข้อมูลรับรองใหม่อย่างปลอดภัย
5. ป้อน Redirect URI อย่างน้อย 1 รายการและไม่เกิน 10 รายการ แต่ละที่อยู่ต้องขึ้นต้นด้วย http:// หรือ https:// และตรงกับที่อยู่เรียกกลับสำหรับเข้าสู่ระบบที่แอปพลิเคชันใช้จริง เพิ่ม Logout Redirect URI ได้ไม่เกิน 10 รายการตามต้องการ
6. เลือก Signing Key ที่ใช้ได้ ใน Advanced Protocol Settings ให้เลือก Scope, Subject Mode และ Issuer Mode แล้วตรวจสอบกับผู้รับผิดชอบแอปพลิเคชัน Scope จำกัดขอบเขตข้อมูลอัตลักษณ์ที่แอปพลิเคชันร้องขอ ส่วน Subject Mode มีผลต่อตัวระบุผู้ใช้ที่แอปพลิเคชันได้รับ ไม่ควรให้ Scope ที่ไม่จำเป็น
7. บันทึกและตรวจสอบข้อความสำเร็จหรือผิดพลาด การกลับไปยังรายการไม่ได้ยืนยันว่าบันทึกสำเร็จเสมอไป ให้เปิดผู้ให้บริการอีกครั้งและตรวจสอบชื่อ Client ID ที่อยู่เรียกกลับ และการตั้งค่าอื่น

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

การที่หน้ากำหนดค่ายอมรับที่อยู่ http:// ไม่ได้หมายความว่าเหมาะกับระบบใช้งานจริงหรือการส่งข้อมูลบนเครือข่ายได้รับการป้องกัน ให้ประเมินวิธีส่งข้อมูลและที่อยู่เรียกกลับตามข้อกำหนดความปลอดภัยขององค์กร

การเลือกและตรวจสอบขอบเขต: หน้ามี openid, profile, email และ offline_access ตัวเลือกนี้กำหนดขอบเขตที่อนุญาตให้แอปร้องขอ แอปยังต้องร้องขอขอบเขตที่ต้องใช้จริงขณะเข้าสู่ระบบ โดยต้องขออย่างน้อยหนึ่งรายการและไม่เกินขอบเขตที่อนุญาต สำหรับการเข้าสู่ระบบ OIDC ให้เลือก openid ตามข้อกำหนดการเชื่อมต่อ หากต้องรับชื่อหรืออีเมลผ่านข้อมูลผู้ใช้ ให้ตรวจว่าอนุญาตและร้องขอ profile หรือ email ตามลำดับจริง ข้อมูลอีเมลยังขึ้นอยู่กับว่าบัญชีได้ระบุอีเมลหรือไม่ offline_access เกี่ยวข้องกับโทเคนรีเฟรช แต่การเลือกเพียงอย่างเดียวไม่รับประกันว่าจะรีเฟรชได้ การตั้งค่าที่บันทึกผ่านหน้านี้ไม่อนุญาตวิธีใช้โทเคนรีเฟรช อย่าถือว่าข้อมูลการค้นพบหรือการได้รับโทเคนรีเฟรชยืนยันว่าการรีเฟรชภายหลังจะสำเร็จ หากงานต้องเข้าสู่ระบบต่อเนื่อง ให้ยืนยันแนวทางที่ใช้ได้กับผู้รับผิดชอบแอปและฝ่ายสนับสนุนทางเทคนิค และทดสอบพฤติกรรมหลังโทเคนหมดอายุก่อนใช้งานจริง

เชื่อมโยงและตรวจสอบแอปพลิเคชัน

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

1. เปิด Applications ภายใต้ Applications & Access แล้วสร้างหรือแก้ไขแอปพลิเคชัน
2. เปิดหน้าต่างเลือกในช่องผู้ให้บริการของแอปพลิเคชันและเลือกผู้ให้บริการที่เหมาะสมและพร้อมใช้ กำหนดค่าอื่นที่จำเป็นให้ครบแล้วบันทึก กำหนดขอบเขตการเข้าถึงตามการใช้งานจริง การเชื่อมโยงผู้ให้บริการเพียงอย่างเดียวไม่ได้ให้สิทธิ์เข้าถึงแก่ผู้ใช้
3. กลับไปที่ Authentication Providers เลือกชื่อผู้ให้บริการเพื่อเปิดรายละเอียด แล้วตรวจสอบแอปพลิเคชันที่เชื่อมโยง Client ID ที่อยู่เรียกกลับ และข้อมูลการกำหนดค่า OpenID ที่แสดง
4. ตรวจพารามิเตอร์การเชื่อมต่อในแอปพลิเคชันธุรกิจก่อน หากไม่ตรงตามข้อกำหนดเท่านั้น ให้ผู้รับผิดชอบแอปปรับตามแผนที่อนุมัติ ใช้บัญชีทดสอบที่ควบคุมเพื่อตรวจสอบทั้งกรณีอนุญาตและไม่อนุญาตให้เข้าถึง และตรวจสอบการเปลี่ยนเส้นทางจริงหลังเข้าสู่ระบบและออกจากระบบ
5. ตรวจสอบ Scope ที่ร้องขอ ตัวระบุผู้ใช้ และการตรวจสอบลายเซ็นว่าเป็นไปตามคาด ตรวจสอบ Issuer Mode เทียบกับเอกสาร discovery จริง โทเคน และผลการทดสอบเชื่อมต่อ ไม่ควรตัดสินผู้ออกจริงจากคำอธิบายตัวเลือกบนหน้าจอเพียงอย่างเดียว
6. ยืนยันกับผู้รับผิดชอบแอปพลิเคชันว่าใช้ขั้นตอน Authorization Code เมื่อไคลเอนต์แบบ Confidential ใช้ Secret ให้ยืนยันผ่านช่องทางปลอดภัยว่าการตั้งค่าทั้งสองฝั่งตรงกัน ไคลเอนต์แบบ Public ต้องรองรับ PKCE และใช้พารามิเตอร์ตรวจสอบที่สอดคล้องกันเมื่อขอสิทธิ์และแลก Authorization Code โดยควรใช้ S256 หากไม่รองรับ PKCE หรือพารามิเตอร์ไม่ตรงกัน การยืนยันตัวตนอาจล้มเหลว ห้ามเปลี่ยนเป็นไคลเอนต์แบบ Confidential เพื่อเลี่ยงข้อจำกัดที่แอปพลิเคชันไม่สามารถเก็บ Secret ได้อย่างปลอดภัย

แก้ไขและลบ

เลือก Edit ของผู้ให้บริการในรายการเพื่อเปลี่ยนการตั้งค่า หากไม่ได้สร้าง Secret ใหม่ขณะแก้ไข หน้าอาจแสดงค่าปกปิด ห้ามนำค่าปกปิดไปใช้เป็น Secret จริง การเปลี่ยน Client ID, Secret, URI เปลี่ยนเส้นทาง คีย์ลงนาม หรือโหมดตัวระบุผู้ใช้อาจกระทบแอปพลิเคชันที่เชื่อมต่อ ควรกำหนดช่วงเวลาการเปลี่ยนแปลงและแผนย้อนกลับล่วงหน้า แล้วตรวจสอบแอปพลิเคชันที่เกี่ยวข้องอีกครั้งหลังเปลี่ยน

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

การแก้ไขปัญหา

• ไม่พบผู้ให้บริการ: การค้นหาชื่ออาจตกหล่นรายการที่มีอยู่ ให้ล้างคำค้นและตรวจสอบรายการกับสิทธิ์ของบัญชี
• บันทึกไม่สำเร็จ: ตรวจสอบชื่อ ที่อยู่เรียกกลับ คีย์ลงนาม Scope ช่องบังคับอื่น และข้อความบนหน้า การกลับไปยังรายการไม่ใช่หลักฐานว่าบันทึกสำเร็จ
• เรียกกลับหลังเข้าสู่ระบบล้มเหลว: เปรียบเทียบที่อยู่เรียกกลับจริงของแอปพลิเคชันกับการตั้งค่าผู้ให้บริการ ประเภทไคลเอนต์ และพารามิเตอร์ฝั่งแอปพลิเคชัน โดยตรวจสอบที่อยู่เต็มทั้งสองฝั่ง
• โทเคนหรือตัวระบุผู้ใช้ไม่ตรงคาด: ตรวจสอบ Scope, Subject, Issuer จริง และคีย์ลงนาม แล้วใช้บันทึกของแอปพลิเคชันตรวจสอบการเชื่อมต่อ
• แอปพลิเคชันเข้าสู่ระบบไม่ได้หลังเปลี่ยน: ตรวจสอบความเชื่อมโยง Client ID, Secret, คีย์ลงนาม และสถานะแอปพลิเคชัน แล้วทำตามแผนกู้คืนที่ได้รับอนุมัติ