Module  java.security.jgss

Package org.ietf.jgss

该软件包提供了一个框架，允许应用程序开发人员使用诸如Kerberos等各种基础安全机制（使用统一API）的身份验证，数据完整性和数据机密性等安全服务。 应用程序可以选择使用的安全机制用唯一对象标识符标识。 这种机制的一个例子是Kerberos v5 GSS-API机制（对象标识符1.2.840.113554.1.2.2）。 该机制可通过GSSManager类的默认实例获得。

GSS-API在RFC 2743中以独立于语言的方式定义 。 Java语言绑定在RFC 2853中定义

应用程序通过实例化一个GSSManager ，然后作为安全上下文的工厂。 应用程序可以使用也使用GSSManager创建的特定主体名称和凭据; 或者可以使用系统默认值实例化上下文。 然后通过上下文建立循环。 一旦与对等体建立上下文，则认证完成。 然后可以从这个上下文获得数据保护，如完整性和机密性。

GSS-API不与对等体进行任何通信。 它只是产生令牌，应用程序必须以某种方式运输到另一端。

凭证收购

GSS-API本身并不规定底层机制如何获得验证所需的凭据。 假设在调用GSS-API之前，这些凭据被获取并存储在机构提供者知道的位置。 但是，Java平台中的默认模型将是机制提供者只能从当前访问控制上下文中与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 。

从以下版本开始：
1.4