2
votes

I have some old school .NET ASMX web services that I want to consume from ASP.NET Web Apps that I am hosting on Azure. The old services are authenticated using Active Directory Windows Authentication(Update) but the ASP.NET Web Apps are authenticated using Azure AD. What is the best option to allow for the Azure AD Web app to call those ASMX Web Services that are expecting an Windows Authentication token?

Here's how my ASMX services are setup today. In the web.config:

<authentication mode="Windows" />

There is also impersonation turned on:

<system.web><identity impersonate="true"></identity>

The code of the web services use the Windows Identity inside of its code so its important that we are able to resolve the correct Windows Identity. Here is how we reference the user's principal:

System.Security.Principal.WindowsIdentity.GetCurrent().Name

The new Web App has its authentication setup using Microsoft OWIN. We created an application in Azure AD. So all that we have are claims coming from Azure AD within the Web App.

UPDATE: It looks like the information on my configuration was a bit off. We are not using ADFS, we are using straight Windows Auth in the ASMX services.

UPDATE 2: I've tried setting up Azure AD Application Proxy to transform the claims into Windows auth token required by my legacy on premise web services.

So instead of making a call to here:

https://myServer/MyServices/MyService.asmx

When I access this URL in a browser, I get the standard Windows Auth login, I enter my credentials and I can use the ASMX service harness to call the Service Methods.

I'm now making a call to this URL:

https://mystuff.msappproxy.net/MyServices/MyService.asmx

The funny thing is when I go to this URL, I get redirected to Azure AD and login and then I can use the Service Methods. When I monitor the HTTP traffic, I notice that a cookie is being attached to the request when I invoke my web service.

AzureAppProxyAccessCookie_{guid}_1.1

However, when I use my Azure AD authenticated web site, it makes javascript calls to the MyService.asmx web service and I get an HTTP 302 FOUND with a URL that looks like this:

https://login.live.net/{guid}/oauth2/authorize?response_type=id_token&client_id={guid}&redirect_uri=https://mystuff.msappproxy.net/MyServices/MyService.asmx

It appears its trying to do it but maybe the token issued by Azure AD to my Web App is not getting translated into the token that the Azure AD Application Proxy can use?

UPDATE 3:

In order to isolate the issue further I tried creating a sample Ajax Get request with hard coded html encoded request body. I created the sample jQuery call in one of the POC apps I have playing with. However getting a redirect CORS error in the browser’s console: https://mystuff.msappproxy.net/

Here is the isolated javascript call I am making from the Web App.

    function GetASMX()
{
    $.ajax({
        url: "https://mystuff.msappproxy.net/MyServices/MyService.asmx/DoSomething?parameter=[stuff]",
        type: 'GET',
        xhrFields: {
            withCredentials: true
        },
        crossDomain:true,
        success: function (e) {
            alert('Api App Returns: ' + e);
        }
    });
}

CORS is enabled on the ASMX side. I need to find out why is this happening. It seems like this might be related.

1

1 Answers

0
votes

There is no obvious way. At high level, if you have admin access to your ADFS you could set an identity provider trust with your Azure AD tenant: that would give you the chance of traverse the trust chain so that your Azure AD users can exchange an Azure AD token for an ADFS one. That's the theory. In order to move to the implementation phase, one would need more details about the protocol you are currently using for securing calls to your ASMX services. If you are simply making ajax callas protected by cookies, that should be easy to adapt - you just get one extra redirect toward Azure AD. But if you are using ws-security and ws-trust, then you're in trouble. Neither protocols are supported by Azure AD's public surface, and in any case those protocols do not offer a clear way of handling the federation flow between two providers.