Since couple of year (3-4) I strongly evangelize single-sign-on, federated identity, claims authentication and so on. There are at least two major points to support that:
You (as developer) don’t want to be responsible for the leak of tens or hundreds of thousands passwords and personal data. This responsibility is just too high.
Living in 21st century, there is not a single Internet user, who does not have at least 2 online identities which can be used for authentication (Google, Microsoft, FaceBook, Yahoo, etc.)
Having said that, I have also written a number of articles on claims based authentication, custom login pages, etc. In all of them user had to go through some learning curve. This is not the case today! Today, Microsoft is thinking about developers and lets them to focus on application itself, business logic and just does not care about authentication! Do not forget that you can run .NET (ASP.NET WebForms, MVC and even ASP.NET vNext!), Java, Node.Js, PHP, Python on Azure Web Sites today! With three easy steps, you can protect your Web Site with Azure Active Directory!
What is Azure Active Directory – this is the Identity management system that is responsible for all Office 365 subscribers, Dynamics CRM Online subscribers, Microsoft Intune and all Azure Subscriptions! You may even had no idea, but with every Azure subscription, comes one default Azure Active Directory. So, if you are using Azure, regardless of that being MSDN benefit, Regular pay-as-you-go or a free Trial, you already have one Azure Active Directory tenant! If you wish, you can learn a bit more about how to manage your Azure Active Directory here.
So, dear user, you have created your Azure Web Site and now you have to protect it with your Azure Active Directory tenant. Here are the three easy steps you have to follow:
1. Navigate to the Configure tab of your Web site. Scroll down to Authentication / Authorization section and click Configure
3. Select your Azure Active Directory (if you have not changed anything, the name of your Active directory will most probably be “Default Directory) and chose “Create new application”:
Now your site is protected by Azure Active directory, has automatic Claims Authentication, you don’t have to worry about salting and hashing users passwords, don’t need to worry about how user would reset their password and so on. Protecting your site has never been easier!
What are the catches! There is always a catch! First of all, this service is yet in preview and has some limitations:
- You can only protect your site with your Azure Active directory, but you can add Microsoft Accounts (i.e. email@example.com) to your Azure Active Directory, but not any external users (i.e. FaceBook, Google, Yahoo)
- With the current release all users in the configured directory will have access the application.
- With the current release the whole site is placed behind login the requirement (you cannot define “public” pages, but it is relatively easy to do this in a web.config file).
- Head less authentication/authorization for API scenarios or service to service scenarios are not currently supported.
- With the current release there is no distributed log-out so logging the user out will only do so for this application and not all global sessions (which means, that if user comes back, he/she will automatically be logged-in again).
Quick, easy and works across the whole stack of supported platforms on Azure Web Sites (.NET, PHP, Java, Node.JS, Python).