【问题标题】:How can multiple web apps be able to jointly use the same data from an identity database?多个 Web 应用程序如何能够共同使用身份数据库中的相同数据?
【发布时间】:2017-08-28 18:20:08
【问题描述】:

问题实际上是,例如,服务于 JWT 的身份验证服务器如何被同一公司或域的多个网站(将网站作为子域)使用?不是为公众准备的。

我已经在考虑不对称 JWT。另外,我不想实现 OAuth 2.0 以避免复杂性,因为身份验证服务器只会提供属于同一根域的子域的 Web 应用程序。

【问题讨论】:

  • 您已经问过这个问题,然后将其删除。你不喜欢这些回复吗?
  • @nurdyguy 感谢您注意到这一点。我删除了那篇文章,因为它似乎与单点登录有关……但我正在根据这篇文章中的当前描述寻找不太复杂的解决方案。 IE。涉及从各种 ASP.NET Web 应用程序连接到远程 ASP.NET Identity 数据库的解决方案。
  • 是的。 Web API 支持 cookie 和会话支持,因此您可以将该层放置在安全数据库上,并基本上创建一个表单身份验证系统,该系统可以在多个应用程序之间进行单点登录。
  • 如果用户登录其中一个应用程序,他们是否会自动在所有其他应用程序上进行身份验证?

标签: c# asp.net sql-server asp.net-mvc asp.net-identity


【解决方案1】:

根据本文中的当前描述寻求不太复杂的解决方案

如果您想要一种可靠且安全的方式在不同站点之间共享资源,您可能需要查看IdentityServer

简而言之,您基本上将匿名用户重定向到身份服务器以登录。登录成功后,会返回一个token给用户。然后用户使用该令牌访问来自不同站点的资源。

my GitHub sample project查看基本工作流程和屏幕截图。

【讨论】:

  • 使用单独的身份服务器应用程序绝对是处理此类事情的最佳方式。不幸的是,我认为这是一个比他正在寻找的更复杂的答案。这是我会做的。
  • 好吧,告诉您的客户,如果没有适当的知识和测试,不应该创建自制单点登录。这会导致一个很大的安全漏洞。
  • @Win 感谢您的帖子。即使它是[或可能是]对我有用的可能解决方案,我只是以突出显示的形式更新了我的问题。请根据我的更新重新考虑提供其他回复。
  • 请检查我的问题的“更新 2”。
  • 我刚刚用更新 3 更新了帖子。请检查一下。
【解决方案2】:

好的,这就是交易。

  1. 多个网络应用程序可以访问同一个数据库(身份数据库或其他)吗?当然!现在,如果您使用的是实体框架(尽管没有说明,但我假设您是),那么就迁移等而言,这可能会变得很棘手。我个人使用 Dapper,所以我永远不必担心 :-)

    是的,每个应用程序都可以访问数据库,但 WAY 与 SingleSignOn 不同,SingleSignOn 是 真正 您正在谈论的。您希望用户登录到一个站点,并且该身份保留到其他完全不同的站点。这不像简单地访问数据库那么简单。出于许多原因,IdentityServer 实际上是此类事物的标准。

  2. 不,ajax 方法将不起作用,因为当用户在 site1 登录时,cookie 是针对 site1 的。如果他访问 site2,即使您通过 ajax 发送了凭据,浏览器也没有与 site2 关联的任何 cookie。当这一切发生时,用户在 site1,所以所有 cookie 都是 site1 cookie,与 site2 cookie 完全分开。即使您能找到一种方法来完成这项工作,它也会带来严重的安全风险。

    您可以使用隐藏的 IFrame 而不是 ajax 来执行类似的操作,因为您可以在其中设置 iframe 网站的 cookie。但我不建议您这样做,因为存在安全风险。

您需要将“身份验证”的概念与“授权”甚至“用户管理”的概念分开。

身份验证----我是我所说的我吗? (检查我的用户名和密码,甚至可能是短信等其他形式)

