Java是否应该自动使用Kerberos ticketCache? [英] Java automatically uses Kerberos ticketCache when it shouldn't?

问题描述

我们有一个可以与外部服务对话的服务器端应用程序.是否使用呼叫我们的用户的凭据，预先配置的凭据对这些服务进行身份验证取决于我们的配置.

We have a server side application that can talk to external services. It depends on our configuration whether we authenticate against those services with the credentials of the user who called us, with pre-configured credentials, or not at all.

外部服务可以使用HTTP协商身份验证.对于我们的自定义HTTP/WebDAV请求，我们使用Apache HttpClient，在这里我们在自己的控制下处理凭据.但是对于JAX-WS调用(或由第三方库调用的纯HTTP URL)，Java的HttpUrlConnection本身处理身份验证.这是事情变得奇怪的地方.

The external services may use HTTP Negotiate authentication. For our custom HTTP/WebDAV requests, we use Apache HttpClient, where we have the credentials handling under our own control. But for JAX-WS calls (or plain HTTP URLs called by 3rd party libs), Java's HttpUrlConnection handles the authentication itself. This is where things get odd.

据说Java总是尝试使用当前主题中的Kerberos凭据进行协商.很好，可以.它还可以使用票证缓存(即，kinit会话或系统会话，如果可以访问)，但是如果我正确阅读了文档(*)，则它只能在以下两种情况下使用:

Java supposedly always tries to use the Kerberos credentials from the current subject for Negotiate. That's fine, and works. It can also use the ticket cache (i.e. the kinit session or the system session, if accessible), BUT if I read the documentation (*) correctly, it should do so only on two conditions:

*) https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/lab/part6.html

1. javax.security.auth.useSubjectCredentialsOnly明确设置为false
2. 提供了一个自定义的JAAS配置，该配置将useTicketCache显式设置为true

这不会发生.在我们的可重现测试中，如果主题为空，则默认情况下始终使用系统凭据.更糟糕的是，将useSubjectCredentialsOnly显式设置为true(应为默认值)不会更改此行为.到目前为止，我们发现的唯一解决方法是显式提供一个自定义的JAAS配置，该配置将useTicketCache设置为false(再次应为默认值).

This is not what happens. In our reproducible tests, it defaults to always using the system credentials if the subject is empty. Worse, explicitly settings useSubjectCredentialsOnly to true (which should be the default) doesn't change this behaviour. The only workaround we've found so far is explicitly providing a custom JAAS config which sets useTicketCache to false (which again should be the default).

调试到Krb5LoginModule显示，除非我们配置此替代方法，否则登录模块实际上确实会被useTicketCache = true调用.

Debugging into Krb5LoginModule shows that, unless we configure this workaround, the login module does in fact get called with useTicketCache=true.

我们可以在所有Windows系统上重现此内容.似乎Linux可能表现良好，但由于域问题，我无法详细验证这一点.

We can reproduce this on all our Windows systems. It seems Linux might be behaving fine, but I haven't been able to verify this in detail (due to domain issues).

我阅读文档有误吗?还是Java实现中存在错误?还是我们的Windows系统很奇怪?

Am I reading the documentation wrong? Or is there a bug in the Java implementation? Or are our Windows systems wonky?

似乎非常不理想的是，我们必须告诉客户始终配置一种变通办法，以防止Java使用服务用户(而不是将请求发送给我们的用户)的凭据秘密调用远程服务.

It seems very much not ideal that we should have to tell our customers to always configure a workaround to prevent Java from secretly calling remote services with the credentials of the service user instead of the user who sent the request to our service.

推荐答案

至少在我刚刚调试过的Linux上的Java 8 u 131代码中，函数sun.security.jgss.GSSUtil.useSubjectCredsOnly(GSSCaller caller)是如果调用方是 HttpCaller 的实例，则进行硬编码以返回 false .

At least in the Java 8 u 131 code on Linux I have just been debugging, the function sun.security.jgss.GSSUtil.useSubjectCredsOnly(GSSCaller caller) is hard-coded to return false if the caller is an instance of HttpCaller.

对于其他类型的调用者，将检查javax.security.auth.useSubjectCredsOnly属性.

For other types of caller the javax.security.auth.useSubjectCredsOnly property is checked.

这篇关于Java是否应该自动使用Kerberos ticketCache?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！