อิน เทอร์เฟซการ เขียน โปรแกรมแอปพลิเคชันบริการความปลอดภัยทั่วไป ( GSSAPIหรือGSS-API ) เป็นอินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชันสำหรับโปรแกรมในการเข้าถึงบริการความปลอดภัย^{[ 1 ]}

GSSAPI เป็นมาตรฐานของIETFที่แก้ไขปัญหาบริการรักษาความปลอดภัยที่คล้ายคลึงกันแต่เข้ากันไม่ได้จำนวนมากที่ใช้งานอยู่ตั้งแต่ปี 2005

GSSAPI เองไม่ได้ให้ความปลอดภัยใดๆ แต่ผู้ให้บริการด้านความปลอดภัยจะจัดเตรียมการใช้งาน GSSAPI ซึ่งโดยปกติจะอยู่ในรูปแบบของไลบรารีที่ติดตั้งมาพร้อมกับซอฟต์แวร์ด้านความปลอดภัย ไลบรารีเหล่านี้จะนำเสนออินเทอร์เฟซที่เข้ากันได้กับ GSSAPI ให้กับผู้เขียนแอปพลิเคชัน ซึ่งสามารถเขียนแอปพลิเคชันของตนให้ใช้เฉพาะ GSSAPI ที่ไม่ขึ้นกับผู้จำหน่าย เท่านั้น หากจำเป็นต้องเปลี่ยนการใช้งานด้านความปลอดภัย แอปพลิเคชันก็ไม่จำเป็นต้องเขียนใหม่^{[ 2 ]}

คุณลักษณะเด่นของแอปพลิเคชัน GSSAPI คือการแลกเปลี่ยนข้อความทึบแสง ( โทเค็น ) ซึ่งซ่อนรายละเอียดการใช้งานจากแอปพลิเคชันระดับสูงกว่า^{[ 3 ]}ฝั่งไคลเอนต์และเซิร์ฟเวอร์ของแอปพลิเคชันถูกเขียนขึ้นเพื่อส่งต่อโทเค็นที่ได้รับจากการใช้งาน GSSAPI ของแต่ละฝั่ง โทเค็น GSSAPI สามารถเดินทางผ่านเครือข่ายที่ไม่ปลอดภัยได้ เนื่องจากกลไกต่างๆ ให้ความปลอดภัยของข้อความโดยธรรมชาติ หลังจากแลกเปลี่ยนโทเค็นจำนวนหนึ่งแล้ว การใช้งาน GSSAPI ที่ปลายทั้งสองด้านจะแจ้งให้แอปพลิเคชันในพื้นที่ทราบว่าบริบทความปลอดภัยได้รับการสร้างขึ้นแล้ว

เมื่อมีการสร้างบริบทด้านความปลอดภัยแล้ว ข้อความแอปพลิเคชันที่ละเอียดอ่อนสามารถถูกห่อหุ้ม (เข้ารหัส) โดย GSSAPI เพื่อการสื่อสารที่ปลอดภัยระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ การป้องกันทั่วไปที่รับประกันโดยการห่อหุ้ม GSSAPI ได้แก่การรักษาความลับ (ความลับ) และความสมบูรณ์ (ความถูกต้อง) ^{[ 4 ]} GSSAPI ยังสามารถให้การรับประกันในพื้นที่เกี่ยวกับตัวตนของผู้ใช้ระยะไกลหรือโฮสต์ระยะไกลได้อีกด้วย

GSSAPI อธิบายถึงการเรียกใช้ฟังก์ชันประมาณ 45 รายการ รายการที่สำคัญ ได้แก่:

GSS_Acquire_cred

เพื่อขอหลักฐานยืนยันตัวตนของผู้ใช้ ซึ่งมักจะเป็นรหัสลับทางคริปโตกราฟี

ชื่อการนำเข้า GSS_Import_name

แปลงชื่อผู้ใช้หรือชื่อโฮสต์ให้เป็นรูปแบบที่ระบุตัวตนของหน่วยงานด้านความปลอดภัย

GSS_Init_sec_context

สร้างโทเค็นไคลเอ็นต์เพื่อส่งไปยังเซิร์ฟเวอร์ ซึ่งโดยปกติจะเป็นโทเค็นท้าทาย

GSS_ยอมรับ_บริบทความปลอดภัย

ประมวลผลโทเค็นจากGSS_Init_sec_contextและสามารถสร้างโทเค็นตอบกลับเพื่อส่งคืนได้

GSS_Wrap

แปลงข้อมูลแอปพลิเคชันให้เป็นโทเค็นข้อความที่ปลอดภัย (โดยทั่วไปจะเข้ารหัส)

GSS_Unwrap

แปลงโทเค็นข้อความที่ปลอดภัยกลับเป็นข้อมูลแอปพลิเคชัน

GSSAPI ได้รับการกำหนดมาตรฐานสำหรับ ภาษา C (RFC 2744) Javaใช้ GSSAPI ^{[ 5 ]} เป็น JGSS ^{[ 6 ]} ซึ่งเป็น อินเทอร์เฟซโปรแกรมแอปพลิเคชันบริการความปลอดภัยทั่วไปของ Java ^{[ 7 ]}

ข้อจำกัดบางประการ^{[ 8 ]}ของ GSSAPI ได้แก่:

1. กำหนดมาตรฐานเฉพาะการตรวจสอบสิทธิ์ เท่านั้น ไม่ใช่การอนุญาตด้วย
2. โดยสมมติว่าใช้สถาปัตยกรรมแบบไคลเอ็นต์-เซิร์ฟเวอร์

