使用单个 MembershipProvider 对多个 Web 服务后端进行身份验证有何影响?
在此假设场景中,有一个 ASP.NET 4 Web 应用程序同时聚合来自多个 Web 服务的数据。 Web 服务都是相同的实现,但是是单独的实例并且彼此不知道。
在 Web 应用程序中,用户为他想要访问的每个 Web 服务提供凭据,并且身份验证过程会迭代其所有用户名/密码组合以及每个 Web 服务的 URL。 (笨重的 UI 仅用于说明......)
假设 Web 应用程序使用自定义 MembershipProvider
类中的 ValidateUser
方法进行身份验证,并且 MembershipProvider< /code> 按照惯例在 web.config 中配置。
还假设自定义 MembershipProvider
类具有一个 Url
属性,该属性随着对不同 Web 服务的每次身份验证调用而变化。
假设所有这些,您如何处理用户 1 和用户 2 同时进行身份验证的场景,但用户 1 可以访问 Web 服务 A、B 和 C,用户 2 可以访问 Web 服务 X、Y ,和Z?
凭据和 URL 是否可能会混淆,导致用户 1 可能看到用户 2 的数据,反之亦然?
In this hypothetical scenario there is an ASP.NET 4 web application that simultaneously aggregates data from multiple web services. The web services are all of the same implementation, but are separate instances and are not aware of each other.
In the web application a user provides credentials for each web service he wants access to, and the authentication process iterates through all of his user name/password combos coupled with the URL for each web service. (The clunky UI is for illustration only....)
Assume the web application uses the ValidateUser
method in a custom MembershipProvider
class for authentication, and the MembershipProvider
is configured in web.config as per usual.
Assume also that the custom MembershipProvider
class has a Url
property that changes with each authentication call to the different web services.
Assuming all of that, how do you handle the scenario where User 1 and User 2 are authenticating at the same time, but User 1 has access to Web Service A, B, and C, and User 2 has access to Web Service X, Y, and Z?
Will the credentials and URLs potentially get mixed up and User 1 might see User 2's data and vice-versa?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果您打算实施自定义会员资格提供商,您会遇到很多令人头疼的问题。原因是在您的应用程序模型中,授权方案基于用户拥有的任何成员资格(针对特定服务)。
我建议您拥有自己的会员资格(针对您自己的站点)并扩展配置文件模型,以便您可以直接从用户的配置文件中检索用户有权访问的每项服务的凭据。
个人资料信息可以根据您自己的会员资格和角色提供者(特定于您的站点)与您自己的授权结合使用。在这种情况下,您可以为每个用户分配特定于每个服务的角色。
为了成功实现这一目标,为每个服务编写一个包装器,用您自己的方法(调用服务)封装服务调用。这将允许您使用
[PrincipalPermissison]
属性标记您自己的方法...并实现无缝授权。因此,如果您的用户有权访问 Amazon Web 服务,并且在他/她的个人资料中存储了该服务的凭据,您可以拥有以下权限:
用户角色:“AmazonAccessor”
这将使您不必兼顾会员资格和各种其他令人头疼的问题。
现在要创建您自己的配置文件,您可以执行以下操作:
当然还有 Web 配置:
If you are going to implement a custom membership provider you will see lots of headaches down the road. The reason is that in your app model, the authorization scheme is based on whatever membership the user has (for a specific service).
I would advise to have your own membership (for your own site) and extend the profile model so that you can retrieve credentials for each service that the user has access to straight out of the user's profile.
The profile information can be used in conjunction with your own authorization based on your own membership and role providers (specific for your site). In that case you can assign each user a role specific to each service.
To successfully achieve that, for each service, write a wrapper, encapsulating service calls with your own methods (which call the service). This will allow you to mark your own methods with the
[PrincipalPermissison]
attribute... and achieve seemless authorization.So if your user has access to the Amazon web service and there are credentials for that service stored in his/her profile you can have the following:
User Role: "AmazonAccessor"
This will prevent you from having to juggle membership and all sorts of other headaches.
Now to create your own profile you can do something like this:
And of course the Web config: