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

Canonical: https://www.nsecsoft.com/th/docs/ping64-identity-access/iam/authentication/configure-authentication-provider/

Language: th-TH

Updated: 2026-11-15T04:10:33.453187Z

ใน 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, คีย์ลงนาม และสถานะแอปพลิเคชัน แล้วทำตามแผนกู้คืนที่ได้รับอนุมัติ