As anticipated in Monday’s announcement, the CTP release of Visual Studio 2015 brings lots of interesting news to identityland – both in the IDE and in the form of libraries we released on NuGet at the same time.
The features are still in preview (some of them, very much so 
) but at this point you should be able to start getting a taste of what the product will look like in its final form.
In this post I am going to highlight the most interesting identity features you might want to experiment with.
New ASP.NET 4.6 Project Templates and Tools
(for the ones of you not keeping track, ASP.NET 4.6 == ASP.NET vCurrent)
Big news in this area!
The first thing you’ll notice is that the look & feel of the “Change Authentication” changed.
“Organizational Accounts” is now gone, substituted by the new moniker “Work and School Accounts”. In their infinite wisdom, our designers decided to change the label into something easy for people to relate to. As a poor English-as-a-second-language speaker, I can only agree
If you pick the option and hit OK, things get even more interesting.
Major rearranging! Let’s examine the new layout, top to bottom.
The first dropdown remains the same as its VS2013 ancestor. It gives you the usual options for using Azure Active Directory from a Single Organization (for Line of Business apps), multiple organizations (for SaaS/multitenant apps) and on-premises (for direct ADFS connections).
But hey, what is that domain dropdown? What’s in there?
You’ll remember from the first VS2015 preview (and this silly video) that VS2015 introduced the ability of associating your MSA (formerly Live ID) and Azure AD accounts to Visual Studio, so that VS can now access the services your accounts can access on your behalf – across multiple features, and without bugging you all the time with credential prompts.
The domain dropdown is a manifestation of that. It lists all the default domains associated to all the Azure AD tenants your users belong to: basically, those are all the directories that you can use for securing new ASP.NET projects. You just select the directory you want, hit OK and VS will automatically provision your app in that directory! Neat, right?
A couple more details worth highlighting:
- If you don’t see the domain you want in the list, just select the dropdown and start typing the domain you want. Once you hit OK the tool will verify with VS if by any chance that domain is associated to one of the Azure AD tenants for which you already have cached tokens. If that’s the case, it will just use the associated token and create the new project without prompting you. If that’s a completely new, unknown domain, you’ll get the usual ADAL prompt: once you enter the necessary credentials and consent, the cached token collection will grow by one member – and your app will be provisioned in the new directory. WARNING: in this CTP, this doesn’t work especially well. If it fails, you might want to add the user in advance to VS, via top right corner
->Account Settings. - In this CTP the dropdown is quite unstable. For example: if you have a federated tenant with lots of registered custom domains, the dropdown will show all of them… but in fact, they will all be different ways of choosing the same directory tenant. On occasions it might not show other test directories in the same subscription as the federated tenant.
That is not very usable, and downright confusing at times (the domains are listed in random order and usually the one preselected in the dropdown is not the one you’d choose). I want to make sure to clarify that this is a BUG in CTP6, which we will hopefully address soon.
Going down, you’ll notice that we now have one single permission, Read Directory Data. The directory permisisons in this release are radically different from the ones in VS2013. Whereas the old model assigned permissions directly to the application, forcing you to be an administrator in the target directory, in the new system we use delegated permissions. That means that as long as the permission you choose does not require admin access, and your admin did not explicitly disallow the feature, you can now use VS for creating Azure AD protected apps even if you are not an admin! For that reason, we limited the set of permissions in the tool to the only one that can be set for (single org) web apps by non admins. If you want to change permissions, you can always go to the portal and change them there.
What’s left? let’s pop out the More Options area.
Wait a minute, what is “client id” doing there, instead of “app id URI” or realm? You guessed that right! From this CTP on, the ASP.NET templates for Azure AD generate OpenId Connect config code instead of WS-Federation. And of course, they use OWIN middleware for that.
What about ADFS? Well, if we want to talk with the ADFS setups in market today, we have to stick with WS-Federation. However, we updated the on-premises template to use the OWIN middleware for WS-Federation to talk with ADFS.
You already guessed, but let me spell it out: from this CTP on, we no longer have any template using Windows Identity Foundation. We’re now fully on OWIN.
New Connected Services Tool
Remember the Configure Azure AD Authentication dialog form the first VS2015 preview? It’s been updated to align with the new templates and domain dropdown. If I launch it against the project just created (solution explorer->right click->Configure Azure AD Authentication) I land on the following:
As you can see, the dialog precisely picked up all the settings that were generated by the file->new ASP.NET template, and I can now modify those to my heart’s content – the tool understands the project template structure and will do the changes I ask for, whereas in the earlier preview it would have thrown its metaphorical arms up and refused to touch a project with existing identity settings.
Isn’t it awesome to have different VS features all working together, presenting compatible options and augmenting each others’ functionalities? I’ll tell you a little secret: it doesn’t happen on its own! The 2nd law of software thermodynamics wants features to show radically different UX and options, produce different artifacts, duplicate tasks and data, and so on. But we aren’t letting that happen! Every Thursday morning representatives from ASP.NET, VS IDE, Identity, Connected Services tools and Office tools teams gather around the same table, ensuring that everything identity related in VS2015 interlocks nicely. We try our best!
New OpenId Connect and OAuth2 Middleware for .NET Core & ASP.NET 5!
Last but not least. We finally have OpenId Connect and OAuth2 bearer middleware that you can use in ASP.NET 5 projects.
We don’t have templates supporting those at this point, but we have the NuGets out there and two brand new samples that use as a starting point for your Web Apps and Web API based on vNext:
- WebApp-OpenIdConnect-AspNet5, the classic OpenId Connect sign in and sign out – this time based on the ASP.NET 5 flashy templates
- NativeClient-AspNet5, the entry level sample showing how to expose a Web API to be consumed by a native client. Note: the native client is still classic .NET 4.5, it’s only the web API project that is on ASP.NET 5.
There isn’t much news for what concerns the identity middlewares in themselves; the main notable new feature is the alignment we made between notification pipelines between OpenId Connect and OAuth2 bearer. That should make it easier for you to write portable logic for pipeline-bound operations, such as claims augmentation, custom request validation, and the like.
The most evident news is more about the way in which the projects in ASP.NET 5 are organized. Say goodbye to web.config! Have lots of moving parts that support client side development!Shove everything in one single Startup.cs! All of those are things happening around the identity logic; in fact, the init code we use remains pretty much the same – as a quick glance to startup.cs will confirm.
app.UseCookieAuthentication(options => { });
app.UseOpenIdConnectAuthentication(options =>
{
options.ClientId = Configuration.Get("AzureAd:ClientId");
options.Authority = String.Format(Configuration.Get("AzureAd:AadInstance"), Configuration.Get("AzureAd:Tenant"));
options.PostLogoutRedirectUri = Configuration.Get("AzureAd:PostLogoutRedirectUri");
}); The only difference is that now you have to repeat “options” every time you want to set a property.
There is a bug to call out in this release – the ClaimsPrincipal.Current is not correctly set hence the samples contain a small workaround to set it right. That will be fixed in the next release.
Get your hands dirty
Lots of new features in this release! Although not everything is super stable at this point, I hope you’ll have the patience to play with the new identity features in VS2015 CTP6 and let us know what you like, what you don’t like and what’s still missing. Looking forward for your feedback!