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

การรับรองความถูกต้องพื้นฐาน HTTP ในวิธีนี้ตัวแทนผู้ใช้ HTTP เพียงแค่ให้ชื่อผู้ใช้และรหัสผ่านเพื่อพิสูจน์การรับรองความถูกต้อง วิธีนี้ไม่ต้องใช้คุกกี้รหัสเซสชันหน้าเข้าสู่ระบบและโซลูชันพิเศษอื่นๆ และเนื่องจากใช้ส่วนหัว HTTP เอง

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

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

บทความนี้ประกอบด้วยตัวอย่างการกําหนดค่าบางส่วนสําหรับการใช้ LDAP สําหรับการรับรองความถูกต้องด้วย ONEWEB 4.0 ลองกําหนดค่าขั้นตอนนี้

ตั้งค่าการเชื่อมต่อ LDAP

ข้อมูลพื้นฐานจากการเชื่อมต่อจะถูกกําหนดด้วยแอตทริบิวต์ต่อไปนี้

security-domain name: ชื่อแอตทริบิวต์สําหรับ ONEWEB 4.0 คงที่เป็นการอ้างอิง "LDAPAuthLocal" จาก jboss-web.xml url: URL ของเซิร์ฟเวอร์ LDAP ที่จะเชื่อมต่อ ตัวอย่าง "ldap://[ที่อยู่ IP ของเซิร์ฟเวอร์]:[พอร์ต]" bindDN: ชื่อจําเพาะที่จะใช้เมื่อสร้างการเชื่อมต่อกับเซิร์ฟเวอร์ เมื่อใช้ bindDN มักจะมาพร้อมกับรหัสผ่านที่เกี่ยวข้อง bindCredential: รหัสผ่านที่จําเป็นสําหรับชื่อ bindDN ที่ระบุเพื่อสร้างการเชื่อมต่อกับเซิร์ฟเวอร์ baseCtxDN: จุดเริ่มต้นที่จะเริ่มค้นหา baseFilter: ตัวกรองการค้นหาที่ใช้เพื่อค้นหาบริบทของผู้ใช้ในการตรวจสอบสิทธิ์ ชื่อผู้ใช้/userDN ที่ป้อนตามที่ได้รับจากการเรียกกลับโมดูลการเข้าสู่ระบบจะถูกแทนที่ลงในตัวกรองทุกที่ที่เห็นนิพจน์{0} ลักษณะการทํางานการแทนที่นี้มาจากวิธีการมาตรฐาน DirContext.search(Name, String, Object[], SearchControls cons) ตัวอย่างทั่วไปสําหรับตัวกรองการค้นหาคือ (uid={0}) rolesCtxDN: ตัวกรองการค้นหาที่ใช้เพื่อค้นหาบทบาทที่เกี่ยวข้องกับผู้ใช้ที่ได้รับการรับรองความถูกต้อง roleAttributeID: ชื่อของแอตทริบิวต์บทบาทของบริบทที่สอดคล้องกับชื่อของบทบาท searchScope: ใช้ขอบเขตเริ่มต้นคือ SUBTREE_SCOPE

สําหรับ Wildfly กําหนดค่า "stanalone.xml" tag "<profile>" sub tag "<subsystem>" <security-domains> ให้ลองแทรก ดูตัวอย่างด้านล่าง

<security-domain name="LDAPAuthLocal" cache-type="default">
        <authentication>
               <login-module code="Remoting" flag="optional">
                       <module-option name="password-stacking" value="useFirstPass"/>
               </login-module>
               <login-module code="LdapExtended" flag="required">
                       <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
                       <module-option name="java.naming.provider.url" value="ldap://[IP Address]:[Port]"/>
                       <module-option name="java.naming.security.authentication" value="simple"/>
                       <module-option name="bindDN" value="CN=SystemAdmin,OU=People,dc=example,dc=com"/>
                       <module-option name="bindCredential" value="secret"/>
                       <module-option name="baseCtxDN" value="OU=Roles,dc=example,dc=com"/>
                       <module-option name="baseFilter" value="(sAMAccountName={0})"/>
                       <module-option name="rolesCtxDN" value="OU=People,dc=example,dc=com"/>
                       <module-option name="roleFilter" value="(member={1})"/>
                       <module-option name="roleAttributeID" value="sAMAccountName"/>
                       <module-option name="roleAttributeIsDN" value="true"/>
                       <module-option name="roleRecursion" value="1"/>
                       <module-option name="defaultRole" value="AllUser"/>
                       <module-option name="searchScope" value="SUBTREE_SCOPE"/>
                       <module-option name="allowEmptyPasswords" value="false"/>
                       <module-option name="throwValidateError" value="true"/>
               </login-module>
        </authentication>
</security-domain>

ระบุโดเมนความปลอดภัย JBoss ในไฟล์ jboss-web.xml ให้ระบุโดเมนความปลอดภัยที่จําเป็น ดูตัวอย่างด้านล่าง

