See: 描述
| 接口 | 描述 |
|---|---|
| GSSContext |
该接口封装了GSS-API安全上下文，并提供了可用于上下文的安全服务。
|
| GSSCredential |
该接口封装了实体的GSS-API凭据。
|
| GSSName |
该接口封装了单个GSS-API主体实体。
|
| 类 | 描述 |
|---|---|
| ChannelBinding |
该类封装了主叫方提供的通道绑定信息的概念。
|
| GSSManager |
该类作为其他重要GSS-API类的工厂，并提供有关支持的机制的信息。
|
| MessageProp |
这是在每消息GSSContext方法中使用的实用程序类，用于传递每消息属性。
|
| Oid |
该类表示通用对象标识符（Oid）及其相关联的操作。
|
| 异常 | 描述 |
|---|---|
| GSSException |
发生GSS-API错误时会抛出此异常，包括任何机制特定的错误。
|
在RFC 2743中，GSS-API以独立于语言的方式定义 。 Java语言绑定在RFC 2853中定义
一个应用程序是通过实例化一个GSSManager开始的，然后GSSManager作为安全上下文的工厂。 应用程序可以使用也使用GSSManager创建的特定主体名称和凭据; 或者可以使用系统默认值实例化上下文。 然后通过上下文建立循环。 一旦与对等体建立上下文，则认证完成。 然后可以从这个上下文获得数据保护，如完整性和机密性。
GSS-API不与对等体进行任何通信。 它只是产生令牌，应用程序必须以某种方式运输到另一端。
Subject在当前的访问控制上下文中。
Kerberos v5机制将在私有凭证集中搜索所需的INITIATE和ACCEPT凭据（ KerberosTicket和KerberosKey ），其中一些其他机制可能在公共集合或两者中查找。
如果所需凭证不存在于当前主题的适当集合中，则GSS-API调用必须失败。
这种模式的优点是从应用的角度来看，凭据管理是简单和可预测的。 给予正确权限的应用程序可以清除主题中的凭据，或者使用标准的Java API来更新它们。 如果它清除了凭据，那么确保JGSS机制将失败，或者如果它重新启动基于时间的凭证，那么将确保JGSS机制能够成功。
该模型确实要求执行一个JAAS login ，以验证和填充JGSS机制以后可以使用的主题。 然而，应用程序有能力通过系统属性来放宽此限制： javax.security.auth.useSubjectCredsOnly 。 默认情况下，该系统属性将被假定为true （即使未设置），表示提供程序只能使用当前主题中存在的凭据。 但是，如果应用程序将此属性显式设置为false，则表示提供程序可以自由使用其选择的任何凭据缓存。 这样的凭证缓存可以是磁盘高速缓存，内存中高速缓存，甚至是当前的主题本身。
有关使用Java GSS-API的在线教程，请参阅Introduction to JAAS and Java GSS-API 。