SSO 最佳实践：无法访问 IDP 的解决方案是什么？
这是与此关于一般 SSO 最佳实践的问题类似的内容。 处理残疾或由于某种原因无法访问的中央身份提供商的最佳方法是什么？ 如果您的网站允许用户使用集中存储的凭据登录，并且中央服务无法正常工作或无法访问，您是否：
允许用户在本地站点上重新输入其凭据，以便他们可以使用本机登录Web 应用程序（或内容管理系统或其他）的设施
允许用户请求可以在 Web 应用程序本身上使用的另一组辅助凭据（即，当 IDP 关闭时他们可以使用单独的密码）[注意：显然，这违背了“单一凭据”目标抛弃所有想法]。
- 用户使用相同凭据的多个不同维护者中的任何一个登录（通过为他们提供多个提供者的多个链接，然后尝试每个提供者，直到其中一个真正连接并工作）
出于可能明显的原因，这些上面的解决方案似乎很有吸引力，因此在您用最佳替代方法回答时，请随意将这些解决方案放入“最差实践”列表中。
Here's something similar to this question on general SSO best-practices. What is the best approach for dealing with a disabled or for-whatever-reason-unreachable central identity provider. If your website allows users to login with their centrally-stored credentials, and the central service is not working or unreachable do you:
Allow users to re-enter their credentials on the local site, so that they can use the native login facility of the web application (or content management system or whatever)
Allow users to request another secondary set of credentials that they can use on the web application itself (i.e., a separate password they can use when the IDP is down) [NOTE: obviously this defeats the 'single credentials' goal just tossing out all ideas].
Allow the users to login using any of several various maintainers of the same credentials (by giving them multiple links to multiple providers, and then trying each one of them until one of them actually connects and works)
For probably apparent reasons, none of these solutions above seem attractive, so feel free to put these on the "worst practices" list while you answer with the best alternative approach.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为最好的方法是采用去中心化 SSO，就像 Open ID 中实现的那样。 如果每个帐户可以有多个提供程序，那么如果一个提供程序出现故障，您可以故障转移到另一个提供程序。
另一方面，如果需要集中式 SSO。 我唯一能想到的就是让中央机构为每个用户生成一个加密证书。 如果服务具有证书吊销列表的最新副本和中央机构公钥的缓存副本，则即使中央机构不可用，它也可以验证证书。 不幸的是，这种方法可能会遇到可用性问题，因为用户既需要随身携带证书副本，又需要在您要求时知道您在说什么。
I'd think the best way would be to have decentralized SSO, as is implemented in Open ID. If each account can have many providers, then if one provider goes down, you can fail over to another.
On the other hand, if centralized SSO is required. The only thing that I can think of would be to have the central authority generate a cryptographic certificate for each user. If the service has a fresh copy of the certificate revocation list and a cached copy of the central authority's public key, it can validate certificates even if the central authority is unavailable. Unfortunately, this method would probably suffer from usability issues as users would need to both keep a copy of their certificate handy and know what you're talking about when you ask for it.