根据 WCF 成员资格服务对 ASP.Net 网页进行身份验证
我有一个用 ASP.Net 制作的网页和另一组工具，如 WPF、Windows 窗体应用程序。 ASP.Net 网页和所有应用程序集必须根据同一 ASP.Net 成员资格提供程序数据库进行身份验证。
我想知道的是使用 WCF 服务进行身份验证的最佳方法，该服务使用 ASP.NET 成员资格提供程序进行身份验证。是否有现成的东西可以根据 WCF 身份验证服务对 ASP.NET 网页进行身份验证？我必须实施自定义提供商吗？因为 ASP.NET 网页中的成员资格使用用户信息填充 IPrinciple User 属性，并且我希望与 WCF 服务身份验证具有相同的行为。
I have a Webpage made with ASP.Net and another set of tools like a WPF, Windows Forms applications. Is mandatory that the ASP.Net webpage and all the set of applications be authenticated against the same ASP.Net membership provider database.
What I want to know is the best way to authenticate using a WCF service that uses ASP.NET membership provider for the authentication. Is anything made out of the box for authenticate a ASP.NET webpage against a WCF authentication service? I have to implement a Custom Provider? Because the Membership in ASP.NET Webpage fill the IPrinciple User property with user information and I want the same behaviour with a WCF service authentication.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
自定义会员资格提供商就是我之前所做的。效果很好。我的团队犯了一个错误，让 wcf 服务与成员资格提供程序的接口相匹配，这是不必要且混乱的。如果您选择走这条路，我建议您根据需要自行制定服务合同，并实施您的提供商来使用它。
不过，如果我再做一次，我根本不会使用 WCF，而只是使用直接与数据库对话的 ASP.NET 应用程序的成员资格提供程序（现有的或自定义的，具体取决于您的需要）比 WCF 层有一个共享程序集，其他工具可以使用该程序集直接与数据库对话。甚至在 WCF 服务层中拥有通用代码。我认为使用服务并不能真正提供仅使用通用程序集无法获得的全部功能。无论如何，asp.net 会员资格提供商将是独立的。
这是假设您处于一个只能让桌面工具连接到数据库的环境中。如果这是一个 Internet 部署场景，您可能确实需要通过某种服务来完成此操作，而 WCF 是一个很好的选择。不过，与构建使用 WCF 服务的成员资格提供程序相比，使用现有的成员资格提供程序并在与之配套的数据库之上构建 WCF 服务可能是一条更短的路径。我认为后者不是一个糟糕的选择，但前者可能会更好。当然，这取决于很多因素。
a custom membership provider is how i have done this before. it worked pretty well. my group made the mistake of making the wcf service match the interface of the membership provider, which was unnecessary and messy. if you choose to go this route, i'd recommend making your service contract on your own as you want it and implementing your provider to consume that.
if i was doing it again, though, i wouldn't use wcf at all, but rather just use a membership provider (existing or a custom one, depending on your needs) for the asp.net application that talks directly to the database rather than a wcf layer and have a shared assembly the other tools could use that talks directly to the database. even having common code in a wcf service tier. i don't think using a service really provides a whole lot that you couldn't get by just using a common assembly. the asp.net membership provider is going to be something separate anyway.
this is assuming you are within an environment where you can just have the desktop tools connect to the database. if this is an internet deployed scenario, you probably do need to do this through some kind of service, and wcf is a great candidate for that. it's probably a shorter path, though, to use an existing membership provider and build your wcf service on top of the database that goes with that than to build a membership provider that consumes the wcf service. i don't think it would be a bad choice to do the latter, but you'd probably be better off with the former. this, of course, depends on a lot of factors, though.