WCF 中基于令牌的身份验证
我正在创建一个网站，其中包含 ASP.NET 页面和 Flash 小程序。我想将我的业务逻辑封装在 WCF 服务中，该服务将通过两个端点公开：一个端点可通过 HTTP(S) 通过 Internet 访问，供 Flash 客户端使用，另一个端点可在数据中心内访问，供应用程序服务器使用。如果这看起来不是一个好方法，那么请在这里停下来；否则，我将继续...
问题是如何验证来自 Flash 客户端的请求。由于我不想将用户的密码存储在浏览器 cookie 中，不想在每个请求中发送密码，并且不想在初始登录后必须使用 HTTPS，所以我计划使用令牌 -基于认证系统。我也不希望用户在登录网站本身后必须登录 Flash 客户端，因此我计划在 Flash 客户端启动时使用 Javascript 将令牌传递给 Flash 客户端。
我知道 WCF 支持使用 .NET Framework 的内置安全框架 (System.Security) 来强制执行访问控制，我想利用这一点。
那么问题是：当 Flash 调用 WCF 服务时，如何将令牌传递给 WCF 服务，以及如何在服务器上处理该令牌？
- WCF 具有“颁发令牌”身份验证模式，但它似乎旨在用于具有安全令牌服务和 SAML 令牌的成熟联合场景 - 我真正想要的更复杂一点。可以将此模式与我自己的“简单随机字符串”令牌一起使用吗？如果是这样，怎么办？请记住，这需要与 Flash 兼容。
- 我可能会在标头（SOAP 标头或 HTTP 标头）中传递令牌。在这种情况下，一旦我确定了哪个用户正在发出请求，我如何通知框架以便 System.Security 检查起作用？
- 我应该考虑一种完全不同的方法吗？任何避免在每个请求中发送密码、让我使用 System.Security 并与 Flash 配合使用的方法都是可能的。
I am creating a website which will contain both ASP.NET pages and a Flash applet. I want to encapsulate my business logic in a WCF service which will be exposed through two endpoints: One accesssible over the Internet through HTTP(S), for use by the Flash client, and one accessible within the data center for use by the application servers. If this does not seem like a good approach, then stop me here; otherwise, I'll move on...
The question is how to authenticate requests coming from the Flash client. Since I don't want to store the user's password in a browser cookie, don't want to send the password with every request, and don't want to have to use HTTPS after the initial login, I plan on using a token-based authentication system. I also don't want the user to have to log into the Flash client after already logging into the site itself, so I plan on using Javascript to pass the token to the Flash client when it starts.
I know WCF supports using the .NET Framework's built-in security framework (System.Security) to enforce access control, and I would like to take advantage of this.
The question, then, is: How do I pass the token to the WCF service when it is called by Flash, and how do I process the token on the server?
- WCF has an "issued token" authentication mode, but it appears this is intended to be used in a full-blown federation scenario with a Secure Token Service and SAML tokens--a bit more complexity that I really want. It is possible to use this mode with my own "simple random-string" tokens? If so, how? Keep in mind this needs to be compatible with Flash.
- I could potentially pass the token in a header (either a SOAP header or an HTTP header). In this case, once I've determined which user is making the request, how do I inform the framework so that the System.Security checks will work?
- Is there a different approach altogether that I should consider? Anything that avoids sending passwords in every request, lets me use System.Security, and works with Flash is a possibility.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
因为看起来最初的问题已经得到解答，所以我将保持简短，但一种方法确实是在 http 标头中传递身份验证令牌并覆盖
CheckAccess(OperationContext operationContext, ref Message message)自定义ServiceAuthorizationManager。您之前已将服务配置为使用实现
IAuthorizationPolicy的自定义策略。剩下的就是实现简单的
IIdentity和IPrincipal类来存储您的授权状态。关于此主题有许多好文章：
http:// /msdn.microsoft.com/en-us/library/system.identitymodel.policy.iauthorizationpolicy.aspx
http://msdn.microsoft.com/en-us/library/system.servicemodel.serviceauthorizationmanager.aspx
我想这可能仍然感觉像是“滚动你的-own”解决方案，但当您遵循既定模式时，它至少让人放心。它确实具有将您的服务方法中的授权代码黑盒化的优点。
As it seems the original question has been answered I'll keep this brief, but one approach would indeed be to pass the authentication token in an http header and override
CheckAccess(OperationContext operationContext, ref Message message)in a customServiceAuthorizationManager.You will have previously configured the service to use a custom policy that implements
IAuthorizationPolicy.All that remains is to implement simple
IIdentityandIPrincipalclasses to store your authorization state.A number of good articles exist on this subject:
http://msdn.microsoft.com/en-us/library/system.identitymodel.policy.iauthorizationpolicy.aspx
http://msdn.microsoft.com/en-us/library/system.servicemodel.serviceauthorizationmanager.aspx
I guess this may still feel like a "roll-your-own" solution, but its at least reassuring when you're following an established pattern. It does have the advantage of black-boxing your authorization code from your service methods.