<jboss-web>
    <security-domain>java:/jaas/LDAPAuthLocal</security-domain>
</jboss-web>

Open ID เป็นโปรโตคอลการรับรองความถูกต้องแบบมาตรฐานแบบเปิดและแบบกระจายอํานาจ เป็นเลเยอร์การตรวจสอบสิทธิ์ที่ด้านบนของ OAuth 2.0 OpenID อนุญาตให้ผู้ใช้ใช้บัญชีที่มีอยู่เพื่อลงชื่อเข้าใช้หลายเว็บไซต์โดยไม่จําเป็นต้องสร้างรหัสผ่านใหม่ ผู้ใช้สร้างบัญชีโดยเลือกผู้ให้บริการข้อมูลประจําตัว OpenID แล้วใช้บัญชีเหล่านั้นเพื่อลงชื่อเข้าใช้เว็บไซต์ใดๆ ที่ยอมรับการรับรองความถูกต้องของ OpenID องค์กรขนาดใหญ่หลายแห่งออกหรือยอมรับ OpenID บนเว็บไซต์ของตนตาม OpenID Foundation

การเชื่อมต่อ Open ID ต้องใช้ actors 3 คน

• Open ID Provider - เป็นเซิร์ฟเวอร์การอนุญาตที่สามารถตรวจสอบผู้ใช้ปลายทางและให้ข้อมูลที่จําเป็นแก่แอปพลิเคชันที่ร้องขอข้อมูล

• Relying Party - แอปพลิเคชันไคลเอ็นต์ร้องขอการรับรองความถูกต้องของผู้ใช้ปลายทางและข้อมูลเกี่ยวกับผู้ใช้ปลายทาง

• End-User - ผู้เข้าร่วมที่เป็นมนุษย์ได้รับการรับรองความถูกต้องและผู้ที่ฝ่ายที่พึ่งพากําลังขอข้อมูล

จากเวอร์ชัน 4.0.19.10 IAM2 ใน ONEWEB ยอมรับการรับรองความถูกต้อง Open ID เวอร์ชันปัจจุบันรองรับการตอบสนองเพียง 4 ประเภท: Code, Access Token, ID Token & none

Response Type: Code เมื่อตั้งค่าประเภทการตอบกลับเป็นรหัส ระบบจะส่งคืนรหัสการให้สิทธิ์ คอมโพเนนต์เซิร์ฟเวอร์ของ Relying Party สามารถแลกเปลี่ยนรหัสเป็นโทเค็นที่ต้องการได้

Response Type: Token เมื่อชนิดการตอบกลับถูกตั้งค่าเป็นโทเค็น จะทริกเกอร์โฟลว์โดยนัยและส่งคืนโทเค็นการเข้าถึงไปยังฝ่ายที่พึ่งพาโดยตรง โทเค็นการเข้าถึงคือข้อมูลประจําตัวที่ใช้ในการเข้าถึงทรัพยากรที่มีการป้องกัน โทเค็นการเข้าถึงแสดงถึงขอบเขตและระยะเวลาการเข้าถึงที่เฉพาะเจาะจง

Response Type: ID Token เมื่อประเภทการตอบกลับถูกตั้งค่าเป็น id_token จะทริกเกอร์โฟลว์โดยนัยและส่งคืนโทเค็น ID ไปยังฝ่ายที่พึ่งพาโดยตรง โทเค็น ID มีการอ้างสิทธิ์เกี่ยวกับการรับรองความถูกต้องของผู้ใช้ปลายทางและข้อมูลประจําตัวของพวกเขา โดยอาจมีข้อมูลอื่นๆ เกี่ยวกับผู้ใช้ปลายทาง ฝ่ายที่พึ่งพาที่ต้องการรับข้อมูลเพิ่มเติมเกี่ยวกับผู้ใช้ปลายทางจําเป็นต้องแสดงโทเค็นการเข้าถึงที่ได้รับไปยังตําแหน่งข้อมูลผู้ใช้

Response Type: none เมื่อประเภทการตอบกลับถูกตั้งค่าเป็นไม่มี ผู้ร้องขอไม่ต้องการให้ส่งคืนรายการใดๆ ข้างต้น

ประเภทการตอบสนอง "none" เป็นกรณีพิเศษที่ไม่สามารถใช้ร่วมกับประเภทอื่นได้ อีกสามตัวสามารถรวมกันในแบบที่คุณต้องการ แต่ IAM2 เวอร์ชันปัจจุบันไม่รองรับประเภทการตอบสนองแบบผสม สําหรับการใช้ประเภทการตอบกลับแบบผสม โปรดรอ IAM2 รุ่นในอนาคต

เมื่อลงทะเบียนรหัสไคลเอ็นต์กับ ONEWEB แล้วผู้ใช้สามารถใช้การตรวจสอบสิทธิ์ Open ID ผ่าน IAM2 ดังที่แสดงในคําขอตัวอย่างด้านล่าง