This project has moved and is read-only. For the latest updates, please go here.

Combine WindowsAuthentication and UseWindowsAzureBearerToken

Oct 12, 2013 at 12:03 PM
My server needs to handle intranet users using WindowsAuthentication and home users via Azure Active Directory. How would I configure this in Startup.cs?

Oct 12, 2013 at 6:08 PM
This could get interesting. WindowsAuthentication is still integrated into the servers, rather than OWIN middleware, so making it cooperate might be tricky.

Step 1: Get two apps working, one with each auth type, just to make sure you know how.
Step 2: Describe your setup for each app (maybe share the config code).
Step 3: Then we can work on merging the two apps.
Oct 13, 2013 at 1:36 PM
Hi Tratcher, I have both versions working.

On the WPF client I choose authentication as follows:-
    abstract public class DataManager
        static DataManager()
            if (Environment.UserDomainName.Equals(ConfigurationManager.AppSettings["ServerDomainName"], StringComparison.CurrentCultureIgnoreCase))
                _useWindowsAuthentication = true;
                _httpHandler = new HttpClientHandler { UseDefaultCredentials = true };
                _authenticationContext = new AuthenticationContext("" + _tenant);

        public static HttpClient GetHttpClient()
            HttpClient httpClient = null;

            if (_useWindowsAuthentication)
                httpClient = new HttpClient(_httpHandler);
                httpClient = new HttpClient();

                AuthenticationResult _authenticationResult = _authenticationContext.AcquireToken(_resource, _clientId, _redirectUri, _userId);

                _userId = String.Empty;

                httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
                httpClient.DefaultRequestHeaders.TryAddWithoutValidation("Authorization", _authenticationResult.CreateAuthorizationHeader());

            httpClient.BaseAddress = _webApiBaseUri;
            return httpClient;
and on the server for WindowsAuthentication I have:-
    public partial class Startup
        public void Configuration(IAppBuilder app)
            //  new WindowsAzureJwtBearerAuthenticationOptions
            //  {
            //      Audience = ConfigurationManager.AppSettings["ida:Audience"],
            //      Tenant = ConfigurationManager.AppSettings["ida:Tenant"]
            //  });


            var config = new HttpConfiguration();


... and uncomment for AAD authentication.

ClaimsTransformationMiddleware reads the AAD Graph api and transforms groups into roles which are added to ClaimsIdentity. I'll need to do something similar for Windows groups.

My Web.config adds a claimsAuthorizationManager for authorizing access to the web api. Not sure if that is the right way to do it in Katana but it works. I'm currently running the server on IIS but would like to be able to try it out self-hosted as well.

The server is just exposing webapi endpoints; there's no web site or mvc stuff. I could run two separate servers but would prefer one if it's possible.

Thanks for looking into this.
Oct 14, 2013 at 5:31 PM
Set IIS to allow Anonymous in addition to Windows Auth, then un-comment UseWindowsAzureBearerToken. With this config DenyAnonymous should send back a 401, and you'll be issued a challenge for Azure (as a redirect?), but I don't think you'll be issued a challenge for WindowsAuth (Negotiate/NTML). Correct? If so then I can show you how to issue a challenge for a specific auth type (Azure or Windows).
Oct 17, 2013 at 3:52 PM
I now have this working on my Dev machine using local IIS Express but run into problems when running on the intranet and targeting Windows Server 2008 R2. I've posted a question here (not sure if that's the best place) describing the problem.

DenyAnonymous does send back a 401 but also a challenge for WindowsAuth (Negotiate/NTLM). I'm logging the calls and on my dev machine can see an unauthenticated request arriving followed by the same request with AuthenticationType='Negotiate'. Unfortunately, on the intranet this is not playing nicely with the async on the client.

I'm not sure where to head next with this.
Oct 17, 2013 at 5:43 PM
Looks like a known bug in HttpClient. I think it's fixed in .NET 4.5.1 (releasing very soon).

It also looks like you can work around the issue by doing the auth on a HEAD request first.