Today's post is a deep dive on some of the cool new capabilities in our developer tools and frameworks that we announced today. Working with the ASP.NET and Visual Studio teams, we've made some big enhancements that make it easy for developers to use Windows Azure Active Directory as their authentication service.
Our guest blogger for today is Vittorio Bertocci who many of you already know from his many identity presentations and webcastes. Vittorio is a Principal Program Manager here in the Active Directory team and probably our most famous team member. He worked closely with the ASP.NET Team on this project.
Alex (Twitter @Alex_A_Simons)
In the last few months we worked in close collaboration with the ASP.NET team to make Windows Azure Active Directory a first class citizen in the Visual Studio project creation experience. Today Sayed announced the availability of the ASP.NET and Web Tools for Visual Studio 2013 Preview , which extends the new ASP.NET project templates and tooling experience to integrate Windows Azure Active Directory authentication and management features right at project creation time. We are excited to finally have a public preview of the new feature for you to try!
You can head to Sayed’s post (or to the preview documentation ) for a comprehensive overview and release notes, but in a nutshell: imagine if you could in just few clicks create the solution already configured to authenticate users from your organization and/or easily onboard new organizations, support distributed sign out, automatically refresh authentication settings and securely query the directory through the Graph API. That’s exactly what the new templates enable you to do.
If you had a chance of reading the developer walkthroughs we published when Windows Azure AD reached general availability: those new templates create the same solution described in our walkthrough for web sign with LoB applications , or even a solution which combines all of our Windows Azure GA walkthroughs .
An In-Depth Example: Creating a New Multitenant Application
Let’s walk through the creation of a project with the new tool, to give you a feeling of how the new feature works. Let’s tackle upfront the application type with the highest number of moving parts, a multitenant application (described here ).
Please note: none of the info below is required for using the new tools . We are describing how things work under the hood for the developers that have been working on Windows Azure AD and want to know how those new tools relate to existing artifacts, but in fact one developer could just go through the template wizard and obtain a working app with nearly no knowledge of the underlying infrastructure.
You can refer to this post for instructions on how to get and install the bits on your machine; also, don’t forget that we are still in preview!
Start by creating a new project; select Web from the project types list on the left.
As you can see, there is now one single entry point: ASP.NET Web Application. Simple! Select it and click OK. You will be given the chance to select the technologies you want to feature in your project. For our sample we’ll select MVC.
In the next step you are given the chance to select the technologies you want to feature in your project. For our sample we’ll select MVC.
You might have noticed that the dialog also informs you about the authentication settings currently selected: the default is “Individual user Accounts”, which correspond to the case in which your app maintains its own account database (though it still can outsource credentials verification to external providers, such as Facebook).
We want to change that option and connect to Windows Azure AD. Click on “Change Authentication”. You’ll get a new dialog, which offers you to choose different authentication types (on the left) and provides controls (on the right) to enter the details required to implement your chosen settings.
Choose “Organizational Accounts”.
The UI changes to help you to choose which kind of app you want to create: an app tied to a single Windows Azure AD tenant, a SaaS app meant to be used by multiple Windows Azure AD tenants or an app tied to a traditional on-premises identity provider (such as an ADFS2.0 instance).
Choose “Cloud – Multiple Organizations”.
Note: This UI shows a lot of options right now. Post preview we will be looking at ways to simplify it. The only field you are required to fill is the “Domain” one, as Visual Studio must know which Windows Azure AD tenant should be used for creating the application entry.
The Access Level combo box offers you the chance of adding directory reading capabilities to your app, in addition to the default Single Sign On.
The Application ID URI will be assigned automatically by the tool if you don’t enter anything.
Hit OK on this screen.
At this point the tool will ask you to enter your Windows Azure AD credentials for the tenant you specified: the tool needs them to access the Graph on your behalf and create the application entry for the project automatically.
Once you have done that, click “Create project”.
The tool will go through the classic project creation phases: template instantiation, acquisition of the necessary NuGet packages, and so on. However it will follow those up with the creation (via Graph API) of the necessary entries in Windows Azure AD, and the automatic configuration of the project bits to support Web sign on and Graph invocation.
Let’s take a look a bit more in-depth on what the tool created.
What’s in the Visual Studio Project?
Immediately after creation, the project
Where does all that logic live? It is wired up in the right places through the project. Here there’s a quick reference map to start your exploration:
The Application Entry in Windows Azure AD
That settles what’s in the Visual Studio project. What about the entries created in Windows Azure AD?
If you head to the Windows Azure portal and select your applications list, you’ll find that a new entry (with the same name of the Visual Studio project) has been created.
Want to take a deeper look? Head to the Graph Explorer , sign in and list your applications by requesting https://graph.windows.net/<yourtenantname>/applications . Search for your project name, and you’ll find an entry similar to the following:
The things to note in the above entry are:
Given that a multitenant app is automatically available in its origin tenant, we should expect to find a ServicePrincipal for it as well. And sure enough, if you head to https://graph.windows.net/<yourtenantname>/servicePrincipals you’ll find something to the effect of the following:
No surprises here either; what we really wanted from the ServicePrincipal is its object ID, so that we can verify if the tool actually added the app in the Directory Readers role as requested: you can do it by using a query of the form https://graph.windows.net/<yourtenantname>/servicePrincipals/<serviceprincipalObjectID>/memberO... .
"description": "Allows access to various read only tasks in the directory. ",
"displayName": "Directory Readers",
And sure enough, everything is as expected . :-)
Running the Project
The project is ready to be run right after creation. Hit F5 in Visual Studio: you’ll get the following screen.
Apart from the theme and few cosmetic differences, this is actually the project described in the multitenant app walkthrough minus the effort of writing it from scratch and provisioning it by hand in the Windows Azure AD portal. You can sign up with a new tenant, sign in, query the Graph, sign out… all out of the box. Pretty neat
This is just the first preview of this new, important capability. As we go on with our collaboration with the ASP.NET team we’ll adjust features according to feedback and expand the scope to address more scenarios.
As usual, your opinions and suggestions are super important for our work prioritization: do give the new ASP.NET and Web Tools for Visual Studio 2013 a try, and let us know what you think!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.