开发者

Windows authentication in asp.net mvc 3 hosted on Windows Azure?

I am migrating o开发者_JAVA技巧ne 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 !


You have two choices here:

  1. Use federated authentication and something like ACSv2. This requires a bit of work to setup a relying party, install ADFS2, etc. However, it is the most robust and future proof option. It is a very good option.
  2. Use something like Windows Azure Connect. That will bring Windows Authentication to the cloud by joining your running instances to your domain controller on-premises. In effect, you have something of a VPN between your cloud instances and your on-premises domain controller. There are some caveats to this model today (requires installing agent on DC for instance), but it would be from a 'just works' stand point, the easiest. Longer term, this is less attractive I believe than option #1.

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.


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.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