Windows Azure 上托管的 asp.net mvc 3 中的 Windows 身份验证？
我正在将一个 ASP.NET MVC 3 Intranet 网站迁移到 Windows Azure，并将 DB 迁移到 SQL Azure。
在本地，我的站点使用 Windows 身份验证来对用户进行身份验证和授权（通过在控制器上放置 AUTHORIZE 属性）。
如果您能让我知道如何进行同样的操作，那就太好了。提前谢谢您！
I am migrating one ASP.NET MVC 3 intranet Website to the Windows Azure and DB to SQL Azure.
On Premises my site uses Windows Authentication to authenticate and authorize the user(By Placing AUTHORIZE attribute on controllers).
It would be very kind of you If you can let me know How to go about the same.Thank You In Advance !
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这里有两个选择：
您可以通过查看Windows Azure 平台培训工具包来获取有关其中每一项的更多详细信息。
我还应该补充一点，您无法（至少现在）将 Windows 身份验证与 SQL Azure 结合使用。您必须在那里使用 SQL 身份验证，因此我在这里讨论的内容仅适用于网站本身。
You have two choices here:
You can get more details for each of these by checking out the Windows Azure Platform Training Kit.
I should also add that you have no option (today at least) of using Windows Authentication with SQL Azure. You must use SQL authentication there, so what I am talking about here only applies to the web site itself.
我非常成功地使用 Windows Identity Foundation 和 Azure AppFabric 访问控制服务来使用 ADFS v2 进行身份验证。
除了直接身份验证之外，它还为您提供了比其他声明更高的灵活性，例如角色（不需要仅基于 AD 组成员身份）。
在我看来，它最大的优势在于 Azure 平台和本地 AD 之间不需要任何通信通道。一切都是通过浏览器完成的。从安全角度来看，这意味着虽然任何人都可以访问您的应用程序，但没有人可以对其进行身份验证，除非他们也可以访问您的 ADFS 服务器。对此的访问可以仅限于本地客户端或通过 VPN，从而大大减少了攻击面。
此外，根据我的经验，由于 ADFS 不需要对外公开，因此可以大大减轻部署它的官僚开销。
只需要进行配置，虽然最初可能有点麻烦，但一旦掌握了它，就非常简单了。您将 WIF 配置为使用 ACS 作为其身份提供者，并在 ACS 中为应用程序创建依赖方。然后，您将 ACS 配置为使用 ADFS 作为其身份提供程序。您可以将 WIF 配置为直接与 ADFS 通信，但通过 ACS 进行的额外抽象级别可能很有用。
完成配置后，使用 [Authorize] 属性即可“正常工作”。
请注意，如果您在控制器中使用 Ajax 调用，则需要采取一些预防措施，因为 Ajax 调用不处理联合身份验证重定向（或 ADFS Shuffle，我喜欢这样称呼它），但这没什么这是无法克服的。
总而言之，WIF+ACS+ADFS 透明 Windows 集成身份验证的组合给我留下了深刻的印象。
I'm very successfully using Windows Identity Foundation with Azure AppFabric Access Control Service to authenticate using ADFS v2.
As well as straight authentication, it gives you lots of flexibility over other claims, such as roles (which don't need to be based solely on AD group membership).
In my opinion, its biggest strength is that there is no communication channel required between the Azure platform and your on-premise AD. Everything is done via the browser. From a security perspective, this means that although anyone can reach your application, nobody can authenticate to it unless they can also reach your ADFS server. Access to this can be restricted to on-premise clients only or via VPN, greatly reducing the attack surface.
Also, because ADFS does not need to be exposed externally, it can greatly ease the bureaucratic overhead of deploying it, in my experience.
Only configuration is required, which although it can be a bit of a fiddle initially, is pretty straightforward once you've got to grips with it. You configure WIF to use ACS as it's Identity Provider and create a Relying Party in ACS for the application. Then, you configure ACS to use ADFS as its Identity Provider. You could configure WIF to talk directly to ADFS, but the additional level of abstraction of going via ACS can be useful.
Once you've done your configuration, using the [Authorize] attribute 'just works'.
Note that if you're using Ajax calls into your controllers, you'll need to take some precautions, as Ajax calls don't handle the federated authentication redirect (or the ADFS Shuffle, as I like to call it), but it's nothing that's insurmountable.
All in all, I'm very impressed with the combination of WIF+ACS+ADFS for transparent Windows integrated authentication.