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 。
 Submit a bug or feature 
For further API reference and developer documentation, see Java SE Documentation. That documentation contains more detailed, developer-targeted descriptions, with conceptual overviews, definitions of terms, workarounds, and working code examples.
 Copyright © 1993, 2014, Oracle and/or its affiliates. All rights reserved.