跨计划发送自定义 ACS 索赔的最佳方式是什么?

发布于 2025-01-08 06:43:24 字数 442 浏览 0 评论 0原文

我有两个程序,一个“登录”程序,它使用外部 STS(Google、Facebook 等)来登录用户并返回用户拥有的安全访问类型。然后,我想将该信息发送到一个单独的程序,该程序获取该安全访问权限并据此授予用户权限。

发送该信息的最佳方式是什么?

我已经阅读了一些有关自定义授权管理器服务的内容,但我不确定这是否是我所需要的。是否可以只发布安全信息,然后 web.config 将其转化为声明?我应该制作一个新的令牌并发送它吗?

我绝望地迷失了。如果有人可以在网络上的某个地方提供有用的教程,那将非常感激(因为我的谷歌搜索只找到了长篇大论的文章,​​这些文章要么比我需要的多得多,要么少得多)。

具体的代码片段会让我很高兴。

谢谢!

编辑:我试图避免将登录系统变成 STS。但我开始觉得我需要这样做。 STS 和依赖方之间是否存在某个中间点?就像可以生成自己的声明的依赖方一样?

I've got two programs, a "login" program that uses the a foreign STS (Google, Facebook, etc.) to log the user in and returns the type of security access that user has. I then want to send that information off to a separate program that takes that security access and gives the user privileges based on that.

What is the best way to send that information across?

I've read some things about the Custom Authorization Manager Service, but I'm not sure if that is what I need here. Is it possible to just POST the security info across and the web.config turns that into a claim? Should I be making a new token and sending that?

I am hopelessly lost. If someone could provide a helpful tutorial somewhere on the web, that would be immensely appreciated (as my googling has only turned up long-winded articles that either do much more than I need or much less).

Specific code snippets would make my day.

Thanks!

EDIT: I am trying to avoid making the login system into an STS. But I am starting to feel I need to. Is there some halfway point between STS and relying party? Like a relying party that can generate its own claims?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

云雾 2025-01-15 06:43:25

您有多种选择:

  1. 最简单的一种是 ClaimsAuthorizationManager,这可能就是您正在寻找的。 http://msdn.microsoft.com/en-us/library/ee748497.aspx CAM 是 ASP.NET 身份验证管道中的一个步骤,在应用程序验证从 ACS 传入的安全令牌后立即运行。您可以在此处定义自定义授权逻辑,并且可以向交付给您的应用程序的 IClaimsPrincipal 添加其他声明。例如,您可以在一个在各种依赖方应用程序之间共享的库中实现 CAM,而不是将授权逻辑集中在服务中。

  2. 如果您的授权规则很简单,即您不查询任何外部用户属性存储,那么一种选择是使用 ACS 声明转换规则来执行此操作。然后您的应用程序将直接使用 ACS 颁发的令牌。 http://msdn.microsoft.com/en-us/library/gg185955.aspx

  3. 但是,如果您的架构绝对需要一个单独的登录服务来使用令牌并使用用户属性等填充新令牌,那么它将需要是一个 STS。构建自己的 STS 可能很棘手,但有预制的 STS 可以用来完成此任务。例如,如果您的应用程序位于 AD 域中,则 ADFS 2.0 将是理想的选择,因为它与 AD 和 ACS 紧密集成,并且具有强大的声明转换功能。

You have several options:

  1. The simplest one is the ClaimsAuthorizationManager, which might be what you're looking for. http://msdn.microsoft.com/en-us/library/ee748497.aspx The CAM is a step in the ASP.NET authentication pipeline that runs right after your application has validated the security token incoming from ACS. Here is where you define your custom authorization logic, and you can add additional claims to the IClaimsPrincipal that gets delivered to yor application. Instead of centralizing authorization logic in a service, you could for example implement your CAM in a library that's shared accross various relying party applications.

  2. If your authorization rules are simple, i.e., you're not querying any external user attribute store, then one option would be to use ACS claims transformation rules to do this. Then your applications would consume the token issued by ACS directly. http://msdn.microsoft.com/en-us/library/gg185955.aspx

  3. If however your architecture absolutely requires a separate login service that consumes tokens and populates new tokens with user attributes and such, then it will need to be an STS. Building your own STS can be tricky, but there are prefabricated STSes available to do this. If your applications live in an AD domain for example, ADFS 2.0 would be an ideal choice because of it's close integration with AD and ACS, and it's powerful claims transformation capabilities.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文