Question

我有一些旧的.NET ASMX Web服务，我想从我在Azure上托管的ASP.NET Web Apps中使用它。使用Active Directory Windows身份验证（更新）对旧服务进行身份验证，但使用Azure AD对ASP.NET Web Apps进行身份验证。允许Azure AD Web应用程序调用期望Windows身份验证令牌的ASMX Web服务的最佳选项是什么？

以下是我今天的ASMX服务设置方式。在web.config中：

<authentication mode="Windows" />

还开启了假冒行为：

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

Web服务的代码在其代码中使用Windows标识，因此我们能够解析正确的Windows标识非常重要。以下是我们引用用户主体的方式：

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

新的Web App使用Microsoft OWIN进行身份验证设置。我们在Azure AD中创建了一个应用程序。因此，我们所拥有的只是来自Web App中Azure AD的声明。

更新：我的配置信息看起来有些偏差。我们没有使用ADFS，我们在ASMX服务中使用直接的Windows Auth。

更新2 ：我已尝试设置Azure AD应用程序代理，以将声明转换为我的旧内部部署Web服务所需的Windows身份验证令牌。

所以不要打电话到这里：

https://myServer/MyServices/MyService.asmx

当我在浏览器中访问此URL时，我获得了标准的Windows Auth登录，我输入了我的凭据，我可以使用ASMX服务线束来调用服务方法。

我现在正在调用此网址：

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

有趣的是，当我转到此URL时，我被重定向到Azure AD并登录，然后我可以使用服务方法。当我监控HTTP流量时，我注意到当我调用我的Web服务时，cookie正附加到请求上。

AzureAppProxyAccessCookie_ {GUID} _1.1

但是，当我使用我的Azure AD身份验证网站时，它会对MyService.asmx Web服务进行javascript调用，并且我得到一个HTTP 302 FOUND，其URL看起来像这样：

https://login.live.net/ {GUID} /的oauth2 /授权RESPONSE_TYPE = id_token＆安培; CLIENT_ID = {GUID}＆安培; REDIRECT_URI = https://mystuff.msappproxy.net/MyServices/MyService.asmx

它似乎试图这样做但是Azure AD发布到我的Web App的令牌可能没有被转换为Azure AD应用程序代理可以使用的令牌？

更新3：

为了进一步隔离问题，我尝试使用硬编码的html编码请求体创建一个示例Ajax Get请求。我在我玩过的一个POC应用程序中创建了示例jQuery调用。但是在浏览器的控制台中获取重定向CORS错误： https://mystuff.msappproxy.net/

以下是我通过网络应用程序进行的隔离式JavaScript调用。

    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);
        }
    });
}

ASMX端启用了CORS。我需要找出为什么会发生这种情况。看起来这可能是related。

Answer 1

没有明显的方法。在较高级别，如果您具有ADFS的管理员访问权限，则可以与Azure AD租户设置身份提供商信任：这将使您有机会遍历信任链，以便Azure AD用户可以交换Azure AD令牌ADFS一个。这就是理论。为了进入实施阶段，需要有关当前用于保护ASMX服务调用的协议的更多详细信息。如果你只是简单地使用cookie保护ajax callas，那么它应该很容易适应 - 你只需要一个额外的重定向到Azure AD。但是如果你使用的是ws-security和ws-trust，那么你就麻烦了。 Azure AD的公共表面都不支持这两种协议，并且在任何情况下，这些协议都不提供处理两个提供程序之间的联合流的明确方法。

在Azure AD和Windows Auth / AD

1 个答案: