Azure Web Role Authentication Strategies

Question

I have a web role project in ASP.NET made for Azure deployment and need to have authentication.
I have to choose between Office 365 and On-Premise Active Directory.
Looks like both needs to be integrated to Azure Active Directory using Access Control Service. What are the pros and cons of both? Also if there are any other possibilities.

Answer 1

As astaykov mentions in his comment on your question you are not restricted to involving Access Control Services in this scenario. Not sure why he didn't submit that comment as an answer.

If you truly must go against your Office 365 or On Premise AD then what you are really saying asking is what is the difference between the two. I'll list some thoughts, but first if you want to implement these then here are some links:

Offerings from MS on Identity: http://msdn.microsoft.com/en-us/security/aa570351.aspx

Using ADFS V2 in your Azure Deployment: http://channel9.msdn.com/shows/Identity/WIF-Workshop-9-WIF-and-Windows-Azure/ This is a little older material and I couldn't find much on using WIF to connect directo ADFS V2 that was more current. You do NOT have to invovle ACS in this at all. Sadly, this was misunderstood a lot when ACS was released.

Using Office 365/Windows Azure AD: http://msdn.microsoft.com/library/windowsazure/dn151790.aspx

Note: I have connected Web sites running in Azure to ADFSV2 directly, but I've not had a chance to work with the WAAD/Office 365 stuff yet.

If you choose to go with exposing your AD on premise then you would likely do this by exposing it using ADFS V2. This is what opens up the endpoint for the code running WIndows Identify Foundation (WIF) objects to reach out and deal with authentication. The upshot of this is that you don't have to worry about Office 365 logins or a WAAD separately and might be an interesting choice if you don't have those services for ANY OTHER reason but this one scenario. The down side is that you are exposing a proxy to your AD on an endpoint at your own location. If you lose connectivity to the internet then no one attempting to use the apps in the cloud would be able to authenticate. This is also the option I might look at if the users of the app in the cloud will ONLY EVER access it while behind your firewall (such as being at an office or even over VPN). This is because you can set it up so that your app uses a ADFS endpoint that is NOT exposed to the internet, but if they are behind your firewall it would still work. This pretty much ensures that only people already behind your firewall can use your app.

If you choose to use Office 365/WAAD integration then the upside is that you can sync with your onpremise AD to give single sign on to resources on your network as well as to the apps in the cloud. You also make access to your cloud apps more resilient because they have no need to depend on your exposed ADFS V2 endpoint. If you use Office 365/WAAD for any other reason (such as your employess use Office 365 for email, collaboration, etc.) then this is the option I would look at first.

You should look at ACS if you want to integrate with other identify providers such as Google, Facebook or even other companies. Technically you wouldn't have to use ACS at that time either, but it will certainly save you a ton of work to use ACS and not write the integration code on your own for each provider.