SSO 的 HTTP 标头中的用户名
我希望向我的一个 Web 应用程序添加单点登录 (SSO)。我现在不想做任何繁重的事情，我只想知道登录用户的 userId，而不需要他们输入用户名。
该网络应用程序是一个内部应用程序，因此我可以保证它们来自 Windows PC 等。
我已经查看过 jCIFS，但这似乎不再受支持，并推荐商业产品。
我还查看了 WAFFLE，但我正在为 playframework 应用程序构建 SSO，该应用程序不使用 Servlet 堆栈，因此我无法使用 SecurityFilter。我试图理解 WindowsLoginModule，但无法真正理解我必须做什么才能实现它。
是否可以只从 HTTP 标头获取用户名，或者在发布标头之前是否需要先进行一些协商？
I am looking to add single sign on (SSO) to one of my web applications. I don't want anything heavy at the moment, I just want to know the userId of the logged in user, without the need for them to enter a username.
The web app is an internal application, so I can guarantee they are coming from a Windows PC etc.
I have looked at jCIFS, but this doesn't seem to be supported any more, and recommends a commercial product.
I have also looked at WAFFLE, but I am building SSO for a playframework application, which does not use a Servlet stack, so I can't make use of the SecurityFilter. I have tried to make sense of the WindowsLoginModule, but couldn't really understand what I had to do to implement it.
Is it possible to just get the username from the HTTP header, or does it require some negotiation first before it will post the header?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
非繁重的答案
听起来应该可以让您的运营团队实施一个组策略，它将登录的用户名作为 HTTP 标头发送到网络上。
否则，您的假设是正确的，即 IE 和您的服务器之间存在某种协商“舞蹈”。请参阅此处。也许您可以在 Play 代码中伪造这种舞蹈。
沉重的答案
我知道jCIFS和此示例使用 servlet 和过滤器，但可以提取重要的代码位，并可以构建自定义 Play Authenticator（我可以粘贴Scala 示例覆盖
play.api.mvc.Security.Authenticated，但您的答案标记为 Java）。您只需要请求标头（而不是正文），因此它应该在身份验证器中可行。PS jCIFS 似乎在您发帖后进行了更新，所以我假设你会重新考虑使用黑客攻击它。我也对未维护的库持谨慎态度，但有时它们只是达到了成熟度和稳定性，从而减少了对更多更新的需求。
Non-heavy answer
It sounds like it should be possible to get your ops team to implement a Group Policy which will send the logged-in username down the wire as an HTTP Header.
Otherwise, you're correct in your assumption that there is some sort of negotiation "dance" between IE and your server. See here. Perhaps you can fake this dance in your Play code.
Heavy answer
I know jCIFS and this example uses servlets and filters, but the important bits of code can be extracted and a custom Play Authenticator can be built (I can paste a Scala example override of
play.api.mvc.Security.Authenticated, but your answer is tagged Java). You only need the request headers (not body) so it should be doable in an authenticator.PS jCIFS seems to have had an update since your post, so I'm presuming you'd reconsider using hacking it. I'm wary of unmaintained libraries too, but sometimes they just reach a maturity and stability which alleviates the need for any more updates.
Active Directory 使用 Kerberos，因此所有登录用户都应该拥有 kerberos 票证。
快速谷歌发现了这个：
如果您想要 Windows 登录详细信息，我认为这是您唯一的选择。
Active Directory uses Kerberos, so all logged in users should have a kerberos ticket.
A fast google found this:
If you want the windows logon details, I think it's your only option.
您可以尝试使用 Shiro 在您的应用程序中启用 SSO。
Shiro id 独立于 servlet，并且由于您的框架不支持 Servlet，您可以很容易地使用 Shiro。
您可以创建一个定义 hashPassword 的领域。
您可以配置用户名和 hashPassword，并要求 shiro 使用 hashPassword 对您的用户进行身份验证。
然后，您将为用户分配角色，这将服务于您的 SSO 目的。
您可以对多个应用程序的用户进行身份验证，因此当用户登录到另一个应用程序时，shiro 已经对您进行了身份验证，因此它会立即将您登录到该应用程序中。
您可以浏览 shiro 文档（详尽无遗，您应该能够从以下链接首次配置它：-
http://shiro.apache.org/
为您提供许多开箱即用的身份验证和授权功能以及安全和加密模块。
You can try to use Shiro for enabling SSO in your application.
Shiro id independent of the servlets and since your framework does not support Servlets you can very easily go for Shiro.
You can create a Realm where you define the hashPassword.
You can configure the username and the hashPassword and ask the shiro to authenticate your user with the hashPassword.
You will then assign role for the user which will serve your purpose of SSO.
You can authenticate user for more than one application and hence when user logs into another application the shiro has already authenticated you and hence it will straight away log you inside the application..
You can go through the shiro documentation(exhaustive and you should be able to configure it on first go) from the following link:-
http://shiro.apache.org/
It provides you many out of the box functionality for authenticating and authorization along with security and Cryptography modules.
用户名不会在标头中发送。即使是这样，也不应该依赖它，因为精明的用户可能会伪造这些值。
The username isn't sent in the header. Even if it was this shouldn't be relied upon as a savvy user could fake the values.
如果 NTLM 对您来说是一个有效的选择，Jespa 可能是 JCIFS 的一个不错的替代方案。 Jespa（与 JCIFS 不同）支持 NTLM v2 等。它的有限版本（最多 25 个用户）是免费的。
If NTLM would be a valid option for you Jespa might be a good alternative to JCIFS. Jespa (unlike JCIFS) supports NTLM v2, among other things. The limited version of it (up to 25 users) is free.
您始终可以从过滤器中获取任何标头。请参阅 HttpServletRequest 的 javadoc。
You can always get any header from filter. See javadoc for HttpServletRequest.
您希望 Windows 用户自动登录您的 Intranet Web 应用程序。因此，用户帐户将位于活动目录中，通常的微软方式是使用像 NTML 或 Kerberos。尽管有些企业仍在使用 NTML（和 jCIFS）进行 SSO，但通常建议应用程序不要使用 NTLM。
对 Kerberos 和 Java 的快速搜索显示了这个 文章。它似乎依赖于 Java EE 堆栈 (JAAS)。
对于更精简的方法：通常，您无法以可移植的方式在 http 请求中发送用户名。使用 ActivX，您可以执行以下操作：
在服务器端，您可以解析 http 标头并使用您选择的技术提取用户名。
那么，安全性在您的 playframework 应用程序中并不重要吗？
为什么不使用长期存在的 cookie？
希望有帮助！
You want the windows user to automagically login to your intranet webapp. So the user accounts would sit in an active directory and the usual microsoft way would be to use a protocol like NTML oder Kerberos. Applications are generally advised not to use NTLM, although there are enterprises still using NTML (and jCIFS) for SSO.
A quick search on Kerberos and Java showed this article. It seems to depend on the Java EE stack (JAAS).
For a more stripped down approach: Usually, you cannot sent the username in a http request in a portable way. With ActivX you could do:
On the server side, you can parse the http header and extract the username with your technology of choice.
Well, security doesn't matter in your playframework application?
Why don't you use long-living cookies?
Hope it helps!
在域中注册了 ActiveDirectory 和工作站的 Intranet 环境中，HTTP SPNEGO
Negotiation支持是最佳选择。但它需要有关 ActiveDirectory 和 Java Kerberos 实现的特定技能。Spring Security 提供了实现和文档来进行设置。但
Secure.Security并非旨在支持基于令牌的身份验证（如 HTTP 协商）。因此使用 Spring Security 需要特定的集成模块。其他选项有 OpenID 和 shibboleth 但两者都需要专用服务器，可以将其配置为执行 SPNEGO 本身。由于有了可用的 Play 模块，您的应用程序中的集成将变得更加容易。
在不进行客户端复杂和不安全/不可靠调整的情况下在 HTTP 标头中获取用户名的唯一方法是在浏览器和应用程序服务器之间使用身份验证代理。大多数这些代理还支持 Kerberos SPNEGO 作为身份验证方式。
In an intranet context with ActiveDirectory and workstations registered in the domain, the HTTP SPNEGO
Negotiationsupport is the best option. But it requires specific skills around ActiveDirectory and Java Kerberos implementation.Spring Security provides implementation and documentation to set it up. But
Secure.Securityis not designed to support token-based authentication like HTTP Negotiation. So using Spring Security will require a specific integration module.Other options are OpenID and shibboleth but both requires a dedicated server, which can be configured to do SPNEGO itself. Thanks to available Play modules, integration in your application will be easier.
The only way to get the username in an HTTP header without client-side complex and unsecure/unreliable tweaks is to use an authentication proxy between browsers and your application server. Most of these proxies also support Kerberos SPNEGO as authentication mean.