远程 Web 应用程序对当前 Web 应用程序中的用户进行身份验证的最佳方式？
一些背景知识，我正在开发一个现有的 Web 应用程序，该应用程序有一组用户，他们可以使用用户名和密码等通过传统的登录屏幕登录。
最近我们成功获得了客户（拥有自己的 Intranet 站点），希望能够让其用户登录到其 Intranet 站点，然后让其用户单击其 Intranet 上的链接，该链接将重定向到我们的应用程序并自动将其登录。
到目前为止，我对如何实现这一点有两个建议：
- 创建一个带有 2 个参数（“用户名”和“密码”）的 URL，并让 Intranet 站点将这些参数传递给我们（我们的连接是通过 SSL/TLS所以都是加密的）。这可以正常工作，但似乎有点“hacky”，并且还意味着两个系统上的登录名和密码必须相同（并且必须编写某种可以更新用户密码的 Web 服务 - 这也似乎有点不安全）
- 向 Intranet 提供令牌，因此当客户端单击 Intranet 上的链接时，它会将令牌以及用户名（无密码）发送给我们，这意味着它们已通过身份验证。同样，这听起来有点老套，因为这本质上不是与为每个人提供相同的登录密码相同吗？
总而言之，我追求以下目标：
- 一种让已经在内联网上经过身份验证的用户登录到我们的系统而无需太多麻烦，并且无需使用外部系统进行身份验证（即 LDAP / Kerberos）的
- 方法对于这个客户端来说并不是太具体，并且可以很容易地由其他内网实现登录
So a bit of background, I'm working on an existing web application which has a set of users, who are able to log in via a traditional login screen with a user name and password, etc.
Recently we've managed to score a client (who have their own Intranet site), who are wanting to be able to have their users log into their Intranet site, and then have their users click a link on their Intranet which redirects to our application and logs them into it automatically.
I've had two suggestions on how to implement this so far:
- Create a URL which takes 2 parameters (which are "username" and "password") and have the Intranet site pass those parameters to us (our connection is via SSL/TLS so it's all encrypted). This would work fine, but it seems a little "hacky", and also means that the logins and passwords have to be the same on both systems (and having to write some kind of web service which can update the passwords for users - which also seems a bit insecure)
- Provide a token to the Intranet, so when the client clicks on a link on the Intranet, it sends the token to us, along with the user name (and no password) which means they're authenticated. Again, this sounds a bit hacky as isn't that essentially the same as providing everyone with the same password to log in?
So to summarise, I'm after the following things:
- A way for the users who are already authenticated on the Intranet to log into our system without too much messing around, and without using an external system to authenticate, i.e. LDAP / Kerberos
- Something which isn't too specific to this client, and can easily be implemented by other Intranets to log in
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
即使您使用 SSL，您建议的两个选项也不安全。切勿在 URL 上传递凭据，而是使用 POST 将它们放入 HTTP 请求中。
有一个名为 SAML 的标准，它可以用来解决您的问题。挑战在于选择要实施的版本。我会选择 SAML 2.0。
Google Apps 实现 SAML 2.0 风格并允许您使用以下方式进行身份验证您的内联网凭据。就您的应用程序而言，您将是服务提供商，而您的客户将是身份提供商。只要正确实施该标准，您就应该能够支持任何新客户端（身份提供商）。以下是您可能想要查看的 SAML 实现的列表在。如果您需要客户端传递除身份验证信息之外的信息，那么 SAML 可以通过元数据来实现这一点。
您仍然需要实施 SSL 来加密网络流量。
Both of your suggested options are insecure, even if you use SSL. Never pass credentials on a URL, put them in the HTTP request by using POST.
There is a standard called SAML and this can be used to solve your problem. The challenge is choosing which version to implement. I would choose SAML 2.0.
Google Apps implements a flavor of SAML 2.0 and allow you to authenticate using your intranet credentials. In the case of your application, you would be the service provider and your client would be the identity provider. As long as you implement the standard correctly you should be able to support any new client (identity provider). Here is a list of SAML implementations you might want to take a look at. If you need the client to pass over information in addition to the authentication information then SAML can facilitate this with metadata.
You will still need to implement SSL to encrypt network traffic.
我讨厌回答自己的问题，但我更讨厌没有答案的问题。最后，我们采用了与 SalesForce 的委托身份验证 SSO 实现非常相似的实现。
http://wiki.developerforce.com/page/How_to_Implement_Single_Sign-On_with_Force.com
本质上，该解决方案有一个受信任的站点，称为委派身份验证机构，该站点拥有登录公司 Intranet 的用户列表。
当用户登录公司内网并单击指向我们应用程序的链接时，公司内网会将用户名和生成的令牌（在设定的时间后过期）传递到我们的应用程序。
然后，我们的应用程序将检查用户名是否在我们的网站上，如果是，则将用户名/令牌（以及源 IP 和一些其他参数）发送到委托的身份验证机构。如果所有这些项目都与委派的身份验证机构匹配，则返回 true 并且用户可以登录。如果返回 false，则拒绝用户访问。
我们发现这个系统运行得很好，甚至还实现了一些额外的安全功能，如 SSL、客户端证书、VPN 隧道，甚至限制可以访问站点的 IP 地址和委派的身份验证机构。
我知道回答你自己的问题是不好的形式，但我希望这可以帮助其他可能遇到同样问题的人......
I hate to answer my own question, but I hate even more a question with no answer. In the end we went with a very similar implementation of SalesForce's delegated authentication SSO implementation.
http://wiki.developerforce.com/page/How_to_Implement_Single_Sign-On_with_Force.com
Essentially the solution has a trusted site, known as the delegated authentication authority, who has a list of users who are logged into the company intranet.
When the user logs into the company intranet, and they click a link to our application, the company intranet will pass the user name and a generated token (which expires after a set amount of time) to our application.
Our application will then check if the user name is on our site, and if so, send the username / token (along with the source IP and a few other parameters) to the delegated authentication authority. If all those items match on the delegated authentication authority, it returns true and the user can log in. If it returns false the user is denied access.
We've found this system to work quite well, and even implemented a couple of extra security features like SSL, client side certificates, VPN tunnel, and even restricting the IP addresses which can access the site and the delegated authentication authority.
I know it's bad form to answer your own question but I hope this helps someone else who might be having the same problem ...