เพื่อเตรียมพร้อมรับมือกับกลไกความปลอดภัยใหม่ๆ GSSAPI จึงมีกลไกเสมือน สำหรับการเจรจาต่อรองที่ เรียกว่าSPNEGOซึ่งสามารถค้นหาและใช้งานกลไกใหม่ๆ ที่ไม่มีอยู่เมื่อแอปพลิเคชันดั้งเดิมถูกสร้างขึ้นได้

ภาษาต่างๆ ใช้งาน GSSAPI Javaมีคุณสมบัติเหล่านี้ในแพ็ก เก จไลบรารีมาตรฐาน^{[ 9 ]}org.ietf.jgss.*

กลไกการใช้งาน GSSAPI ที่โดดเด่นคือKerberosซึ่งแตกต่างจาก GSSAPI ตรงที่ API ของ Kerberos ยังไม่ได้รับการกำหนดมาตรฐาน และการใช้งานที่มีอยู่ต่างๆ ใช้ API ที่ไม่เข้ากัน GSSAPI อนุญาตให้การใช้งาน Kerberos เข้ากันได้กับ API ^{[ 10 ]}

• รัศมี
• SASL
• ทีแอลเอส
• SSPI
• สปเนโก้
• อาร์พีซีซีซี จีเอสเอส

ชื่อ

สตริงไบนารีที่ใช้ระบุหลักการรักษาความปลอดภัย (เช่น ผู้ใช้หรือโปรแกรมบริการ) - ดูการควบคุมการเข้าถึงและข้อมูลประจำตัวตัวอย่างเช่นKerberosใช้ชื่อเช่นuser@REALMสำหรับผู้ใช้ และservice/hostname@REALMสำหรับโปรแกรม

คุณสมบัติ

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

บริบท

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

โทเค็น

ข้อความที่ไม่โปร่งใสซึ่งแลกเปลี่ยนกันไม่ว่าจะเป็นส่วนหนึ่งของโปรโตคอลการตรวจสอบสิทธิ์เบื้องต้น (โทเค็นระดับบริบท) หรือเป็นส่วนหนึ่งของการสื่อสารที่ได้รับการปกป้อง (โทเค็นต่อข้อความ)

กลไก

การใช้งาน GSSAPI พื้นฐานที่ให้ชื่อจริง โทเค็น และข้อมูลประจำตัว กลไกที่เป็นที่รู้จัก ได้แก่Kerberos , NTLM , Distributed Computing Environment (DCE), SESAME, SPKMและ LIPKEY

ผู้เริ่มต้น/ผู้รับ

ฝ่ายที่ส่งโทเค็นแรกจะเป็นผู้ริเริ่ม ส่วนอีกฝ่ายจะเป็นผู้รับ โดยทั่วไปแล้ว โปรแกรมไคลเอ็นต์จะเป็นผู้ริเริ่ม ในขณะที่เซิร์ฟเวอร์จะเป็นผู้รับ

• กรกฎาคม 1991: คณะทำงานเทคโนโลยีการตรวจสอบความถูกต้องทั่วไป (CAT) ของ IETF ประชุมกันที่แอตแลนตา โดยมีจอห์น ลินน์ เป็นประธาน
• กันยายน 1993: GSSAPI เวอร์ชัน 1 (RFC 1508, RFC 1509)
• พฤษภาคม 1995: Windows NT 3.51 ออกวางจำหน่าย พร้อมฟีเจอร์ SSPI
• มิถุนายน 1996: กลไก Kerberos สำหรับ GSSAPI (RFC 1964)
• มกราคม 1997: GSSAPI เวอร์ชัน 2 (RFC 2078)
• ตุลาคม 1997: SASL ได้รับการเผยแพร่ โดยมีกลไก GSSAPI รวมอยู่ด้วย (RFC 2222)
• มกราคม 2000: การอัปเดต GSSAPI เวอร์ชัน 2 1 (RFC 2743, RFC 2744)
• สิงหาคม 2547: คณะทำงาน KITTEN ประชุมเพื่อดำเนินกิจกรรม CAT ต่อไป
• พฤษภาคม 2549: การใช้งาน GSSAPI ใน Secure Shell ได้รับการกำหนดมาตรฐาน (RFC 4462)

• พีเคซีเอส #11

• RFC  2743 API บริการความปลอดภัยทั่วไป เวอร์ชัน 2 อัปเดต 1
• RFC  2744 API บริการความปลอดภัยทั่วไป เวอร์ชัน 2: C-Bindings
• RFC  1964กลไก Kerberos 5 GSS-API
• RFC  4121กลไก Kerberos 5 GSS-API: เวอร์ชัน 2
• RFC  4178กลไกการเจรจา GSS-API แบบง่ายและปลอดภัย (SPNEGO)
• RFC  2025กลไก API GSS กุญแจสาธารณะแบบง่าย (SPKM)
• RFC  2847 LIPKEY - กลไกคีย์สาธารณะที่มีโครงสร้างพื้นฐานต่ำโดยใช้ SPKM
• "เทคโนโลยีการตรวจสอบสิทธิ์ทั่วไปรุ่นต่อไป (kitten)"คณะทำงานด้านวิศวกรรมอินเทอร์เน็ตกันยายน 2556
• Sun Microsystems (2002). "คู่มือการเขียนโปรแกรม GSS-API — Sun Solaris 9" . Oracle Corporation .
• บริษัท ออราเคิล คอร์ปอเรชั่น (2020). "การเขียนแอปพลิเคชันที่ใช้ GSS-API — Oracle Solaris 11.4, คู่มือสำหรับนักพัฒนาด้านความปลอดภัย "