我想在 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。
不幸的是，我无法访问将使用我的应用程序的计算机上的注册表，因此我正在寻找一种无需修改它即可执行此操作的方法。当我在 Internet Explorer 或 Mozilla Firefox 中通过 SPNEGO 进行单点登录时，它们会在我的票证缓存中创建一个服务票证，因此肯定有一种方法可以在不设置注册表项的情况下执行此操作。有谁知道如何在 Java 中做到这一点？
感谢您的帮助，
memminger
更新：我放弃这个问题。 Windows 注册表项阻止访问票证缓存内的票证（更准确地说：主题）。 Windows 上的 Java 使用自己的 GSSAPI 实现，我认为需要访问票证才能创建服务票证。不过，SSPI Windows API 可以完全访问票证缓存，因此可以创建服务票证。此 API 由 Web 浏览器使用，但 Java 不使用（根据 http://java.sun.com/developer/technicalArticles/J2SE/security/#3）。当我在访问网页一次后在 Firefox 中禁用 SSPI 时（因此已创建服务票证），我仍然可以访问该页面，因此也许命令行 util 就足以使用 SPPI API 创建服务票证。
对于我们来说，这意味着我们现在要么放弃单点登录（这对我们来说是不可接受的），要么在应用程序的客户端进行身份验证（因为我们只能读出用户名，而不能验证应用程序上的票证）。服务器），这是一个重大的安全风险。另一个例子说明更强的安全约束如何导致更大的安全漏洞，因为它们变得太复杂而无法使用。
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.
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?
Thanks for your help,
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.
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.
发布评论
评论（4）
如果我误解了您的问题，请原谅我，但是...
SSO 类型系统的要点是客户端直接向（单独的）身份验证服务器进行身份验证，并从中获取票证。然后，它将票证传递到它想要使用的目标服务器，每个目标服务器都会通过身份验证服务器验证票证是否有效。如果票证经过验证，服务器可以假设客户端仅通过向（受信任的）Kerberos 服务器提供可接受的凭据来获取票证。
在此过程中的任何地方，任何服务器都不应代表客户端进行身份验证。在这样的系统中，唯一需要知道并验证客户端凭据的服务器是身份验证服务器 - 其他服务器不需要访问此信息。这样，客户端只需进行一次身份验证交换即可对许多服务器进行身份验证，并且凭据不会因存储在多个服务器上或可由多个服务器访问而面临风险。
听起来您的实现正在正常工作 - 身份验证应该发生在应用程序的客户端，这是正确的并且不存在安全风险。
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.
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 6 中设置 sun.security.jgss.native ？ SSPI 不是 Windows 的“本机”接口吗？
Have you tried setting sun.security.jgss.native in Java 6? Wouldn't SSPI be the "native" interface for windows?
您可以通过 JNA 访问本机 SSPI API。请参阅 WAFFLE 或 WindowsAuthProviderImpl .apache.org/httpcomponents-client-ga/httpclient-win/xref/org/apache/http/impl/auth/win/WindowsNegotiateScheme.html" rel="nofollow">WindowsNegotiateScheme 来自 Apache HC 库一个例子。
You can access the native SSPI API via JNA. See the WindowsAuthProviderImpl in WAFFLE or WindowsNegotiateScheme from the Apache HC library for an example.
JDK 13 中引入了对 Windows SSPI 的本机支持，后来也向后移植到 JDK 11。您至少需要使用 Java 11.0.10。当使用 JDK 对 SSPI 的支持时，不再需要摆弄
allowtgtsessionkey注册表项，也不需要使用 JNA 或 Waffle。您需要设置
-Dsun.security.jgss.native=true
才能使其正常工作。
如果您的 Windows JDK 版本在
bin目录中包含名为sspi_bridge.dll的文件，您就可以识别该版本是否支持 SSPI。参考：
JDK-6722928
Native support for Windows SSPI was introduced into JDK 13 and later backported to JDK 11 too. You'll need to use at least Java 11.0.10. When the JDK's support for SSPI is used then there's no longer a need to fiddle with the
allowtgtsessionkeyregistry key, nor any need to use JNA or Waffle.You need to set
-Dsun.security.jgss.native=trueto make it work.
You can recognize if your JDK version for Windows has support for SSPI if it includes a file named
sspi_bridge.dllin thebindirectory.Refs:
JDK-6722928