Azure/网络场就绪的 SecurityTokenCache
我们的网站使用 ADFS 进行身份验证。为了减少每个请求的 cookie 负载,我们打开 IsSessionMode(请参阅 节食中的 fedauth cookie)。
要使其在负载平衡环境中正常工作,我们需要做的最后一件事是实现一个就绪的 SecurityTokenCache。实现看起来非常简单,我主要感兴趣的是找出在处理 SecurityTokenCacheKey 以及 TryGetAllEntries 和 TryRemoveAllEntries 方法时是否应该考虑任何问题(SecurityTokenCacheKey 有 Equals 和 GetHashCode 方法的自定义实现)。
有人有这方面的例子吗?我们计划使用 AppFabric 作为后备存储,但使用任何持久存储的示例都会有所帮助 - 数据库表、Azure 表存储等。
以下是我搜索过的一些地方:
- 在 赫维·威尔逊的 PDC09 会话他使用了 数据库安全令牌缓存。我还没找到样本 他的会话的代码。
- Vittorio Bertocci 的优秀著作第 192 页 在《Programming Windows Identity Foundation》一书中,他提到了上传 Azure 就绪的 SecurityTokenCache 的示例实现 书的网站。我也找不到这个样本。
谢谢!
jd
2012 年 3 月 16 日更新 Vittorio 的博客 链接到使用新的 .net 4.5 内容的示例:
ClaimsAwareWebFarm 这个示例是对我们从你们许多人那里得到的反馈的回答:您想要一个显示场就绪会话缓存(而不是 tokenreplycache)的示例,以便您可以通过引用使用会话而不是交换大 cookie;您需要一种更简单的方法来保护农场中的 cookie。
Our site uses ADFS for auth. To reduce the cookie payload on every request we're turning IsSessionMode on (see Your fedauth cookies on a diet).
The last thing we need to do to get this working in our load balanced environment is to implement a farm ready SecurityTokenCache. The implementation seems pretty straightforward, I'm mainly interested in finding out if there are any gotchas we should consider when dealing with SecurityTokenCacheKey and the TryGetAllEntries and TryRemoveAllEntries methods (SecurityTokenCacheKey has a custom implementation of the Equals and GetHashCode methods).
Does anyone have an example of this? We're planning on using AppFabric as the backing store but an example using any persistent store would be helpful- database table, Azure table-storage, etc.
Here are some places I've searched:
- In Hervey Wilson's PDC09
session he uses a
DatabaseSecurityTokenCache. I haven't been able to find the sample
code for his session. - On page 192 of Vittorio Bertocci's excellent
book, "Programming Windows Identity Foundation" he mentions uploading
a sample implementation of an Azure ready SecurityTokenCache to the
book's website. I haven't been able to find this sample either.
Thanks!
jd
3/16/2012 UPDATE
Vittorio's blog links to a sample using the new .net 4.5 stuff:
ClaimsAwareWebFarm
This sample is an answer to the feedback we got from many of you guys: you wanted a sample showing a farm ready session cache (as opposed to a tokenreplycache) so that you can use sessions by reference instead of exchanging big cookies; and you asked for an easier way of securing cookies in a farm.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
为了提出一个有效的实现,我们最终必须使用反射器来分析 Microsoft.IdentityModel 中与 SessionSecurityToken 相关的不同类。以下是我们的想法。此实现部署在我们的开发和质量保证环境中,似乎工作正常,它对应用程序池回收等具有弹性。
在 global.asax 中:
DurableSecurityTokenCache.cs:
MruCache.cs:
ICache.cs:
To come up with a working implementation we ultimately had to use reflector to analyze the different SessionSecurityToken related classes in Microsoft.IdentityModel. Below is what we came up with. This implementation is deployed on our dev and qa environments, seems to be working fine, it's resiliant to app pool recycles etc.
In global.asax:
DurableSecurityTokenCache.cs:
MruCache.cs:
ICache.cs:
这是我写的一个示例。我使用 Windows Azure 永久存储令牌,避免任何可能的重播。
http://tokenreplaycache.codeplex.com/releases/view/76652
您需要将其放入您的 web.config 中:
Here is a sample that I wrote. I use Windows Azure to store the tokens forever, defeating any possible replay.
http://tokenreplaycache.codeplex.com/releases/view/76652
You will need to place this in your web.config: