我有一个服务到服务模型,其中我有一个用于 Kerberos 身份验证的密钥表。
在这个模型中,我定义了一个登录配置如下:-
import java.util.HashMap;
import java.util.Map;
import javax.security.auth.login.AppConfigurationEntry;
import javax.security.auth.login.Configuration;
public class GSSIbmLoginConfiguration extends Configuration {
private AppConfigurationEntry configEntry;
public GSSIbmLoginConfiguration(String principal,
String credentialCache,
String keytab,
KerberosCredentialUsage usage) {
Map<String, String> params = new HashMap<String, String>();
params.put("credsType", "both");
params.put("renewable", Boolean.TRUE.toString());
params.put("principal", principal);
if (credentialCache != null) {
params.put("useCcache", credentialCache);
}
if (keytab != null) {
params.put("useKeytab", keytab);
}
configEntry = new AppConfigurationEntry(
"com.ibm.security.auth.module.Krb5LoginModule",
AppConfigurationEntry.LoginModuleControlFlag.REQUIRED, params);
}
public AppConfigurationEntry[] getAppConfigurationEntry(String name) {
return new AppConfigurationEntry[] {
configEntry
};
}
此登录配置可替代 jaas.conf
现在我正在尝试使用 LoginContext 的登录方法。然后我从中获得主题。
现在使用这个主题我做了一个特权动作。
private static final class SubjectAction implements PrivilegedExceptionAction<GSSCredential> {
private final int credentialType;
private final int credentialLifetime;
private SubjectAction(int credType, int lifetime) {
credentialType = credType;
credentialLifetime = lifetime;
}
public GSSCredential run() throws GSSException {
GSSManager gssManager = GSSManager.getInstance()
return gssManager.createCredential(null, credentialLifetime, KRB5_MECH_ID, GSSCredential.INITIATE_AND_ACCEPT);
}
}
这失败了。相关日志(我在设置日志系统属性后挖掘出来的):-
[JGSS_DBG_CRED] localhost-startStop-1 Creating mech cred for null, mech 1.2.840.113554.1.2.2, usage initiate and accept
[JGSS_DBG_PROV] localhost-startStop-1 Provider Entry: provider: IBMJGSSProvider, mechanism: 1.3.6.1.5.5.2 get Factory for mech: 1.2.840.113554.1.2.2 GSSCaller:
[JGSS_DBG_PROV] localhost-startStop-1 Provider Entry: provider: IBMJGSSProvider, mechanism: 1.2.840.113554.1.2.2 get Factory for mech: 1.2.840.113554.1.2.2 GSSCaller:
[JGSS_DBG_PROV] localhost-startStop-1 Created new (empty) factory list (size=1) for provider IBMJGSSProvider version 7.0
[JGSS_DBG_PROV] localhost-startStop-1 Loading factory
[JGSS_DBG_PROV] localhost-startStop-1 Factory class name for provider IBMJGSSProvider version 7.0 is com.ibm.security.jgss.mech.krb5.Krb5MechFactory
[JGSS_DBG_PROV] localhost-startStop-1 Prior to load
[JGSS_DBG_PROV] localhost-startStop-1 Done to load
[JGSS_DBG_PROV] localhost-startStop-1 Loaded factory for provider IBMJGSSProvider version 7.0
[JGSS_DBG_PROV] localhost-startStop-1 Loaded factory ok
[JGSS_DBG_PROV] localhost-startStop-1 getFactory: index = 1 found factory caller = com.ibm.security.jgss.GSSCaller@e7d4b6d7
[JGSS_DBG_CRED] localhost-startStop-1 usage: initiate and subject
[JGSS_DBG_CRED] localhost-startStop-1 Obtaining creds from Krb5Util.ServiceCreds for default service
[JGSS_DBG_CRED] localhost-startStop-1 Found key for isp/ISPNode1/ISPDomain@INFAKRB.INFADEV.COM(1)
[JGSS_DBG_CRED] localhost-startStop-1 Found key for isp/ISPNode1/ISPDomain@INFAKRB.INFADEV.COM(23)
[JGSS_DBG_CRED] localhost-startStop-1 Found key for isp/ISPNode1/ISPDomain@INFAKRB.INFADEV.COM(3)
[JGSS_DBG_CRED] localhost-startStop-1 Found key for isp/ISPNode1/ISPDomain@INFAKRB.INFADEV.COM(17)
[JGSS_DBG_CRED] localhost-startStop-1 acquiring creds for isp/ISPNode1/ISPDomain@INFAKRB.INFADEV.COM
现在真正令人困惑的是:-
[JGSS_DBG_CRED] localhost-startStop-1 Creating mech cred for null, mech 1.2.840.113554.1.2.2, usage initiate and accept
and then:
[JGSS_DBG_PROV] localhost-startStop-1 getFactory: index = 1 found factory caller = com.ibm.security.jgss.GSSCaller@e7d4b6d7
[JGSS_DBG_CRED] localhost-startStop-1 usage: initiate and subject
第一部分是针对 createCredential 本身的。然而,第二个似乎是一些机制工厂相关的调用(在这种情况下是 kerberos)。现在,在这个基于文件的 cred 缓存身份验证开始之后。
[KRB_DBG_CCHE] FileCredentialsCache:localhost-startStop-1: >>>KinitOptions cache name is /export/home/ispqa95/krb5cc_ispqa95
[KRB_DBG_CCHE] FileCredentialsCache:localhost-startStop-1: >>> FileCredentialsCache default name is: /export/home/ispqa95/krb5cc_ispqa95
[KRB_DBG_CCHE] FileCredentialsCache:localhost-startStop-1: >>>FileCredentialsCache: read ccache version 0x503
[KRB_DBG_KDC] KrbDataInputStream:localhost-startStop-1: >>>KrbDataInputStream: Bytes read: 0000: 49 4e 46 41 4b 52 42 2e 49 4e 46 41 44 45 56 2e INFAKRB.INFADEV.
0010: 43 4f 4d 通信
[KRB_DBG_KDC] KrbDataInputStream:localhost-startStop-1: >>> CCacheInputStream: equiv string: INFAKRB.INFADEV.COM
[KRB_DBG_CCHE] CCacheInputStream:localhost-startStop-1: >>> readPrincipal: read realm INFAKRB.INFADEV.COM
[KRB_DBG_KDC] KrbDataInputStream:localhost-startStop-1: >>>KrbDataInputStream: Bytes read: 0000: 6e 61 67 61 72 6c 61 nagarla
这意味着机制工厂以某种方式获得了错误的值。
我尝试反编译 IBM jar(ibmjgssprovider.jar),但里面的类名似乎是乱码(替换为 a、b、xy 等)。
这最终导致:- java.io.IOException: Primary principals do not match
作为专有的,我很难弄清楚 IBM 的行为。OpenJdk 的帮助很大。
有人可以帮忙吗。我的产品设置的某些系统属性是否会导致这种行为?
我正在尝试在执行时检查所有可能的系统属性。请让我知道是否需要其他东西。
也有人可以指出一些 IBM JDK 安全论坛吗?我也想在那里发布这个问题。