模块  java.security.jgss
软件包  org.ietf.jgss

Class GSSManager

  • public abstract class GSSManager
extends Object
    此类充当其他重要GSS-API类的工厂，还提供有关所支持机制的信息。 它可以创建实现以下三个GSS-API接口的类的实例： GSSName ， GSSCredential和GSSContext 。 它还具有查询可用机制列表和每种机制支持的名称类型的方法。

    可以通过静态方法getInstance获得默认GSSManager子类的实例，但是应用程序可以自由地实例化GSSManager其他子类。 除了任何其他实例外，默认的GSSManager实例还将支持Kerberos v5 GSS-API机制。 该机制由Oid“1.2.840.113554.1.2.2”标识，并在RFC 1964中定义。

    扩展GSSManager抽象类的子类可以实现为基于模块化提供者的层，其利用一些众所周知的服务提供者规范。 GSSManager API允许应用程序在此类实现上设置提供程序首选项。 这些方法还允许实现在不支持基于提供程序的配置的情况下抛出明确定义的异常。 期望可移植的应用程序应该意识到这一点并通过捕获异常来干净地恢复。

    设想将有三种最常用的供应商使用方式：

    1. 应用程序不关心使用什么提供程序（默认情况）。
    2. 应用程序希望特定提供程序优先用于特定机制或始终使用，而不管机制如何。
    3. 应用程序希望尽可能使用本地配置的提供程序，但如果缺少一个或多个机制的支持，那么它希望回退到自己的提供程序。

    GSSManager类有两种启用这些使用模式的方法： addProviderAtFront和addProviderAtEnd 。 这些方法具有创建<provider，oid>对的有序列表的效果，其中每对指示给定oid的提供者的偏好。

    值得注意的是，GSSManager创建的不同GSS-API对象之间存在某些交互，其中用于特定机制的提供程序可能需要在所有对象之间保持一致。 例如，如果GSSCredential包含来自机制m的提供者p的元素，则通常应将其传递给将使用提供者p作为机制m的GSSContext。 一个最大化可移植性的简单经验法则是不应混合使用从不同GSSManager创建的对象，如果应用程序想要在已创建对象的GSSManager上调用addProviderAtFront方法，则应创建不同的GSSManager实例。 。

    以下是一些示例代码，显示了如何使用GSSManager： 

      GSSManager manager = GSSManager.getInstance();

     Oid krb5Mechanism = new Oid("1.2.840.113554.1.2.2");
     Oid krb5PrincipalNameType = new Oid("1.2.840.113554.1.2.2.1");

     // Identify who the client wishes to be
     GSSName userName = manager.createName("duke", GSSName.NT_USER_NAME);

     // Identify the name of the server. This uses a Kerberos specific
     // name format.
     GSSName serverName = manager.createName("nfs/foo.sun.com",
                                             krb5PrincipalNameType);

     // Acquire credentials for the user
     GSSCredential userCreds = manager.createCredential(userName,
                                             GSSCredential.DEFAULT_LIFETIME,
                                             krb5Mechanism,
                                             GSSCredential.INITIATE_ONLY);

     // Instantiate and initialize a security context that will be
     // established with the server
     GSSContext context = manager.createContext(serverName,
                                                krb5Mechanism,
                                                userCreds,
                                                GSSContext.DEFAULT_LIFETIME);

    服务器端可能使用此源的以下变体： 

      // Acquire credentials for the server
     GSSCredential serverCreds = manager.createCredential(serverName,
                                             GSSCredential.DEFAULT_LIFETIME,
                                             krb5Mechanism,
                                             GSSCredential.ACCEPT_ONLY);

     // Instantiate and initialize a security context that will
     // wait for an establishment request token from the client
     GSSContext context = manager.createContext(serverCreds);
    从以下版本开始：
    1.4
    另请参见：
    GSSName ， GSSCredential ， GSSContext

    • 构造方法详细信息

      • GSSManager

        public GSSManager()

    • 方法详细信息

      • getInstance

        public static GSSManager getInstance()
        返回默认的GSSManager实现。
        结果
        GSSManager实现

      • getMechs

        public abstract Oid[] getMechs()
        返回通过此GSSManager可供GSS-API调用者使用的机制列表。 从getInstance()方法获得的默认GSSManager在其列表中包括Oid“1.2.840.113554.1.2.2”。 此Oid标识RFC 1964中定义的Kerberos v5 GSS-API机制。
        结果
        与可用机制相对应的Oid对象数组。 没有机制可用时返回null值（例如，当机制是动态配置的时候，当前没有安装机制）。

      • getNamesForMech

        public abstract Oid[] getNamesForMech​(Oid mech)
                               throws GSSException
        返回指定机制支持的名称类型。

        默认的GSSManager实例包括对Kerberos v5机制的支持。 当表明该机制（“1.2.840.113554.1.2.2”），则返回的列表将包含至少以下nametypes： GSSName.NT_HOSTBASED_SERVICE ， GSSName.NT_EXPORT_NAME和Kerberos V5具体的OID“1.2.840.113554.1.2.2.1”。 Oid“1.2.840.113554.1.2.2.1”的命名空间在RFC 1964中定义。

        参数
        mech - 要查询的机制的Oid
        结果
        与机制支持的名称类型对应的Oid对象数组。
        异常
        GSSException - 包含以下主要错误代码： GSSException.BAD_MECH GSSException.FAILURE
        另请参见：
        getMechsForName(Oid)

      • getMechsForName

        public abstract Oid[] getMechsForName​(Oid nameType)
        返回支持指定名称类型的机制列表。

        在Kerberos v5机制（“1.2.840.113554.1.2.2”）将始终在此列表中，当指示NAMETYPE是一个返回GSSName.NT_HOSTBASED_SERVICE ， GSSName.NT_EXPORT_NAME ，或“1.2.840.113554.1.2.2.1”。

        参数
        nameType - 要查找的名称类型的Oid
        结果
        与支持指定名称类型的机制对应的Oid对象数组。 如果找不到支持指定名称类型的机制，则返回null 。
        另请参见：
        getNamesForMech(Oid)

      • createName

        public abstract GSSName createName​(String nameStr,
                                   Oid nameType)
                            throws GSSException
        将字符串名称从指定名称空间转换为GSSName对象的工厂方法。 通常，创建的GSSName对象将包含名称的多个表示形式，每个表示支持的机制; 两个例外情况是，当命名空间类型参数指示NT_EXPORT_NAME或GSS-API实现不是多机制时。 建议不要将此方法与NT_EXPORT_NAME类型一起使用，因为将先前导出的由任意字节组成的名称表示为String可能会导致字符编码方案出现问题。 在这种情况下，建议将字节直接传递给此方法createName的重载形式。
        参数
        nameStr - 表示要创建的名称的可打印形式的字符串。
        nameType - Oid指定所提供的可打印名称的名称空间。 null可用于指定检查nameStr的每个机制应采用特定于机制的默认可打印语法。 建议不要将nametype NT_EXPORT_NAME与此方法一起使用。
        结果
        表示指示主体的GSSName
        异常
        GSSException -包含以下主要错误代码： GSSException.BAD_NAMETYPE ， GSSException.BAD_NAME ， GSSException.BAD_MECH ， GSSException.FAILURE
        另请参见：
        GSSName ， GSSName.NT_EXPORT_NAME

      • createName

        public abstract GSSName createName​(byte[] name,
                                   Oid nameType)
                            throws GSSException
        将包含指定名称空间名称的字节数组转换为GSSName对象的工厂方法。 通常，创建的GSSName对象将包含名称的多个表示形式，每个支持的机制一个; 两个例外情况是，当命名空间类型参数指示NT_EXPORT_NAME或GSS-API实现不是多机制时。 传入的字节由每个底层机制根据其为给定nametype选择的某种编码方案进行解释。
        参数
        name - 包含要创建的名称的字节数组
        nameType - Oid指定字节数组中提供的名称的名称空间。 null可用于指定检查字节数组的每个机制应采用特定于机制的默认语法。
        结果
        表示指示主体的GSSName
        异常
        GSSException -包含以下主要错误代码： GSSException.BAD_NAMETYPE ， GSSException.BAD_NAME ， GSSException.BAD_MECH ， GSSException.FAILURE
        另请参见：
        GSSName ， GSSName.NT_EXPORT_NAME

      • addProviderAtFront

        public abstract void addProviderAtFront​(Provider p,
                                        Oid mech)
                                 throws GSSException
        此方法用于向GSSManager指示当需要对给定机制提供支持时，应用程序希望特定提供程序在所有其他提供程序之前使用。 当使用null值而不是机制的Oid ，无论机制是什么，GSSManager必须先使用指示的提供者。 只有当指示的提供者不支持所需的机制时，GSSManager才会转移到其他提供者。

        重复调用此方法会保留较旧的设置，但会优先降低它们，从而形成一个有序的提供者列表和Oid在顶部的Oid对。

        使用null Oid调用addProviderAtFront将删除在GSSManager实例中为此提供程序设置的所有先前首选项。 使用非null Oid调用addProviderAtFront将删除使用此机制和此提供程序一起设置的任何先前首选项。

        如果GSSManager实现不支持具有可插入提供程序体系结构的SPI，则应抛出GSSException，其状态代码为GSSException.UNAVAILABLE，以指示操作不可用。

        假设一个应用程序希望在需要任何机制时首先检查提供者A，它会调用： 

          GSSManager mgr = GSSManager.getInstance();
         // mgr may at this point have its own pre-configured list
         // of provider preferences. The following will prepend to
         // any such list:

         mgr.addProviderAtFront(A, null);
        现在，如果它还希望在检查先前设置的A之前始终从提供者B获得Oid m1的机制，它将调用： 
          mgr.addProviderAtFront(B, m1);
        然后GSSManager首先检查B是否需要m1。 如果B不提供对m1的支持，GSSManager将继续检查A.如果需要任何机制m2，其中m2与m1不同，那么GSSManager将跳过B并直接用A检查。

        假设稍后对同一GSSManager实例进行以下调用： 

          mgr.addProviderAtFront(B, null)
        那么先前的对（B，m1）设置被包含在内，应该被删除。 有效地，首选项列表现在变为{（B，null），（A，null），... //后跟预先配置的列表。

        但请注意以下电话： 

          mgr.addProviderAtFront(A, m3)
        不包含先前的（A，null）设置，列表将有效地变为{（A，m3），（B，null），（A，null），...}
        参数
        p - 需要机械支持时应使用的提供程序实例。
        mech - 正在为其设置提供程序的机制
        异常
        GSSException -包含以下主要错误代码： GSSException.UNAVAILABLE ， GSSException.FAILURE

      • addProviderAtEnd

        public abstract void addProviderAtEnd​(Provider p,
                                      Oid mech)
                               throws GSSException
        此方法用于向GSSManager指示如果找不到支持给定机制的其他提供程序，则应用程序将希望使用特定提供程序。 当使用null值而不是机制的Oid时，GSSManager必须使用指示的提供程序用于任何机制。

        重复调用此方法会保留较旧的设置，但会优先将它们提升到较新的设置之上，从而形成一个有序的提供者列表和在底部增长的Oid对。 因此，在此之前将首先使用较旧的提供者设置。

        如果以前存在的任何首选项与此处设置的首选项冲突，则GSSManager应忽略此请求。

        如果GSSManager实现不支持具有可插入提供程序体系结构的SPI，则应抛出GSSException，其状态代码为GSSException.UNAVAILABLE，以指示操作不可用。

        假设应用程序希望当需要Oid m1的机制时，首先检查系统默认提供程序，并且只有当它们不支持m1时才应检查提供程序A. 然后它会打电话： 

          GSSManager mgr = GSSManager.getInstance();
         mgr.addProviderAtEnd(A, m1);
        现在，如果它还希望在检查了所有已配置的提供程序后检查提供程序B的所有机制，则它将调用： 
          mgr.addProviderAtEnd(B, null);
        有效地，首选项列表现在变为{...，（A，m1），（B，null）}。

        假设稍后对同一GSSManager实例进行以下调用： 

          mgr.addProviderAtEnd(B, m2)
        然后使用该对（B，null）的先前设置包含此项，因此应忽略此请求。 如果对已存在的（A，m1）或（B，null）对进行请求，则会发生相同的情况。

        但请注意以下电话： 

          mgr.addProviderAtEnd(A, null)
        不包含在先前的（A，m1）设置中，列表将有效地变为{...，（A，m1），（B，null），（A，null）}
        参数
        p - 需要机械支持时应使用的提供程序实例。
        mech - 正在为其设置提供程序的机制
        异常
        GSSException -包含以下主要错误代码： GSSException.UNAVAILABLE ， GSSException.FAILURE