Azure ACS 没有生成的代码和 HttpHandlers？
Azure 的 ACS 服务非常贴心，我喜欢它的所有魔力，但我希望我的 Web 应用程序 (MVC) 的魔力少一点。如果您查看 CodePlex 上的代码示例，您会发现调用该服务并从端点获取登录提供程序的 JSON 列表非常简单，如下所示：
https://.accesscontrol.windows.net/v2/metadata/IdentityProviders.js？协议=wsfederation&领域=http%3a%2f%2flocalhost%3a7070%2f&版本=1.0&回调=？
从生成的 JSON 中，您可以呈现一些指向提供商的链接，一旦您处理了这些登录，它们就会通过 ACS 将您退回，并且 ACS 会将生成的令牌发布到您在 Azure 中设置的任何端点门户网站。
我的问题是，我该如何处理该令牌？我不想使用 WIF“魔法”来创建 IPrincipal 等设置。我只是不想弄乱应用程序中已有的内容。
Azure's ACS service is pretty sweet, and I love all of the magic it can do, but I want a little less magic for my Web app (MVC). If you look at the code samples on CodePlex, it's easy enough to call the service and get a JSON list of login providers from an endpoint like this:
https://.accesscontrol.windows.net/v2/metadata/IdentityProviders.js?protocol=wsfederation&realm=http%3a%2f%2flocalhost%3a7070%2f&version=1.0&callback=?
From the resulting JSON, you can render some links to the providers, and once you deal with those logins, they'll bounce you back through ACS, and ACS will do a post with the resulting token to whatever endpoint you set up in the Azure portal.
My question is, what do I do with that token? I don't want to use the WIF "magic" that creates sets an IPrincipal and what not. I just don't want to mess with what I already have in the app.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您将完全按照 WIF 对令牌所做的操作。您可以在解密 SAML 令牌后对其进行解析。您可以在此处查看 SAML 令牌的规范。我建议使用 WIF，因为解析 SAML 不适合胆小的人。您需要解析所有声明，然后决定在应用程序中如何处理它们。 WIF 通过创建 IClaimsPincipal 并在 IClaimsIdentity 上设置声明来实现此目的。
You would do exactly what WIF does with the token. You parse it after decrypting the SAML token. You can see the spec for the SAML token here. I would recommend going with WIF because parsing SAML is not for the faint of heart. You will need to parse out all the claims and then decide what to do with them in your applications. WIF does this by creating the IClaimsPincipal and setting the claims on the IClaimsIdentity.
我写了一篇博客文章，为那些想要 WIF 的强大功能但又不想将整个应用程序转换为基于声明的人描述了一个解决方案。这应该让您了解如何处理这种情况： http://goo.gl/J8WZe
最终，我扩展了 WIF 模块类并添加了一些覆盖来替换我不需要的魔术方法。
我还没有对此进行测试，但您可以做的另一件事是通过注册它公开的各种事件来进入 WIF 工作流程。
I wrote a blog post describing a solution for people who want the power of WIF but don't want to convert their entire application to being claim based. This should give you an idea of how you can approach the situation: http://goo.gl/J8WZe
Ultimately, I extended the WIF module classes and added some overrides to replace the magic methods I didn't need.
I have not tested this but the other thing you can do is tap into the WIF workflow by registering for the various events it exposes.