描述
此類機制的其中一個示例就是Kerberosv5GSS-API機制（對象標識符1.2.840.113554.1.2.2）。此機制可以通過GSSManager類的默認實例獲取。
GSS-API以一種獨立於語言的方式在"RFC2743"中定義。Java語言綁定在"RFC2853"中定義。
應用程式通過實例化GSSManager啟動，然後GSSManager充當安全上下文的工廠。應用程式可以使用那些也可以利用GSSManager創建的特定主體名稱和憑據；或者還可以使用系統默認值實例化上下文。然後檢查上下文創建環路。一旦與同位體一起建立了上下文，也就完成了驗證。諸如完整性和機密性的數據保護則可以從此上下文中獲取。
GSS-API與同位體之間不進行任何通信。它只產生應用程式必須以某種方式傳輸給其他端的標記。
接口摘要
GSSContext此接口將封裝GSS-API安全上下文，並提供可通過上下文提供的安全服務。
GSSCredential此接口將為實體封裝GSS-API憑據。
GSSName此接口將封裝單一的GSS-API主體實體。
類摘要
ChannelBinding此類封裝關於調用者提供的通道綁定信息的概念。
GSSManager此類作為其他重要GSS-API類的工廠，並且還提供有關受支持的機制的信息。
MessageProp這是一個在per-messageGSSContext方法中使用的、用來傳送per-message屬性的實用工具類。
Oid此類表示UniversalObjectIdentifiers（通用對象標識符，即Oid）及其相關的操作。
異常摘要
GSSException每當發生GSS-API錯誤（包括任何特定於機制的錯誤）時，都會拋出此異常。
憑據獲取
GSS-API本身並不指示基礎機制如何獲取驗證所必需的憑據。它假定，在調用GSS-API之前獲取這些憑據，並將其存儲在一個機制提供者知道的地方。不過，Java平台中的默認模型將是這樣的：機制提供者必須僅從私有或公共憑據集中獲取憑據，這些憑據集與當前訪問控制上下文中的Subject相關。Kerberosv5機制將在私有憑據集中搜尋需要的INITIATE和ACCEPT憑據（KerberosTicket和KerberosKey），而其他機制可能要在公共集（或兩者）中查找。如果需要的憑據未在當前Subject的適當集合中，則GSS-API調用一定會失敗。
此模型具有憑據管理簡單、可從應用程式角度預知這一優勢。具有適當許可權的應用程式可以使用標準的Java API 清除Subject中的憑據或更新它們。如果應用程式清除了這些憑據，就可以確保JGSS機制失敗，如果它更新了基於時間的憑據，就可以確保JGSS機制能夠成功。
此模型要求執行JAASlogin，以便對JGSS機制稍後可以利用的Subject進行驗證並登錄。不過，應用程式能夠通過以下系統屬性放寬此限制：javax.security.auth.useSubjectCredsOnly。默認情況下，將假定此系統屬性為true（即便在未設定時也是如此），以指示提供者必須僅使用當前Subject中存在的憑據。不過，如果通過應用程式將此屬性顯式設定為false，則表示該提供者可以隨意使用它所選擇的任何憑據快取。此類憑據快取可以是磁碟快取、記憶體快取，抑或僅僅是當前Subject本身。
