有没有办法在 Java 或命令行实用程序中使用本机 SSPI API 获取服务的 Kerberos 票证? [英] Is there a way in Java or a command-line util to obtain a Kerberos ticket for a service using the native SSPI API?

问题描述

我想在 Java 中使用 Kerberos 实现单点登录，并成功地使用 Windows 登录中的票证为服务创建了票证.不幸的是，我只能在启用注册表项allowtgtsessionkey"时创建该票证.一旦我禁用它，我就会收到消息标识符与预期值(906)不匹配"的异常.注册表项记录在 http:///java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html 和 http://support.microsoft.com/kb/308339.

I want to implement Single Sign On with Kerberos in Java and have successfully managed to create a ticket for the Service using the ticket from the Windows logon. Unfortunately, I can only create that ticket when the Registry Key "allowtgtsessionkey" is enabled. I am receiving an exception with the message "Identifier doesn't match expected value (906)" as soon as I disable it. The registry key is documented on http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html and http://support.microsoft.com/kb/308339.

很遗憾，我无法访问将使用我的应用程序的计算机上的注册表，因此我正在寻找一种无需修改即可执行此操作的方法.当我在 Internet Explorer 或 Mozilla Firefox 中通过 SPNEGO 进行单点登录时，它们会在我的票证缓存中创建一个服务票证，因此肯定有一种方法可以在不设置注册表项的情况下执行此操作.有没有人知道如何在 Java 中做到这一点?

Unfortunately I do not have access to the registry on the computers where my application will be used, so I am looking for a way to do this without having to modify it. When I do Single Sign On over SPNEGO in Internet Explorer or Mozilla Firefox, they create a Service ticket in my ticket cache, so there definitely has to be a way to do this without setting the registry key. Does anyone have an idea how to do this in Java?

感谢您的帮助，记忆者

更新:我正在放弃这个问题.Windows 注册表项阻止访问票证缓存中的票证(更准确地说:主题).Windows 上的 Java 使用它自己的 GSSAPI 实现，我想它需要访问票证来创建服务票证.尽管 SSPI Windows API 可以完全访问票证缓存，因此可以创建服务票证.Web 浏览器使用此 API，但 Java 不使用它(根据 http://java.sun.com/developer/technicalArticles/J2SE/security/#3).当我在访问一次网页后在 Firefox 中禁用 SSPI 时(因此已创建服务票证)，我仍然可以访问该页面，因此也许命令行实用程序足以使用 SPPI API 创建服务票证.

Update: I am giving up on this issue. The Windows registry key prevents the access to the Ticket (more exactly: the Subject) inside the Ticket cache. Java on Windows uses its own GSSAPI implementation, and I suppose that needs access to the Ticket to create a Service Ticket. The SSPI Windows API though has full access to the Ticket cache and can thus create Service tickets. This API is used by the web browsers, but it is not used by Java (according to http://java.sun.com/developer/technicalArticles/J2SE/security/#3). When I disable SSPI in Firefox after having accessed a web page once (so a service ticket has been created), I can still access the page, so maybe a command-line util would be sufficient that creates a service ticket using the SPPI API.

对我们来说，这意味着现在我们可以放弃单点登录(这对我们来说是不可接受的)或者我们在应用程序的客户端进行身份验证(因为我们只能读出用户名但不能验证服务器上的票证)，这是一个主要的安全风险.另一个示例，说明更强的安全约束如何导致更大的安全漏洞，因为它们变得过于复杂而无法使用.

For us, this means now that we can either abandon Single Sign On (which is unacceptable for us) or that we do the authentification on the client side of our application (because we can only read out the username but not verify the ticket on the server), which is a major security risk. Another example of how stronger security constraints lead to bigger security holes because they become too complicated to use.

推荐答案

如果我误解了你的问题，请原谅我，但是...

Forgive me if I am misunderstanding you problem, but...

SSO 类型系统的要点是客户端直接向(单独的)身份验证服务器进行身份验证，并从中获取票证.然后它将票证传递给它想要使用的目标服务器，每个目标服务器都验证票证对身份验证服务器是否有效.如果票证得到验证，则服务器可以假定客户端仅通过向(受信任的)Kerberos 服务器提供可接受的凭据来获取它.

The point of SSO type systems is that the client authenticates directly to the (separate) authentication server, and obtains a ticket from it. It then passes the ticket to the target server(s) it wants to use, each of which verify that the ticket is valid with the authentication server. If the ticket is validated, it can be assumed by the server that the client only obtained it by presenting the (trusted) Kerberos server with acceptable credentials.

在此过程中，任何服务器都应该代表客户端进行身份验证.在这样的系统中，唯一需要知道和验证客户端凭据的服务器是身份验证服务器 - 没有其他服务器需要访问此信息.通过这种方式，客户端只需进行一次身份验证交换即可对多台服务器进行身份验证，并且凭据不会因存储在多台服务器上或可供多台服务器访问而面临风险.

Nowhere in the process, should any server authenticate on behalf of the client. In such a system, the only server that needs to know and validate the client's credentials is the authentication server - no other server need have access to this information. This way the client can authenticate for many servers with just one authentication exchange, and credentials are not put at risk by being stored on, or accessible to, multiple servers.

听起来您的实现工作正常 - 身份验证应该发生在应用程序的客户端，这是正确的，没有安全风险.

It sounds like your implementation is working just as it should - the authentication should occur on the client side of the application, and this is correct and not a security risk.

这篇关于有没有办法在 Java 或命令行实用程序中使用本机 SSPI API 获取服务的 Kerberos 票证?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！