Module  java.security.jgss
软件包  org.ietf.jgss

Class GSSManager


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

    默认GSSManager子类的实例可以通过静态方法getInstance获得 ，但应用程序可以自由地实例化其他子类的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​()
        返回GSS-API调用者通过此GSSManager可用的机制列表。 从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对象的Factory方法。 通常，创建的GSSName对象将包含多个表示形式的名称，每个支持的机制一个; 两个例外是这个例外，当命名空间类型参数指示NT_EXPORT_NAME或GSS-API实现不是多机制时。 不建议将此方法与NT_EXPORT_NAME类型一起使用，因为将以前导出的名称组合为字符串的任意字节可能会导致字符编码方案出现问题。 在这种情况下，建议将字节直接传递到此方法createName的重载形式。
        参数
        nameStr - 表示要创建的名称的可打印形式的字符串。
        nameType - Oid指定提供的可打印名称的命名空间。 null可以用于指定每个检查nameStr的机制都应该具有机制特定的默认可打印语法。 使用这种方法使用数据类型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对象的Factory方法。 一般来说，创建的GSSName对象将包含多个表示形式的名称，一个用于支持的每个机制; 两个例外是这个例外，当命名空间类型参数指示NT_EXPORT_NAME或GSS-API实现不是多机制时。 根据给定的数学类型选择的一些编码方案，传入的字节由每个底层机制解释。
        参数
        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对。

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

        如果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);
        现在如果还希望Oid m1的机制始终是在提供者B之前从先前设置的A被检查之前获得的，它会调用： 
          mgr.addProviderAtFront(B, m1);
        那么GSSManager会先检查一下是否需要m1。 如果B没有提供对m1的支持，则GSSManager将继续检查A.如果在m2与m1不同的地方需要任何机制m2，则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