Windows Azure Active Directory Authentication: Getting Started
I’ve recently had the pleasure of familiarizing myself with Windows Azure Active Directory (WAAD) as an identity provider for .NET web applications. While the Build demo makes it look easy, my path was wrought with peril and unexpected pitfalls, so I present to you a series of blog posts where I will go through the ones we encountered, in the vague hope that it will save someone else the trouble. Identity management is a complex topic, so if you are not familiar with Windows Azure Active Directory – or cloud identity in general – I recommend that you read Jouni’s article first.
What is WAAD Authentication and why do I need it?
Windows Azure Active Directory is a SaaS identity provider – that is, a way to provide Single Sign-On and authorization across a variety of services. It’s used by Office 365, so you get the biggest bang for your buck when you are already using Office 365 and want to save your users from having yet another login to remember. Of course, even if you’re not using Office 365, you can still use it to share identities between multiple applications – whether they are cloud-hosted services, on-premises web sites or even client applications on your smartphone.
If you’ve got an Office 365 subscription (and have administrative access to it), you are already good to go. If you don’t have or want one, you can subscribe for a new Windows Azure Active Directory Tenant. You’ll be creating a new admin identity to go with that, so before you start, make sure you’re not logged in with a live account (or any other Microsoft identity, for that matter). The sign-up form is pretty straightforward. First, you fill in the basics. Then, when you’ve chosen a domain and verified its availability, you add in details of the new admin identity, and off you go – the setup redirects you to a login screen which is pre-populated with your new account data. Clicking on “Continue” leads you to the tenant administration page. That’s it, you’ve created a new WAAD tenant.
With the prerequisites out of the way, we’ll tackle the tooling. Download and install the Microsoft Online Services module for PowerShell (32bit 64bit). This is the first real snag: there are at least three versions of this module you may find floating around, and if your module is an older version, there are things you won’t be able to do with it! If you’re having trouble with the commandlets, look at the file properties for the installer package you downloaded, specifically the Digital Signature tab. If the date of the signature is older than July 16th 2012, uninstall the package and download the new version I linked above.
After you install the module, you’re going to want to check that you can actually use it. Open the quick link from your desktop or search your start menu or start screen for Microsoft Online Services Module for Windows PowerShell.
When the shell opens up, type in:
And you’ll be prompted for credentials. Type in the username and password of the account you created when you subscribed to your WAAD tenant or an administrative account in your Office 365 subscription:
No news is good news, so after you’ve given the credentials, if PowerShell works for a while and then says nothing, you’re good to go. If, on the other hand, you get a bunch of red text, you’ve got problems with your login that you need to sort out.
ASP.NET Fall 2012 Update
In order to make use of Visual Studio’s wizardry in configuring your application, you’re going to need the ASP.NET Fall 2012 Update. It contains a number of fixes and a feature that adds Yet Another Context-Menu Item for Visual Studio Web projects.
You can do all of this without the wizard, but it’s somewhat error-prone, so I find it best to let tools do the heavy lifting. In the next installment, I’m going to go through the steps of setting up your application for authentication.