Windows Azure 上的 WCF 会话
我们的应用架构如下： 1) WCF 服务充当外观层，位于服务、业务逻辑和数据访问层之上 2) 每个客户端，无论是 MVC/ASP.NET 还是任何其他类型的应用程序，都有一个 ClientTag，首先需要对其进行身份验证并颁发“访问令牌”。然后，客户端将这个令牌与每条消息一起传递到 Facade 层 3) 系统将托管在 Windows Azure 上
这可以通过 WCF 会话轻松实现，如下所示： 1）客户端发起对WCF的调用以获取令牌（客户端到WCF的会话已建立，因此每个后续通信都是同一“对话”的一部分） 2) WCF对ClientTag进行身份验证，颁发令牌，并将其存储为本地变量 3) 客户端将令牌存储在它自己的会话中，并通过每个请求
将其传递给 WCF 问题在于 Azure（由于其高可用性/负载平衡性质）不支持 WCF 会话。所以，问题是我们如何实现这一点。
一种解决方案是使用 AppFabric 缓存来模拟 WCF 层中的会话状态。我们将在那里存储访问令牌，然后根据客户端传入的内容对其进行验证。这样做的问题是客户端和 WCF 之间没有并发性。因此，我们必须在来自同一客户端的每个请求上提前 WCF 会话超时，但我们希望避免在每个请求上更新缓存（可能是数百/秒）。
有什么建议吗？有没有人在 Azure 上实现过类似的东西。任何反馈将不胜感激。
PS 这不仅是在服务器上发生的身份验证，而且还为每个客户端进行自定义授权。 （某些客户端可能可以访问某些功能，而其他客户端可能无法访问）。
谢谢！
Our application architecture is as follows:
1) WCF service acts as a facade layer and sits on top of Service, Business Logic and Data Access layer
2) Every client, be it an MVC/ASP.NET, or any other type of application has a ClientTag that first needs to be authenticated and issued an "access token". This token is then passed by the client with every message into the Facade layer
3) The system will be hosted on Windows Azure
This would have been easy to implement with WCF sessions like so:
1) Client initiates a call to WCF to get the token (Client to WCF Session is established, thus every subsequent communication is part of the same "conversation")
2) WCF authenticates the ClientTag, issues the token, and stores it as a local variable
3) Client stores the token in it's own Session and pass it to WCF with every request
Where it breaks down is the fact that Azure (due to its high-availability/load-balancing nature) doesn't support WCF sessions. So, the questions is how do we implement this.
One solution is to use AppFabric caching to imitate session state in WCF layer. We would store the Access Token there and then validate it against what the client passes in. The problem with this is that there is no concurrency between client and WCF. So, we would have to advance WCF session timeout on every request from the same client but we'd want to avoid updating the cache on every request (it could be hundreds/sec).
Any suggestions? Has anyone implemented anything similar to this on Azure. Any feedback would be greatly appreciated.
P.S. It's not only authentication that would happen on the server, but also custom authorization for each client. (Some client might have access to some functions, and others might not).
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我正在实施与此直接类似的东西，但使用 OAuth 2.0 作为通过 ACS 的身份验证架构。
我所关注的模型是从此处的 MSDN 示例中无耻地
窃取复制而来的：https://connect.microsoft.com/site1168/Downloads/DownloadDetails.aspx?DownloadID=35417。这假设客户端具有用户界面，因此用户可以直接或通过某些第三方身份提供商提供某种用户名和密码。这种方法的优点是 WCF 层不需要使用任何类型的会话状态，因此无需对机器密钥或其他内容进行繁琐的处理。不过，您仍然会得到可以映射到
IPrincipal的内容，因此，如果您愿意，您可以创建自定义RoleProvider并以通常的方式使用声明性角色。请注意，该示例使用老式 ASP.NET，并且依赖于不透明（并且可能有很多错误）程序集
Microsoft.IdentityModel.Protocols.Oauth。而且，除非我遗漏了什么，否则我还没有在其他地方看到过这个版本（例如作为 Windows Identity Foundation 的一部分），所以我怀疑它相当新。另一种方法可能再次是使用 ACS，这次是对 SAML 令牌进行身份验证，同样遵循 OAuth 2.0 协议。详细信息和示例代码位于：http://msdn.microsoft.com/ en-us/library/windowsazure/hh127795.aspx。这可能更适合没有 UI 的系统。
I'm in the middle of implementing something directly similar to this, but using OAuth 2.0 as the authentication architecture through ACS.
The model I'm following is shamelessly
stolencopied from an MSDN sample here: https://connect.microsoft.com/site1168/Downloads/DownloadDetails.aspx?DownloadID=35417. This assumes the client has a user interface, so the user can present some kind of username and password either directly or through some third-party identity provider.The advantage of this approach is that the WCF layer doesn't need to use any kind of session state, so there's no tedious mucking about with machine keys or whatnot. You'll still get something that can be mapped to an
IPrincipal, however, so if you want you can create a customRoleProviderand use declarative roles in the usual way.Note the sample uses old-school ASP.NET, and has a dependency on an opaque (and possibly rather buggy) assembly
Microsoft.IdentityModel.Protocols.Oauth. And, unless I'm missing something, I've not seen this released anywhere else (e.g. as part of Windows Identity Foundation) so I suspect it's rather new.An alternative approach could again be to use ACS, this time to authenticate a SAML token, again following the OAuth 2.0 protocols. Details and sample code is here: http://msdn.microsoft.com/en-us/library/windowsazure/hh127795.aspx. That may be better suited to a system with no UI.