windows 有没有办法在 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?

提问by user269667

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.htmland http://support.microsoft.com/kb/308339.

我想在 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 上。

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?

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

Thanks for your help, memminger

谢谢你的帮助，memminger

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.

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

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

回答by Lawrence Dol

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

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

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.

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

Nowhere in the process, should any server authenticate on behalf ofthe 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 shouldoccur on the client side of the application, and this is correct and not a security risk.

听起来您的实现正在正常工作 - 身份验证应该在应用程序的客户端进行，这是正确的，而不是安全风险。

回答by Borealid

Have you tried setting sun.security.jgss.native in Java 6? Wouldn't SSPI be the "native" interface for windows?

您是否尝试过在 Java 6 中设置 sun.security.jgss.native？SSPI 不是 Windows 的“本机”接口吗？

回答by Malcolm Smith

You can access the native SSPI API via JNA. See the WindowsAuthProviderImplin WAFFLEor WindowsNegotiateSchemefrom the Apache HC library for an example.

您可以通过JNA访问本机 SSPI API 。见WindowsAuthProviderImpl在WAFFLE或WindowsNegotiateScheme从Apache HC库的一个例子。