授权---- 好的,你知道我是谁,但是我可以在你的网站上做什么?这可能因站点而异。也许我是您的一个网站的管理员,但只是另一个网站的普通用户。我的个人站点 cookie 将包括角色等,并且每个站点都不同。

用户管理----我可以更改我的姓名/电子邮件/等吗?

处理此问题的最佳方法是使用运行 IdentityServer 的单独服务器应用程序。这将处理身份验证并立即为您的所有网站构建 cookie。理想情况下,您也应该将其用于任何用户管理,但这可能会很痛苦并且不是那么重要。以下是 IdentityServer4 的一些示例应用程序。


响应您的更新 2----

不完全...这是基本流程:用户转到site1并单击“登录”。这会引发一个“挑战”,将它们重定向到网站身份验证。在 website-auth 上,用户通过表单提交提交他们的凭据(用户名/密码)。这会将他们登录到 website-auth,但随后也会将用户重定向回原始调用应用程序(在本例中为 site1)以及他们需要的一切。假设用户现在去site2,他们已经登录了!!!使用 IdentityServer4,用户将自动登录到所有网站。您不必按照您描述的方式做额外的事情,只需插入必要的东西,让 IdentityServer4 处理其余的事情。

看,我知道 IdentityServer4 可能看起来有点吓人,在我开始使用它之前它对我来说确实如此。事实是,所有困难的事情都为您处理。设置它仍然涉及大量配置,但它确实是您正在寻找的最佳解决方案。

查看这些快速入门:https://github.com/IdentityServer/IdentityServer4.Samples/tree/release/Quickstarts


对Update3的响应-----

我理解依赖第三方的担忧,以及这似乎是一种有问题的做法,尤其是在安全方面。我的回答是这样的:

  1. 这些人是该领域的专家。以至于即使在 Macrosoft 提供的基本模板中,IdentityServer 也已成为事实上的安全解决方案。

  2. 您想出的任何本地解决方案都将存在比 IdentityServer 更多的安全漏洞。这根本不是对你的轻视。这些家伙知道他们在做什么。他们已经这样做了

  3. 为什么要重新发明轮子?您将花费 10 倍(至少)的工时来尝试提出一个最终仍然不会那么好的替代方案。

如果您所做的是基于单个网站 cookie 的身份验证,那么使用身份确实没有必要。身份可以做到这一点,但还有其他简单的选择。但是当涉及到多个站点和 SSO 时,我真的不能再强调这一点,IdentityServer 是要走的路。

【讨论】:

  • 感谢您的回复。很明显,我对绕过 CORS 的想法是不现实的。我仍然会用另一个更新来更新这个问题,这将表达我想到的一个新的解决方法。我所说的“用户管理”是指您的意思,就是它的含义,包括登录任何网络应用程序的管理员创建用户配置文件等的能力。
  • 请检查我的问题的“更新 2”。
  • 再次感谢您的指导。我已经检查了 IdentityServer,它似乎是一个付费解决方案,在某种程度上,但我会检查更多,看看我可以将多少用于我的目的。
  • 有些公司将这类事情作为服务提供,但 IdentityServer 本身是开源且免费的。
  • 好的。感谢您的回复。顺便说一句,我刚刚用更新 3 更新了帖子。请也检查一下。
【解决方案3】:

答案是微服务身份验证服务,它使用私钥生成 RSA/非对称 JWT,其他服务器每个都有相同的对应公钥来验证 JWT 并检索用户声明。

但该解决方案不能满足每个其他服务器需要一组不同的关于用户的声明的情况。

这也不是单点登录方法。所以,我会回来的。

但 OAuth 2.0 似乎是答案,但它对我来说太复杂了。

【讨论】:

  • 由于有多个登录入口点,我未选中作为查看它的答案。但除此之外,这是最接近我的问题的答案。
猜你喜欢
  • 2018-01-12
  • 1970-01-01
  • 1970-01-01
  • 2010-09-17
  • 1970-01-01
  • 1970-01-01
  • 2019-09-22
  • 1970-01-01
  • 2016-02-12
相关资源
最近更新 更多