Module java.security.jgss
Package org.ietf.jgss
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调用必须失败。
这种模型的优点是从应用程序的角度来看，凭证管理是简单且可预测的。应用程序在获得适当权限后，可以清除Subject中的凭证或使用标准Java API对其进行更新。如果清除了凭证，可以确保JGSS机制会失败，或者如果更新了基于时间的凭证，则可以确保JGSS机制会成功。
这种模型要求执行JAAS登录以进行身份验证并填充一个Subject，以便稍后JGSS机制可以利用。但是，应用程序可以通过系统属性：javax.security.auth.useSubjectCredsOnly来放宽此限制。默认情况下，假定此系统属性为true（即使未设置），表示提供者必须仅使用当前Subject中存在的凭证。但是，如果应用程序将此属性显式设置为false，则表示提供者可以自由使用其选择的任何凭证缓存。这样的凭证缓存可以是磁盘缓存、内存中的缓存，甚至只是当前Subject本身。
相关文档
有关使用Java GSS-API的在线教程，请参阅JAAS和Java GSS-API简介。- 自版本:
- 1.4
-
ClassDescription该类封装了提供的调用者提供的通道绑定信息的概念。该接口封装了GSS-API安全上下文，并提供可通过上下文获得的安全服务。该接口封装了实体的GSS-API凭证。每当发生GSS-API错误时（包括任何机制特定错误），都会抛出此异常。该类充当其他重要的GSS-API类的工厂，并提供有关支持的机制的信息。该接口封装了单个GSS-API主体实体。这是一个实用程序类，在每个消息的GSSContext方法中使用，以传达每个消息的属性。该类表示通用对象标识符（Oids）及其关联操作。