1

也许这个问题凸显了我对声明身份管理知之甚少，但它就在这里。

如果在使用第三方 STS 作为身份并使用自定义声明进行授权的应用程序中使用 WIF（与应用程序相关且特定于 CanCreateFooBar 之类的东西）

1）如何管理用户？即，可以识别来自 AD 或其他会员资格提供商的用户，但在我的系统内部，我需要了解他们并拥有更多与身份无关的用户信息（因此让这些信息可用真的没有意义系统外），并且应该保留有关用户的信息，
问题是如何以智能的方式管理和创建我的系统数据（从 Ids 开始）？
我想到的确切场景是新员工被添加到公司，系统管理员为具有特定角色的域创建用户，我的系统如何才能意识到这一事实？（我可能希望系统提示系统管理员采取行动

2) 这些用户和角色的声明值存储在哪里，我该如何修改它们？理想情况下，我希望能够更改特定用户和操作的权限。有没有这方面的指导方针？

我可以看到这些可能是非常蹩脚的问题，但是当我考虑如何解决问题时，我想出了过于复杂的解决方案或需要大量重复的解决方案（即在两个地方创建使用的），所以我确定我我只是没有以正确的方式思考这个问题

谢谢

4

2 回答 2

4

如您所见，联合并不一定会减轻对供应的需求。这是一个并非立即显而易见的重要见解。

有多种方法可以解决这个问题，包括：

  1. 使用元或虚拟目录产品或
  2. 通过使用“JIT 配置”（也称为“动态配置”或“动态配置”）。

让我解释一下后者。这个解决方案，我也在我的博客上描述过，包括两个STS，一个IP-STS和一个RP-STS。第一个仅对用户进行身份验证；第二个是特定于您的应用程序的，并且知道授权该系统的用户需要哪些声明。IP-STS 不能发布这些特定于应用程序的属性，这样做会要求您的公司目录服务与各种特定于应用程序的信息混杂在一起。相反，在该存储中维护并由 IP-STS 发布的用户属性本质上是通用的，并且适用于用户，无论他们使用的是哪个应用程序。在对 IP-STS 进行身份验证并从中获得仅身份声明后，令牌将传递给 RP-STS。此令牌服务与您的应用程序紧密耦合。它知道用户需要什么声明才能访问不同的资源。它可以将仅身份声明转换为做出此访问控制决策所必需的声明。因此，RP-STS 是一个声明转换器，它将与身份相关的声明映射到特定于应用程序的声明。

RP-STS 如何为用户提供服务？假设创建了一个新员工，如上面的示例所示。当用户访问您的应用程序时，他将被退回到 RP-STS。他不会在那里登录，所以他会被退回到 IP-STS。系统管理员为他创建了一个帐户，因此他将能够登录，他的浏览器会将他弹回 RP-STS。RP-STS 会破解令牌，获取用户 ID（电子邮件、PPID 等），然后看到它不知道用户是谁。因此，RP-STS 将为用户提供服务。例如，它将通过显示网页来完成此操作。它可能会收集有助于确定该用户在访问 RP 时的角色的信息。在此之后，将提供用户（即，将在其数据库中创建一条记录，其中包含他的索赔值），RP-STS 将发出一个特定于您的应用程序的令牌并将他重定向回那里。应用程序不会知道他只是被配置了；它只会像往常一样使用声明。（明白我为什么称它为 JIT 供应了吗？）

如果在配置用户后情况发生了变化怎么办？好的。想象一下：用户是很久以前在目录存储中创建的，并且在 RP-STS 中如上所述进行了配置，并且他已经愉快地使用系统很长时间了。然后是一项政策变更，要求您的应用程序的用户接受新的条款和条件 (T&C)。下次用户登录应用程序时，他将被重定向到 RP-STS，IP-STS，他将进行身份验证，然后被退回到您的 RP-STS。此时，它会注意到用户必须接受新的 T&C，因此它将向用户显示一个网页并获得他们的同意。之后，RP-STS 将颁发一个安全令牌并将他重定向到您的应用程序。您的应用程序将一如既往地处理声明并执行授权访问所需的操作。它不会知道也不会 不在乎用户只是“重新配置”。或者，您可以使用 ILM（或现在称为 FIM）等产品在身份存储（即您的公司目录）和 RP-STS 的声明存储之间保持更改同步。根据您的系统，像这样进行反向通道同步的产品可能更合适。

顺便说一句，这些不是“蹩脚”的问题！有非常敏锐的问题反映了对一个非常复杂的问题的深刻思考和明智的反思。您需要回答的其他问题包括：

  • 您的应用程序的管理员如何更新其策略（例如，更改 T&C）？您必须创建什么 UI/API？UI 是否与用于管理 IP-STS 策略的 UI 集成在一起？
  • 必须存在什么样的信任关系才能使这样的系统正常工作？
  • 如果主题没有使用被动配置文件怎么办？如果他使用活动配置文件和/或没有 UI 怎么办？
  • 钥匙的位置和位置如何？使用这些密钥需要什么权限？它们是如何被修改、分发的，当它们即将到期时，系统管理员如何得到警报？

This stuff is really easy to demo at user group meetings and at conferences, but in reality it is very advanced stuff. If you have other questions, feel free to post them here or get in touch w/ me directly.

于 2009-12-11T18:34:06.747 回答
1

1）你不管理用户，不是真的。您只需获取 IClaimsIdentity 并将其用作您的授权来源。在我看来，如果您不这样做就可以逃脱，那么您不应该坚持声明-声明应该是您的用户信息的来源。

如果您想在声明的基础上进行构建，请从声明身份中获取唯一引用，例如电子邮件地址或 ppid/签名密钥 OU 哈希，并使用它来构建您自己的数据库，并添加您自己的信息。

但是，您的系统永远不会摆脱 3rd 方身份元数据库中的更改 - 直到在您的应用程序中发布和解析新的 SAML 令牌。

2) 声明值不会存储在任何地方，除非您存储它们。如何将其转换为权限取决于您 - 但通常您执行声明转换以获取外部声明并将它们映射到您用于权限的应用程序内部声明。因为索赔来自外部提供商，所以您无法更改它们 - 您与这些提供商没有任何联系。

于 2009-12-10T23:20:17.193 回答