Web 应用程序的单点登录
一个多月以来我一直试图了解这个问题是如何解决的。我真的需要想出一个有效的通用方法。我有一个理论，但我不确定这是最简单（或正确）的方法，而且我无法找到任何信息来支持我的想法。
场景如下：
1) 您有一个复杂的 Web 应用程序，它以订阅方式提供安全内容。
2) 用户需要使用用户名和密码登录您的应用程序。
3) 您向大公司销售产品，这些公司已经拥有企业身份验证技术（例如 Active Directory）。
4) 您希望与企业身份验证机制集成，以允许其用户无需输入用户名和密码即可登录您的 Web 应用程序。
现在，您提出的任何解决方案都必须提供一种机制：
- 添加新用户
- 删除用户
- 更改用户信息
- 允许用户登录
理想情况下，当企业客户对其自己的身份验证进行相应更改时，所有这些都会“自动”发生。
现在，我有一个理论，做到这一点的方法（至少对于 Active Directory）是我编写一个客户端应用程序，该应用程序与客户的 Active Directory 集成以跟踪目标更改，然后将这些更改传达给我的客户。网络应用程序。我认为，如果这种通信是通过我的网络应用程序提供的网络服务完成的，那么它将保持不可破解的安全级别，这显然是这些企业客户的要求。
我发现了一些有关名为 Active Directory 联合身份验证服务 (ADFS) 的 Microsoft 产品的信息，该方法可能适合也可能不适合我。它似乎有点笨重，并且有一些可能并不适合所有客户的要求。
对于其他现有的 ID 场景（例如 Athens 和 Shibboleth），我认为客户端应用程序是不必要的。这可能只是与现有的身份识别服务绑定的问题。
如果有人对我在这里提到的任何事情提出任何建议，我将不胜感激。特别是，如果您能告诉我关于提供与服务器端 Web 服务通信的客户端应用程序的理论是否正确，或者我是否完全走错了方向。另外，如果您可以向我指出任何解释如何执行此操作的网站或文章，我将非常感激。到目前为止，我的研究还没有取得太多成果。
最后，如果您能让我了解当前提供此服务的任何 Web 应用程序（特别是与企业 Active Directory 相关的应用程序），我将非常感激。我想知道 salesforce.com 或 hoovers.com 等其他 B2B Web 应用程序是否为其企业客户提供类似的服务。
我讨厌在黑暗中，并且非常感谢你能提供的任何光明......
杰里米
I have been trying to understand how this problem is solved for over a month now. I really need to come up with a general approach that work. I have a theory, but I'm just not sure it's the easiest (or correct) approach and I haven't been able to find any information to support my ideas.
Here's the scenario:
1) You have a complex web application that offers secure content on a subscription basis.
2) Users are required to log in to your application with user name and password.
3) You sell to large corporations, which already have a corporate authentication technology (for example, Active Directory).
4) You would like to integrate with the corporate authentication mechanism to allow their users to log onto your Web App without having to enter their user name and password.
Now, any solution you come up with will have to provide a mechanism for:
- adding new users
- removing users
- changing user information
- allowing users to log in
Ideally, all these would happen "automagically" when the corporate customer made the corresponding changes to their own authentication.
Now, I have a theory that the way to do this (at least for Active Directory) would be for me to write a client-side app that integrates with the customer's Active Directory to track the targeted changes, and then communicate those changes to my Web App. I think that if this communication were done via Web Services offered by my web app, then it would maintain an unhackable level of security, which would obviously be a requirement for these corporate customers.
I've found some information about a Microsoft product called Active Directory Federation Service (ADFS) which may or may not be the right approach for me. It seems to be a bit bulky and have some requirements that might not work for all customers.
For other existing ID scenarios (like Athens and Shibboleth), I don't think a client application is necessary. It's probably just a matter of tying into the existing ID services.
I would appreciate any advice anyone has on anything I've mentioned here. In particular, if you can tell me if my theory is correct about providing a client-side app that communicates with server-side Web Services, or if I'm totally going in the wrong direction. Also, if you could point me at any web sites or articles that explain how to do this, I'd really appreciate it. My research has not turned up much so far.
Finally, if you could let me know of any Web applications that currently offer this service (particularly as tied to a corporate Active Directory), I would be very grateful. I am wondering if other B2B Web app's like salesforce.com, or hoovers.com offer a similar service for their corporate customers.
I hate being in the dark and would greatly appreciate any light you can shed ...
Jeremy
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Shibboleth 旨在支持这种情况。但是，它将依赖于您客户的公司实施身份提供商机制。目前，这种情况只在大学里很常见。此外，如果您想要用户信息（不仅仅是假名标识符），您需要公司同意向您发布这些属性。
我很难相信许多公司会向您开放他们的企业身份验证系统，只是为了提供 SSO。
您可能会发现最好依赖 OpenID 或类似的，并使用“记住我”cookie 来减少对人们输入密码。
Shibboleth is designed to support exactly this scenario. However it will rely on your customers' companies implementing the identity provider mechanisms. At the moment, that's only really common in universities. Further, if you want user information (any more than just a pseudonymous identifier), you'd need the company to agree to release those attributes to you.
I find it hard to believe that many companies would open their corporate authentication system to you, just to provide SSO.
You might find it better to rely on OpenID or similar, and using a "remember me" cookie to reduce the need for people to enter passwords.
您的方法的一个基本问题是您正在孤立地考虑您的网络应用程序。客户公司的员工不仅需要 SSO 访问您的 Web 应用程序，还需要一些/少数/许多其他应用程序，并且扩展您的方法将需要为每个应用程序进行定制实施才能启用访问。
因此，学术图书馆界广泛采用 OpenAthens 和 Shibboleth 来利用本地颁发的凭证。典型的中型/大型大学可以订阅来自 50 多个不同发行商的各种产品/服务，并且通过部署 OpenAthens/Shibboleth，他们可以利用 SAML 开放标准（SAML 是 Shibboleth 使用的协议），该标准的使用率正在不断提高。不仅在学术领域，在商业领域也同样如此。
John 的上述回答指出了另一个问题：最近出现了许多开放标准，其中包括 SAML 和 OpenID。因此，内容提供商必须决定是否要在本地实现部分或全部这些内容，但他们使用单独的技术堆栈，因此实现和支持成本可能会重复。
相当多的主要发布商已经实施了 OpenAthens，因为这支持 Athens 中，也可以选择插入其他技术，或编写自定义模块以允许内部应用程序连接，例如记录客户用户正在登录的发票或权利系统。
、SAML/Shibboleth 和 OpenID 在单一平台 访问管理的肯定正在朝着开放标准发展，因此构建您自己的方法将剥夺大量用户对您的应用程序的访问权限
One basic problem with your approach is that you're considering your web app in isolation. Employees at your client's company won't just require SSO to your web app but also some/few/many others, and extending your approach would require a bespoke implementation for each of those to enable access.
Hence the widespread adoption of OpenAthens and Shibboleth in the academic library community to leverage the use of locally-issued credentials. A typical medium/large university can subscribe to various products/services from more than fifty different publishers, and by deploying OpenAthens/Shibboleth they can take advantage of the SAML open standard (SAML is the protocol that Shibboleth uses) that is seeing increased take-up not only in the academic sector, but also in the commercial sector.
John's answer above points to another issue: there are a number of open standards that have recently emerged, SAML and OpenID among them. So content providers are having to decide whether they want to implement some or all of these natively, but they use separate technology stacks and so the implementation and support costs can be duplicated.
Quite a few major publishers have implemented OpenAthens as this supports Athens, SAML/Shibboleth and OpenID in a single platform, with options to plug in other technologies too, or writing a custom module to allow an internal app to connect, e.g. an invoicing or entitlements system recording which clients' users are logging in.
This sector of access management is definitely moving towards open standards, so building your own method would be depriving access to your app for a large number of users