WIF STS,不同“种类”用户、应用程序和声明
我们目前正在考虑实施我们自己的 STS(Microsoft WIF)来验证我们的用户,在此过程中我们提出了一些我们无法回答的问题。
我们有不同类型的用户,使用不同类型的应用程序。每种类型的用户都需要一些仅与该类型的用户和应用程序所属相关的特殊类型的声明。 请注意,我们并不控制所有客户。
假设所有用户都通过使用用户名和密码的简单 https 进行授权 (.NET MVC3)。用户通过其类型、用户名和密码(不仅仅是用户名和密码)来唯一标识。因此,我需要为每种用户类型创建一个端点,以便能够区分它们。当用户授权时,我将颁发一个令牌,其中包含代表用户类型的声明。有没有更简单的方法来做到这一点?我可以避免每种用户类型的端点(目前有三个)吗?
然后,我的令牌服务可以检查授权用户的令牌并转换声明,发出包含所有用户类型特定声明的令牌。到目前为止一切都很好,除了我认为的多个端点?
如果我需要有多个端点,我是否也应该公开不同的元数据文档,每个端点一个?拥有一份包含所有声明描述的大型元数据文档没有任何意义,因为没有任何应用程序需要所有声明。
更新
一些说明。
某些应用程序仅由某些类型的用户使用。没有一种应用程序可以被多种用户类型使用。
根据请求来自的应用程序类型,需要比较该用户类型的用户名和密码。每种类型的应用程序都有用户存储。这就是为什么我需要知道请求来自哪种应用程序类型。我无法仅通过用户名和密码解析类型。
We are currently looking into implementing our own STS (Microsoft WIF) for authenticating our users, and in that process we have come up with a few questions that we haven’t been able to answer.
We have different kinds of users, using different kinds of applications. Each kind of user needs some special types of claims only relevant for that kind of users and the application belonging.
Note that we do not control all the clients.
Let’s say that all users are authorized using simple https using username and password (.NET MVC3). A user is uniquely identified by its type, username and password (not username and password alone). So I will need to create an endpoint for each user type, to be able to differentiate between them. When a user authorize, I’ll issue a token containing a claim representing the user type. Is there an easier way for doing this? Can I avoid an endpoint for each user type (currently there are three)?
My token service can then examine the authorized users’ token and transform the claims, issuing a token containing all the users’ type specific claims. So far so good, except for the multiple endpoints I think?
If I need to have multiple endpoints, should I expose different metadata documents as well, one for each endpoint? Having one big metadata document containing a description of all claims, doesn’t make any sense since there is no application that needs all claims.
Update
Some clarifications.
Certain applications are only used by certain types of users. Not one application can be used by multiple user types.
Depending on what type of application the request is coming from, username and passwords needs to be compared for that user type. There are user stores for each type of application. That is why I need to know what application type the request is coming from. I can't resolve the type by the username and password alone.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
根据您的问题描述,听起来您有三个独立的用户“存储库”(每种用户类型一个)。
因此,恕我直言,这对于三个 STS 或具有多个端点的 STS 来说是有效的场景。
解决此问题的另一种方法是通过将用户重定向到 sts 的回复方的标识符来区分用户类型。该标识符在
wtrealm
参数中提交。处理顺序可能如下所示:
其数据库/类结构可能类似于:
Based on your problem description, it sounds like you have three indepent user "repositories" (one for each user type).
So imho this would be a valid scenario for three STS or a STS with multiple endpoints.
Another way to solve this could be to distinguish the user type by the indentifier of the replying party redirecting the user to the sts. This identifier is submitted in the
wtrealm
parameter.The processing sequence could look like the following:
The datasbase/class structure for this could look similiar to this:
需要更多信息来回答:
某些应用程序是否仅由某些类型的用户使用?或者任何用户类型都可以访问任何应用程序吗?如果是前者,您可以为该应用程序配置 STS 以将该用户类型作为声明传递。每个应用程序都可以配置为拥有自己的声明子集。
用户类型从何而来?如果来自存储库,您不能简单地为其构造一个声明吗?
更新:
@Peter 的解决方案应该有效。
沃特。 3 个 STS 与 3 个端点,
许多 STS - 可以使用具有不同“代码隐藏”的相同标准端点。如果您迁移到开箱即用的解决方案,仍然可以工作。证书续订的额外工作。
一个 STS - 自定义端点将无法迁移。只需更新一个 STS 即可进行证书续订。
元数据——鉴于它可以动态生成,所以并不重要。请参阅动态生成联合元数据。
Need some more information to answer:
Are certain applications only used by certain types of users? Or can any user type access any application? If the former, you can configure the STS for that application to pass that user type as a claim. Each application can be configured to have its own subset of claims.
Where is the user type derived from? If from a repository, could you not simply construct a claim for it?
Update:
@Peter's solution should work.
Wrt. the 3 STS vs. 3 endpoints,
Many STS - can use same standard endpoint with different "code-behind". Would still work if you migrated to an out-the box solution . Extra work for certificate renewals.
One STS - custom endpoints won't be able to be migrated. Only one STS to update for certificate renewals.
Metadata - given that it can be generated dynamically, doesn't really matter. Refer Generating Federation Metadata Dynamically.