Web Authentication Overview
Back in the day of IT, it was relatively simple to perform authentication and authorization with your corporate users. In a typical scenario, you would have your Line-of-Business (LOB) application installed on a server inside your corporate network. The application would be set to use Windows Authentication off of the organization’s Active Directory (AD) deployment, and when a user accessed the application on a domain joined machine, all the magic of Windows Authentication would happen automatically. Often times, the user would also be checked against an AD group membership. If the user was out in the field or not on the corporate network, they would need to use a VPN connection in order to access the application.
Fast forward to current day IT: now users have multiple devices (phones, tablets, etc.) that are not joined to the corporate network. Nowadays, users are also demanding access to the data from anywhere, without having to use VPN on their corporate machine, as well as devices that aren’t joined to the domain.
Enter OAuth – At a basic level, it is a framework that allows for a 3rd party to serve as your authentication provider, so you don’t have to share your password with the service you are trying to use. It is commonly used today on many popular sites. You may recognize it by when you have to log-in to sites using your Facebook, Twitter, Google accounts. It is convenient, because you don’t have to remember yet another account & password. The 3rd party provider will also ask you if you trust the site/service you are trying to access, and will ask you for your consent to release certain information about you to the service, such as your e-mail address, full name, etc.
Windows Azure – Active Directory
While using OAuth with the popular 3rd party identity providers works well for non-enterprise scenarios, it was a non-starter with IT departments, mostly because logging in with those providers to access organizational data was out of the question. You could setup Active Directory with a Secure Token Service – still a good idea, but it does not support issuing OAuth tokens directly – only the more complex authentication protocols such as WS-Trust. Now, though, Microsoft Azure – Active Directory bridges the gap between corporate authentication and modern web authentication standards.
Active Directory Users & Groups
Azure Active Directory (AAD) serves many purposes. The first and most import piece, is that it serves as your user store in the cloud. Just like on premise Active Directory, you create users and groups that you can manage access to your applications. If you already have users and groups in your on premise AD instance, that’s fine – AAD supports a sync from your internal instance to the cloud, so you only have to manage the objects in one location. If you want real-time access to your internal directory, you can also setup a Secure Token Service (STS) on your internal instance, and AAD will redirect to the STS and manage the authentication between the two systems.
Active Directory Graph API
Once your AAD instance is setup and you have users and groups, naturally, you’ll want to get information about these objects – attributes of users, members of groups, etc. This is where the Azure Graph API comes in. The Graph API exposes operations on AD objects as a REST based service and allows you to perform requests, such as verifying group membership and adding/removing users from groups.
Active Directory Applications
AAD also allows you to create applications. These applications serve as the identifier in the cloud for your actual applications that are deployed in the cloud, devices, etc. For example, say you have a mobile application that connects to a REST based service deployed in Azure. In AAD, you would have two applications setup for those two apps. You would then grant your mobile app permission to access your REST service in AAD. When you are ready to start authenticating users, in your code, you would call an Azure AAD web endpoint, including your unique application id & the unique name of the resource you are trying to access (your REST service) in the URL. If everything is setup, and the log in was successful, you will receive an OAuth token back from AAD that you can use to access your REST Service.
As you can see, Azure Active Directly exposes a ton of features that allows you to easily manage and authenticate your users in the cloud using modern web technologies.
Stay tuned for a guide on setting up a real world example using a Windows 8 Modern (Metro) app that authenticates and retrieves data from a REST based service.