java - 了解和探索 JAAS-GSSAPI-JNDI 如何在后台协同工作

Question

我一直试图了解这些不同的 API 如何在幕后粘合在一起。虽然这个问题似乎是一个广泛的问题，但我也想了解一个特定的场景。对此可以进一步调试的任何指针将不胜感激。
我正在关注 基础教程 - https://docs.oracle.com/javase/jndi/tutorial/ldap/security/src/Mutual.java
在此，我特别想了解，在创建 期间，这条线的实际含义是什么。 DirContext

// Request the use of the "GSSAPI" SASL mechanism Authenticate by using already established Kerberos credentials env.put(Context.SECURITY_AUTHENTICATION, "GSSAPI");

Context.SECURITY_AUTHENTICATION 时创建 DirContext/LDAPContext 期间完成的高级步骤是什么？设置为 GSSAPI在环境哈希表中？

是否需要该主题的 TGT LDAPContext创建？

在 期间获得的 Subject 的 TGT/Subject/Private-public 凭证的作用是什么？登录上下文#login() 过程？

让我们从头开始:

 LoginContext lc = new LoginContext(...)
 lc.login() 

这段代码的作用是，它与 KDC 服务器通信，并从它那里获取一个 TGT，如果认证成功!登录上下文中填充了一个 Subject(authenticated)，其中包含凭据的所有信息。
完成后，将使用以下代码执行 JNDI。

将代码作为 Subject 的 PrivilegedAction 执行如下实际上意味着什么？

Subject.doAs(lc.getSubject(), new JndiAction(args));

我无法理解从 Subject.doAs(...) 返回的对象会发生什么？
场景:

考虑 DirContext 是由 Subject.doAs(...) 方法通过使用 PrivilegedAction{....} 返回的，以便以后可以使用上下文。

如果创建它的主题是 logged out，那么这个上下文会发生什么？或其credentials are invalidated or changed?它还会继续工作吗？

TGT 是否用于任何后来的 ctx像 search() 这样的操作还是图片中的 GSSAPI 用于这些操作中的任何一个？

Active Directory 如何验证此上下文是否有效？

需求

a. We don't want to perform any JNDI operation within the PrivilegedAction#run. We just want to return the context object which we want to cache or use later.

b. We have a peculiar requirement that we can't have on single krb.conf file due to some reasons. We create and destroy krb.conf for every subsequent request.

c. The reason for me asking question #5 is that - once the krb.conf file is re-generated as explained above, all the credentials from the in-memory LoginContext#Subject objects are invalidated and can't be used further.

d. In this case, can we use the cached context?

任何有助于了解实际工作的帮助表示赞赏

Answer 1

I am particularly trying to understand, what this line actually means, during the creation of DirContext

// Request the use of the "GSSAPI" SASL mechanism Authenticate by using already established Kerberos credentials 
env.put(Context.SECURITY_AUTHENTICATION, "GSSAPI");

这部分很简单，只是告诉 ldap 客户端使用
GSSAPI 身份验证，而不是“简单”或“无”。
虽然理论上“GSSAPI”应该支持一系列不同的实现，
在这个 Java 实现中，它只支持 kerberosV5。
简单的身份验证，只需将用户名/密码直接传递给 LDAP 服务器。
如果 LDAP 服务器不需要查询身份验证，则不会。
GSSAPI，这里使用存储在先前获得的主题中的 kerberos 凭据。

1. Is the TGT of the Subject required for this LDAPContext creation?

这将取决于 LDAP 服务器配置，但一般来说，不，它不是必需的。
要使用简单的身份验证，您可以执行以下操作:

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.SECURITY_PRINCIPAL, "Administrator@corp.example.com");
env.put(Context.PROVIDER_URL, "ldap://WIN-MKR9VI69FT4.corp.example.com/");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_CREDENTIALS, "password".toCharArray());
DirContext ctx = new InitialDirContext(env);

What is the role of the TGT/Subject/Private-public credentials of the Subject acquired during the LoginContext#login() process?

在原始示例中，它们用于获取服务票证以与 LDAP 服务器一起使用。

What does it actually mean to execute the code as the PrivilegedAction of the Subject as follows?

Java的SecurityManager建筑复杂而陈旧，
没有深入了解所有细节，这里发生的事情或多或少，
刚刚制作 Subject可用于在特权操作中运行的代码的对象。
当 kerberos 代码查找凭证时，
it checks the AccessControlContext and uses credentials from it if available .

4. Consider that the DirContext is returned by the Subject.doAs(...) method by using PrivilegedAction{....} so that the context can be used later on.

凭证/票证未绑定(bind)到 DirContext目的，
所以它不会继续工作，如果不使用 Subject.doAs .

5. What will happen to this context if the Subject through which it was created was logged out or its credentials are invalidated or changed? Will it still continue to work?

如果用户是，凭证/票证可能会或可能不会继续工作
注销或禁用，将取决于 ldap 服务器实现。

6. Are the TGTs used for any of the later ctx operations like search() or is the GSSAPI in the picture for any of these operations?

可以，但您需要通过 Subject.doAs 访问它们。 ,
它们不附加到 DirContext .
第一次访问上下文时，将使用 TGT 获取服务票证，
只要有效，该服务票将继续使用。

a. We don't want to perform any JNDI operation within the PrivilegedAction#run. We just want to return the context object which we want to cache or use later.

应该可以使用简单的身份验证。
您还可以选择使用系统 kerberos 凭证缓存，但我想这将需要更多的工作和更多的文件处理。

b. We have a peculiar requirement that we can't have on single krb.conf file due to some reasons. We create and destroy krb.conf for every subsequent request.

这并不理想，遗憾的是 Java kerberos 实现不支持任何更好的方式来使用多个 kerberos 配置。

c. The reason for me asking question #5 is that - once the krb.conf file is re-generated as explained above, all the credentials from the in-memory LoginContext#Subject objects are invalidated and can't be used further.

不正确，凭据仍然有效，但您需要将 krb.conf 更改回正确的设置
您正在使用的主题，因为在初始登录后仍会引用配置文件。

d. In this case, can we use the cached context?

可以，但您需要先将 krb5.conf 改回正确的值。
您可以调用sun.security.krb5.Config.refresh();在使用上下文之前手动，以确保加载文件配置。
配置通常仅在登录时刷新。