我们有一个ASP Core 2.0应用程序,可与公共网络上的Azure AD很好地配合使用。我们的测试环境在Azure ASE中运行。用户以经过Azure应用网关的公共地址开头,并被路由到ASE中的2个应用服务器中的1个。该应用程序使用指定公共地址的响应URL在Azure AD中注册。
问题是当用户重定向到登录时,提供给Azure AD的请求地址是来自两台服务器之一的内部地址。然后,响应URL不匹配,登录时会出错。
问题是如何将公共地址呈现给Azure AD,以便响应URL的匹配和令牌使用相同的地址发布回应用程序?有人告诉我,应用程序网关配置为填充具有原始地址的x-forwarded-for标头。我看不到可以在Web应用程序中控制什么位置。 startup.cs
services.AddAuthentication(sharedOptions =>
{
sharedOptions.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
sharedOptions.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
})
.AddAzureAd(options =>
{
Configuration.Bind("AzureAd", options);
AzureAdOptions.Settings = options;
})
.AddCookie();
AccountController.cs
public IActionResult SignIn()
{
var redirectUrl = _azureAdOptions.WebBaseUrl;
return Challenge(
new AuthenticationProperties { RedirectUri = redirectUrl },
OpenIdConnectDefaults.AuthenticationScheme);
}
我认为这是一种常见的配置-将公共资源传递到集成了SSO的专用服务器。
[编辑]
基于注释中提供的链接,该链接非常有帮助,我们尝试了多种操作,包括在startup.cs中显式设置UseforwardedHeaders,即使默认情况下应启用此功能。我们没有做任何更改,而在下面的URL中加粗了该URL。
https://login.microsoftonline.com/2ff13e34-f33f-498b-982a-7cb336e12bc6/oauth2/authorize?client_id=998c48ae-bbcf-4724-b6f4-6517e41d180a&redirect_uri=**http%3A%2F%2Flocalhost%3A2345%2Fsignin-oidc**&resource=https%3A%2F%2Fgraph.windows.net&response_type=id_token%20code&scope=openid%20profile&response_mode=form_post......
但是,也许这是一个线索,如果我们在用户单击按钮登录后在家庭控制器上注释掉[Authorize]并登录,则它可以工作。为什么?
注意:上面的ID / GUID已被加密以保护无辜者
答案 0 :(得分:0)
我碰到了this帖子,解释了Application Gateway如何不实现标准的x-forwarded-host标头。我希望此问题能够解决,因此不需要下面的代码。在我们的配置中起作用的解决方案是在每个请求上都强制使用公共域和方案(HTTPS),因为未(显然也无法将)应用网关配置为将SSL传递给后端服务器。
已添加到startup.cs
app.Use((ctx, next) =>
{
ctx.Request.Host = new HostString(options.Value.CustomDomain;
ctx.Request.Scheme = "https";
return next();
});
现在,当应用程序重定向任何安全资源时-[Authorize]控制器方法或在HTTPS上显式调用Challenge(x,y,z)的代码将用作源主机和方案。感谢@juunas指出正确的方向。