Leveraging Azure AD authentication for an on-premise web app

I’ve been experimenting with using Azure AD for authentication of an on-premise web app. I thought I’d share some of my findings so far.


I was writing a web app to provide reporting on simple bind data UWWI is now collecting. When I added a asp.net web project to my Visual Studio solution, it asked me what authentication I wanted to use, with 3 or 4 choices. Since it happened to be a leap forward day, I decided to give AAD a try (to be clear, I’ve been intending to try this out for about 9 months, but never found the time).


The on-boarding process was amazingly simple. I happen to have a global admin account in our AAD, and currently without that, the experience isn’t as simple, but my understanding is that level of privilege won’t always be necessary in the future. In other words, in order to create the application in AAD, you currently need to be an AAD global admin. When I compare the on-board process of what it takes for a web app to integrate to an equivalent federated authentication solution that uses UW NetIDs, like Shibboleth or ADFS, there’s really no comparison. I had a registered app with working authentication within 30 seconds—and all from within Visual Studio.


Now, if I had a more complicated use case, e.g. I was writing a web service that other web apps could interact with, then the initial configuration to get multiple party OAuth setup would have been beyond that, but today there is no UW OAuth offering (or if there is, it isn’t documented). I haven’t experimented here, but I think Eric might have been looking into this.


My next (and active) hurdle was realizing that my AAD credentials wouldn’t allow me to get access to the SQL server where the data my report needed to access was. There are two solutions I can take to solve this. A common solution many websites take is to use the web app pool’s credentials to get access to the data. I’m generally not a fan of that type of architecture, because it complicates the audit picture and there is a strong temptation to not actually write the auditing the web app must now must do, so I resisted that. I spoke with a colleague of mine, Brian Desmond, and he suggested I leverage KCD (Kerberos constrained delegation) to transition the AAD credential to an AD credential—he had done this exact thing several times for similar use cases. Turns out that the C2WTS service (Claims to Windows Token Service) that was released with ADFS 1 was subsequently more broadly released with WIF 3.5. This service is commonly used with Sharepoint 2010 when it is configured to use federated authentication, e.g. see http://support.microsoft.com/kb/2722087. So I now need to explore writing some code that leverages the C2WTS stuff, which fortunately there are nice code examples for at http://msdn.microsoft.com/en-us/library/ee517278.aspx.


I’m beginning to think there is a nice emerging and reproducible authentication integration pattern here for future .NET web apps. You end up with a web app that has federated authentication, can benefit from all the cool AAD capabilities Microsoft is pouring investment into (like RBAC), but you can still get all the benefits of the traditional AD logon token. There’s a lot more to explore here before labeling it a preferred integration pattern, but it has definite potential in my mind.


Obviously I haven’t finished (and given my spare time to work on things like this, I probably won’t for a while), but I did think this was worth sharing more broadly.


If others have a web app they’d like to provision to Azure AD, let one of the AAD global admins know, and we’ll get your web app provisioned.


One thought on “Leveraging Azure AD authentication for an on-premise web app

Leave a Reply

Your email address will not be published. Required fields are marked *