Package org.ietf.jgss
该软件包提供了一个框架，允许应用程序开发人员使用统一的API从各种底层安全机制（如Kerberos）中使用安全服务，如身份验证，数据完整性和数据机密性。 应用程序可以选择使用的安全机制用唯一对象标识符标识。 这种机制的一个示例是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 ），其中某些其他机制可能在公共集中或两者中查找。 如果当前Subject的相应集合中不存在所需凭证，则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
-
接口摘要 接口 描述 GSSContext 此接口封装GSS-API安全上下文，并提供上下文中可用的安全服务。GSSCredential 此接口封装实体的GSS-API凭据。GSSName 此接口封装了单个GSS-API主体实体。 -
类摘要 类 描述 ChannelBinding 该类封装了调用者提供的通道绑定信息的概念。GSSManager 此类充当其他重要GSS-API类的工厂，还提供有关所支持机制的信息。MessageProp 这是在每个消息GSSContext方法中使用的实用程序类，用于传达每个消息的属性。Oid 此类表示通用对象标识符（Oids）及其关联的操作。 -
异常摘要 异常 描述 GSSException 每当发生GSS-API错误（包括任何特定于机制的错误）时，都会抛出此异常。