>背景信息：我们已经开发了 3 个独立的 ASP.NET 应用程序，现在也作为套件出售。客户可以订购 1、2 或所有应用程序。
作为独立的应用程序，这给我们带来了挑战，我们不完全确定如何解决它：身份验证。所有应用程序都有自己的 Indentity 实现，这会强制客户创建每个用户帐户 3 次，并且用户需要为每个应用程序单独登录。因此，客户端请求 SSO 实现。
问题：我们已经对SSO进行了一些研究，Thinktecture IdentityServer看起来非常好，能够解决我们的问题。但是，用户连接到应用程序中的某些实体。我们遇到了一些问题：
- 如何确保身份服务器和三个客户端应用程序之间的一致性（或外键）？ 用户
- 需要在创建时从应用程序内可用（用户需要能够选择其他用户，即使他们尚未登录）。在身份服务器中创建用户时，我们如何确保在应用程序中创建用户？
可能我们完全走在错误的轨道上 - 还有其他解决方案来解决我们面临的问题吗？提前非常感谢..
首先，请记住，vs2013 Web 模板中有一个 OWIN 授权服务器，如果您愿意，可以将其撕成独立服务器。换句话说，Thinktecture服务器不是你唯一的选择，尽管它更强大，功能更齐全。
为了解决您手头的问题，我想到了几个选项：
- 将用户管理分解为单独的数据库和单独的 DbContext。您可以在单个集中式数据库中管理所有用户，如果将代码编写为类库，则可以重用 DbContext 和派生的 IdentityUser 类。这是处理这种情况的更简单、更快、更简单的方法。 创建
- 用于创建用户的受保护的 Web API，并将其包含在所有 3 个站点上。对标识用户管理器进行子类化，并调用其他两个站点，以首先在其他站点上创建用户，然后在当前站点上创建用户。在任何站点上失败时，不要创建用户并在创建用户的任何站点上回滚。此选项需要比第一个选项更多的工作，因为您必须保持同步，但如果由于某种原因您无法使用单个数据库进行用户管理，这将起作用。
你需要关闭脑海中的DBA，并以不同的方式看待事物。外键仅在关系数据库中可用，即使数据库位于同一服务器上，您也不能始终链接到其他数据库中的实体。
因此，放开"外键"要求，只使用用户名或 UserId（可能是 GUID）将域对象与用户相关联。
至于第二个要求 - 我不确定问题是什么。如果你说你需要为尚不存在的用户创建域实体，那么你无论如何都被搞砸了 - 你不能使用不存在的东西。简单的答案是首先在身份服务器中创建用户，然后为该用户创建域实体。然后稍后您可以更改用户属性并将用户名/密码提供给真人使用。