我们的网站使用ADFS进行身份验证.为了减少每次请求的cookie有效负载,我们开启了IsSessionMode(请参阅节食中的fedauth cookies).
我们需要做的最后一件事就是在负载均衡的环境中实现这个功能,就是实现一个农场就绪的SecurityTokenCache.实现看起来非常简单,我主要想知道在处理SecurityTokenCacheKey以及TryGetAllEntries和TryRemoveAllEntries方法时是否存在任何问题(SecurityTokenCacheKey具有Equals和GetHashCode方法的自定义实现).
有没有人有这样的例子？我们计划使用AppFabric作为后备存储,但使用任何持久存储的示例将是有用的 - 数据库表,Azure表存储等.
以下是我搜索过的一些地方:
谢谢!
JD
3/16/2012更新 Vittorio的博客链接到使用新的.net 4.5内容的示例:
ClaimsAwareWebFarm 这个示例是对我们很多人的反馈的回答:你想要一个显示农场就绪会话缓存的示例(而不是tokenreplycache),这样你就可以通过引用而不是交换大的cookie来使用会话; 并且您要求一种更简单的方法来保护农场中的cookie.
在研究基于声明的安全性(或联合安全模型)主题之后.我一直在看到许多以CardSpace为例的例子.我读到的主要文章给出了一个非常好的主题解释,是微软在一个名为Zermatt的框架上的PDF.
我正在研究的基于声明的安全体系结构相当于将STS身份验证代理与STS授权代理结合使用.这样,当我创建新服务时,我需要做的就是确保该服务只接受授权代理发出的声明.如文章所述,授权代理只接受身份验证代理发出的声明.
在设置时,客户端尝试使用新服务时,必须通过身份验证代理 进行身份验证(发出经过身份验证的声明),然后获得授权 代理授权 (发布授权声明).
这一切都很好,花花公子,架构很清晰,但我没有看到如何实现STS.正如我所提到的,网络上的大多数(如果不是全部)示例都显示了如何使用CardSpace,但是当您有一个数据库备份您的身份验证方案时,这并不完全有效.
示例场景
替代文字http://img512.imageshack.us/img512/8329/claimsbasedsecurityza6.jpg
saml geneva-framework federated-identity wcf-security sts-securitytokenservice
伙计们,我有一个ASP.NET MVC应用程序,我试图使用ADFS v2.0(日内瓦)的Release Candidate版本来保护它.我已将应用程序配置为依赖方信任,并且我已使用Fedutil.exe修改应用程序的Web.config,以便它具有有关Geneva服务器的信息并使用Geneva服务器作为其声明源.
然而,当我尝试点击MVC应用程序时,它会重定向到日内瓦,然后(在警告我有关自签名证书之后)再次将我重新引导到MVC应用程序.在接受两个自签名证书警告后,两个服务器在无限重定向循环中互相打乒乓,直到最后日内瓦发出以下消息:
同一个客户端浏览器会话在最后'1'秒内发出'6'请求.可能存在可能的错误配置.请联系您的管理员了解详情
除了包含上述消息的事件之外,MVC端或日内瓦的事件日志中没有错误.如果有人能给我一些关于如何尝试和调试,诊断并希望解决这个问题的信息,我将永远感激不尽.
同样,日内瓦盒子是ADFS v2.0候选版本,ASP.NET MVC站点是使用最新的(09年末)版本的Windows Identity Foundation SDK构建的,其中使用来自WIF SDK的FedUtil.exe修改了Web.config .
所以你们都会得到这个...我从Firefox尝试了同样的应用程序...... IT工作.我收到提示输入我的域凭据,ADFS v2服务器重新指示我ONCE然后我最终在我的应用程序的主页上,完成我的帐户名称和个性化问候语.所以现在真正的问题是:为什么IE8会陷入无限重定向循环并且Firefox不是？经过进一步测试,我已经能够开箱即用,无需修改ADFS v2(RC)或BOTH Safari和Firefox上的WIF(RTW)中的任何默认管道内容.IE8是唯一一个在处理此身份验证方案时遇到任何问题的浏览器.我已经尝试了一切,包括安装和信任自签名证书,将站点添加到我的本地Intranet区域,并将安全性降低到低,甚至设置第一个和第三方cookie始终允许.
还没有看到许多与日内瓦有关的问题,我也在日内瓦论坛上发布了这个问题......
我正在开发一个场景,我们有一个带有广泛安装基础的win form应用程序,它将在我们的整个操作过程中频繁地调用我们集中托管的各种服务.
这些服务都使用日内瓦框架,并且所有客户都应首先致电我们的STS以获得令牌以允许访问服务.
开箱即用,使用ws2007FederationHttpBinding,应用程序可以配置为在每次服务调用之前从STS检索令牌,但显然这不是最有效的方式,因为我们几乎重复调用服务的工作.
或者,我已经实现了从应用程序"手动"检索令牌所需的代码,然后在调用服务上的操作时传递相同的预先检索的令牌(基于WSTrustClient示例和助手论坛); 效果很好,所以我们确实有一个解决方案,但我相信它不是很优雅,因为它需要在代码中构建WCF通道,远离美妙的WCF配置.
我更喜欢ws2007FederationHttpBinding方法,客户端只需像任何其他WCF服务一样调用服务,而不了解日内瓦的任何信息,绑定负责令牌交换.
然后有人(Jon Simpson)给了我[我认为]一个好主意 - 添加一个服务,托管在应用程序本身以缓存本地检索的令牌.本地缓存服务将实现与STS相同的合同; 当收到请求时,它会检查是否存在cahced令牌,如果存在,则返回它,否则它将调用"真正的"STS,检索新令牌,缓存它并返回它.客户端应用程序仍然可以使用ws2007FederationHttpBinding,但不是将STS作为发行者,而是使用本地缓存;
通过这种方式,我认为我们可以实现两全其美 - 在没有服务特定的自定义代码的情况下缓存令牌; 我们的缓存应该能够处理所有RP的令牌.
我已经创建了一个非常简单的原型,看看它是否有效,并且 - 不幸的是有点不足为奇 - 我有点卡住了 -
我的本地服务(当前是一个控制台应用程序)获取请求,并且 - 第一次 - 调用STS来检索令牌,缓存它并成功将其返回给客户端,随后使用它来调用RP.一切顺利.
然而,第二次,我的本地cahce服务尝试再次使用相同的令牌,但客户端失败并出现MessageSecurityException -
"安全处理器无法在消息中找到安全标头.这可能是因为消息是不安全的故障,或者因为通信方之间存在绑定不匹配.如果服务配置为安全性而客户端是没有使用安全性."
是否存在阻止同一令牌被多次使用的东西？我对此表示怀疑,因为当我根据WSTrustClient示例重用令牌时,它运行良好; 我错过了什么？我的想法可能吗？一个好的？
这是本地缓存的(非常基本的,在此阶段)主代码位 -
static LocalTokenCache.STS.Trust13IssueResponse cachedResponse = null;
public LocalTokenCache.STS.Trust13IssueResponse Trust13Issue(LocalTokenCache.STS.Trust13IssueRequest request)
{
if (TokenCache.cachedResponse == null)
{
Console.WriteLine("cached token not found, calling STS");
//create proxy for real STS
STS.WSTrust13SyncClient sts = new LocalTokenCache.STS.WSTrust13SyncClient();
//set credentials for sts
sts.ClientCredentials.UserName.UserName = "Yossi";
sts.ClientCredentials.UserName.Password = "p@ssw0rd";
//call issue …我们目前在不同的域上有一些.Net应用程序,每个域都有不同的成员资格.我们正在转向使用单点登录(并且希望单点注销)和Azure上托管的集中成员身份的联合登录.
我们的自然选择似乎是为Azure的访问控制创建我们自己的身份提供者,我们所有的站点都将使用WIF进行身份验证,但非.Net站点可能会在将来对此进行身份验证.
这仍然是一条可以接受的路线吗？