在 Azure AD 和 Windows Auth / AD 之间转换令牌

Question

我有一些老式的 .NET ASMX Web 服务，我想从我在 Azure 上托管的 ASP.NET Web 应用程序中使用这些服务。旧服务使用 Active Directory Windows 身份验证（更新）进行身份验证，但 ASP.NET Web 应用使用 Azure AD 进行身份验证。允许 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 应用程序使用 Microsoft OWIN 进行身份验证设置。我们在 Azure AD 中创建了一个应用程序。因此，我们所拥有的只是来自 Web 应用中的 Azure AD 的声明。

更新：看来我的配置信息有点不对劲。我们没有使用 ADFS，我们在 ASMX 服务中使用直接的 Windows 身份验证。

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

所以不要打电话到这里：

https://myServer/MyServices/MyService.asmx

当我在浏览器中访问此 URL 时，我会获得标准的 Windows 身份验证登录，我输入我的凭据，然后我可以使用 ASMX 服务工具来调用服务方法。

我现在正在调用此 URL：

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/authorize?response_type=id_token&client_id={guid}&redirect_uri=https://mystuff.msappproxy.net/MyServices/MyService.asmx

它似乎在尝试这样做，但 Azure AD 向我的 Web 应用程序发出的令牌可能没有被转换为 Azure AD 应用程序代理可以使用的令牌？

更新 3：

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

这是我从 Web 应用程序进行的孤立的 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 的公共表面不支持这两种协议，并且无论如何这些协议都没有提供一种明确的方式来处理两个提供者之间的联合流。