包 org.ietf.jgss


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 ),而其他一些机制可能会在公共凭证集中或同时在两者中查找。如果所需的凭证不存在于当前主题的适当集合中,则 GSS-API 调用必须失败。

该模型的优势在于,从应用程序的角度来看,凭据管理简单且可预测。应用程序在获得正确权限后,可以清除 Subject 中的凭据或使用标准 Java API 更新它们。如果它清除凭证,那么 JGSS 机制肯定会失败,或者如果它更新基于时间的凭证,那么 JGSS 机制肯定会成功。

此模型确实需要执行 JAAS login 以验证和填充 JGSS 机制稍后可以使用的主题。但是,应用程序可以通过系统属性放宽此限制:javax.security.auth.useSubjectCredsOnly。默认情况下,此系统属性将被假定为 true(即使未设置),指示提供者必须仅使用当前主题中存在的凭据。但是,如果此属性被应用程序显式设置为 false,则表明提供者可以自由使用其选择的任何凭据缓存。这样的凭证缓存可能是磁盘缓存、内存缓存,甚至只是当前的 Subject 本身。

有关使用 Java GSS-API 的在线教程,请参阅 JAAS 和 Java GSS-API 简介
自从:
1.4
  • 描述
    此类封装了调用者提供的通道绑定信息的概念。
    该接口封装了 GSS-API 安全上下文并提供了可通过该上下文使用的安全服务。
    此接口封装实体的 GSS-API 凭据。
    只要发生 GSS-API 错误(包括任何特定于机制的错误),就会抛出此异常。
    此类用作其他重要 GSS-API 类的工厂,还提供有关受支持机制的信息。
    该接口封装了单个 GSS-API 主体实体。
    这是在每条消息 GSSContext 方法中使用的实用程序类,用于传达每条消息的属性。
    此类表示通用对象标识符 (Oid) 及其相关操作。