有没有办法在Java或命令行UTIL以获得使用本机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?

问题描述

我想实现单点登录使用Kerberos在Java中，并已成功地设法创建使用的机票从Windows登录该服务的票证。不幸的是，我只能创建票证时，注册表项allowtgtsessionkey已启用。我收到了一个例外，当我禁用它消息标识符不匹配预期值（906）。该注册表项被记录在<一个href="http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html">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?

感谢您的帮助， memminger

Thanks for your help, memminger

更新：我在这个问题上放弃。 Windows注册表键prevents接入到票务（更精确地说：主题）票证缓存中。 Java的Windows上使用自己的GSSAPI实施，我想这需要访问的机票创建服务票证。该SSPI的Windows API虽然已经完全进入到售票高速缓存，从而可以创建服务票证。此API（根据<一个所使用的web浏览器，但它不使用爪哇href="http://java.sun.com/developer/technicalArticles/J2SE/security/#3">http://java.sun.com/developer/technicalArticles/J2SE/security/#3).当我在Firefox中禁用SSPI已经访问的网页一次（这样的服务票证已创建）后，我仍然可以访问该页面，所以也许一个命令行UTIL就足够了创建使用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类型系统的问题是，客户端直接验证到（单独）的认证服务器，并获得从它的票证。然后将其传递票到目标服务器（多个）它要使用，其中每个验证该票证有效的认证服务器。如果门票有效，则可以假设由客户端psenting可接受凭据（可信）Kerberos服务器仅得到它由$ P $服务器

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或命令行UTIL以获得使用本机SSPI API的服务的Kerberos票据？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！