Single Sign-On (Building Real-World Cloud Apps with Windows Azure)
There are many security issues to think about when you’re developing a cloud app, but for this series we'll focus on just one: single sign-on. A question people often ask is this: "I’m primarily building apps for the employees of my company; how do I host these apps in the cloud and still enable them to use the same security model that my employees know and use in the on-premises environment when they’re running apps that are hosted inside the firewall?" One of the ways we enable this scenario is called Windows Azure Active Directory (WAAD). WAAD enables you to make enterprise line-of-business (LOB) apps available over the Internet, and it enables you to make these apps available to business partners as well.
Introduction to WAAD
- It integrates with on-premises Active Directory.
- It enables single sign-on with your apps.
- It supports open standards such as SAML, WS-Fed, and OAuth 2.0.
- It supports Enterprise Graph REST API.
Suppose you have an on-premises Windows Server Active Directory environment that you use to enable employees to sign on to Intranet apps:
What WAAD enables you to do is create a directory in the cloud. It’s a free feature and easy to set up.
It can be entirely independent from your on-premises Active Directory; you can put anyone you want in it and authenticate them in Internet apps.
Or you can integrate it with your on-premises AD.
Now all the employees who can authenticate on-premises can also authenticate over the Internet – without you having to open up a firewall or deploy any new servers in your data center. You can continue to leverage all the existing Active Directory environment that you know and use today to give your internal apps single-sign on capability.
Once you’ve made this connection between AD and WAAD, you can also enable your web apps and your mobile devices to authenticate your employees in the cloud, and you can enable third-party apps, such as Office 365, SalesForce.com, or Google apps, to accept your employees’ credentials. If you're using Office 365, you're already set up with WAAD because Office 365 uses WAAD for authentication and authorization.
The beauty of this approach is that any time your organization adds or deletes a user, or a user changes a password, you use the same process that you use today in your on-premises environment. All of your on-premises AD changes are automatically propagated to the cloud environment.
If your company is using or moving to Office 365, the good news is that you’ll have WAAD set up automatically because Office 365 uses WAAD for authentication. So you can easily use in your own apps the same authentication that Office 365 uses.
Set up a WAAD tenant
A WAAD directory is called a WAAD tenant, and setting up a tenant is pretty easy. We'll show you how it's done in the Windows Azure Management Portal in order to illustrate the concepts, but of course like the other portal functions you can also do it by using a script or management API.
In the management portal click the Active Directory tab.
You automatically have one WAAD tenant for your Windows Azure account, and you can click the Add button at the bottom of the page to create additional directories. You might want one for a test environment and one for production, for example. Think carefully about what you name a new directory. If you use your name for the directory and then you use your name again for one of the users, that can be confusing.
The portal has full support for creating, deleting, and managing users within this environment. For example, to add a user go to the Users tab and click the Add User button.
You can create a new user who exists only in this directory, or you can register a Microsoft Account as a user in this directory, or register or a user from another WAAD directory as a user in this directory. (In a real directory, the default domain would be ContosoTest.onmicrosoft.com. You can also use a domain of your own choosing, like contoso.com.)
You can assign the user to a role.
And the account is created with a temporary password.
The users you create this way can immediately log in to your web apps using this cloud directory.
What's great for enterprise single sign-on, though, is the Directory Integration tab:
If you enable directory integration, and download a tool, you can sync this cloud directory with your existing on-premises Active Directory that you're already using inside your organization. Then all of the users stored in your directory will show up in this cloud directory. Your cloud apps can now authenticate all of your employees using their existing Active Directory credentials. And all this is free – both the sync tool and WAAD itself.
The tool is a wizard that is easy to use, as you can see from these screen shots. These are not complete instructions, just an example showing you the basic process. For more detailed how-to-do-it information, see the links in the Resources section at the end of the chapter.
Click Next, and then enter your Windows Azure Active Directory credentials.
Click Next, and then enter your on-premises AD credentials.
Click Next, and then indicate if you want to store a hash of your AD passwords in the cloud.
The password hash that you can store in the cloud is a one-way hash; actual passwords are never stored in WAAD. If you decide against storing hashes in the cloud, you'll have to use Active Directory Federation Services (ADFS). There are also other factors to consider when choosing whether or not to use ADFS. The ADFS option requires a few additional configuration steps.
If you choose to store hashes in the cloud, you’re done, and the tool starts synchronizing directories when you click Next.
And in a few minutes you’re done.
You only have to run this on one domain controller in the organization, on Windows 2003 or higher. And no need to reboot. When you’re done, all of your users are in the cloud and you can do single sign-on from any web or mobile application, using SAML, OAuth, or WS-Fed.
Sometimes we get asked about how secure this is – does Microsoft use it for their own sensitive business data? And the answer is yes we do. For example, if you go to the internal Microsoft SharePoint site at http://microsoft.sharepoint.com, you get prompted to log in.
Microsoft has enabled ADFS, so when you enter a Microsoft ID, you get redirected to an ADFS log-in page.
And once you enter credentials stored in an internal Microsoft AD account, you have access to this internal application.
We're using an AD sign-in server mainly because we already had ADFS set up before WAAD became available, but the log-in process is going through a WAAD directory in the cloud. We put our important documents, source control, performance management files, sales reports, and more, in the cloud and are using this exact same solution to secure them.
Create an ASP.NET app that uses WAAD for single sign-on
Visual Studio makes it really easy to create an app that uses WAAD for single sign-on, as you can see from a few screen shots.
When you create a new ASP.NET application, either MVC or Web Forms, the default authentication method is ASP.NET Identity. To change that to WAAD, you click a Change Authentication button.
Select Organizational Accounts, enter your domain name, and then select Single Sign On.
You can also give the app read or read/write permission for directory data. If you do that, it can use the Windows Azure Graph REST API to look up users’ phone number, find out if they’re in the office, when they last logged on, etc.
That's all you have to do - Visual Studio asks for the credentials for an administrator for your WAAD tenant, and then it configures both your project and your WAAD tenant for the new application.
When you run the project, you'll see a sign-in page, and you can sign in with credentials of a user in your WAAD directory.
When you deploy the app to Windows Azure, all you have to do is select an Enable Organizational Authentication check box, and once again Visual Studio takes care of all the configuration for you.
These screen shots come from a complete step-by-step tutorial that shows how to build an app that uses WAAD authentication: Developing ASP.NET Apps with Windows Azure Active Directory .
In this chapter you saw that Windows Azure Active Directory, Visual Studio, and ASP.NET, make it easy to set up single sign-on in Internet applications for your organization's users. Your users can sign on in Internet apps using the same credentials they use to sign on using Active Directory in your internal network.
The next chapter looks at the data storage options available for a cloud app.
For more information, see the following resources:
- Windows Azure Active Directory Documentation. Portal page for WAAD documentation on the windowsazure.com site. For step by step tutorials, see the Develop section.
- Windows Azure Multi-Factor Authentication. Portal page for documentation about multi-factor authentication in Windows Azure.
- Organizational account authentication options. Explanation of the WAAD authentication options in the Visual Studio 2013 new-project dialog.
- Microsoft Patterns and Practices - Windows Azure Guidance. See Federated Identity pattern.
- HowTo: Install the Windows Azure Active Directory Sync Tool.
- Active Directory Federation Services 2.0 Content Map. Links to documentation about ADFS 2.0.