ASP.NET Core 2.1 cookie 身份验证似乎具有服务器关联性
ASP.NET Core 2.1 cookie authentication appears to have server affinity
我正在 ASP.NET Core 2.1 中开发一个应用程序,并将其 运行 安装在 Kubernetes 集群上。我已经使用 OpenIDConnect 实现了身份验证,使用 Auth0 作为我的提供商。
一切正常。用 [Authorize]
属性标记的操作或控制器将匿名用户重定向到身份提供者,他们登录,重定向回来,Bob 是你的叔叔。
当我将部署扩展到 2 个或更多容器时,问题开始出现。当用户访问应用程序时,他们会登录,并且根据回调期间他们获得的容器,身份验证成功或失败。即使在身份验证成功的情况下,当用户点击他们未获得授权的容器时,反复 F5-ing 最终将重定向到身份提供者。
我的思路是,使用 cookie 身份验证,用户在他们的浏览器中存储一个 cookie,该 cookie 随每个请求一起传递,应用程序对其进行解码并获取 JWT,然后从它,并且用户已通过身份验证。这使得整个事情变得无状态,因此无论服务请求的容器如何,它都应该工作。然而,如上所述,它似乎并没有真正以这种方式工作。
我在 Startup.cs
中的配置如下所示:
services.AddAuthentication(options =>
{
options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
})
.AddCookie()
.AddOpenIdConnect("Auth0", options =>
{
options.Authority = $"https://{Configuration["Auth0:Domain"]}";
options.ClientId = Configuration["Auth0:ClientId"];
options.ClientSecret = Configuration["Auth0:ClientSecret"];
options.ResponseType = "code";
options.Scope.Clear();
options.Scope.Add("openid");
options.Scope.Add("profile");
options.Scope.Add("email");
options.TokenValidationParameters = new TokenValidationParameters
{
NameClaimType = "name"
};
options.SaveTokens = true;
options.CallbackPath = new PathString("/signin-auth0");
options.ClaimsIssuer = "Auth0";
options.Events = new OpenIdConnectEvents
{
OnRedirectToIdentityProviderForSignOut = context =>
{
var logoutUri =
$"https://{Configuration["Auth0:Domain"]}/v2/logout?client_id={Configuration["Auth0:ClientId"]}";
var postLogoutUri = context.Properties.RedirectUri;
if (!string.IsNullOrEmpty(postLogoutUri))
{
if (postLogoutUri.StartsWith("/"))
{
var request = context.Request;
postLogoutUri = request.Scheme + "://" + request.Host + request.PathBase +
postLogoutUri;
}
logoutUri += $"&returnTo={Uri.EscapeDataString(postLogoutUri)}";
}
context.Response.Redirect(logoutUri);
context.HandleResponse();
return Task.CompletedTask;
},
OnRedirectToIdentityProvider = context =>
{
context.ProtocolMessage.SetParameter("audience", "https://api.myapp.com");
// Force the scheme to be HTTPS, otherwise we end up redirecting back to HTTP in production.
// They should seriously make it easier to make Kestrel serve over TLS in the same way ngninx does...
context.ProtocolMessage.RedirectUri = context.ProtocolMessage.RedirectUri.Replace("http://",
"https://", StringComparison.OrdinalIgnoreCase);
Debug.WriteLine($"RedirectURI: {context.ProtocolMessage.RedirectUri}");
return Task.FromResult(0);
}
};
});
我花了几个小时试图解决这个问题,但一无所获。我现在唯一能想到的理论上可行的方法是使用粘性负载平衡,但这更多的是应用创可贴而不是实际解决问题。
使用 Kubernetes 的主要原因之一是它的弹性和处理缩放的能力非常好。就目前而言,我只能扩展我的支持服务,而我的主应用程序必须 运行 作为一个 pod。这远非理想。
也许某处有某种机制可以与我不知道的特定实例建立亲和力?
我希望有人能指出我正确的方向。
谢谢!
身份验证发出的 cookie 通过数据保护进行加密。默认情况下,数据保护仅限于特定应用程序或其实例。如果您需要在实例之间共享 auth cookie,则需要确保数据保护密钥持久保存到一个公共位置并且应用程序名称相同。
services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(@"\server\share\directory\"))
.SetApplicationName("MyApp");
您可以在 docs 中找到更多信息。
每当我重新启动我的 Azure 应用服务 (PaaS) 并且我的用户的 cookie 不再有效时,我 运行 都会遇到同样的问题。我的应用使用了 ASP.NET Core Identity 框架。
这里的文档解释了将数据保护配置为跨多个应用程序实例甚至多个网络应用程序的各种方法:
https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview
我发现使用 blob 存储帐户是使其正常工作的最快方式:
var storageAccount = CloudStorageAccount.Parse(configuration["Configuration key to Azure storage connection string"]);
var client = storageAccount.CreateCloudBlobClient();
var container = client.GetContainerReference("key-container");
container.CreateIfNotExistsAsync().GetAwaiter().GetResult();
services.AddDataProtection()
.SetApplicationName("Application Name")
.PersistKeysToAzureBlobStorage(container, "keys.xml");
我正在 ASP.NET Core 2.1 中开发一个应用程序,并将其 运行 安装在 Kubernetes 集群上。我已经使用 OpenIDConnect 实现了身份验证,使用 Auth0 作为我的提供商。
一切正常。用 [Authorize]
属性标记的操作或控制器将匿名用户重定向到身份提供者,他们登录,重定向回来,Bob 是你的叔叔。
当我将部署扩展到 2 个或更多容器时,问题开始出现。当用户访问应用程序时,他们会登录,并且根据回调期间他们获得的容器,身份验证成功或失败。即使在身份验证成功的情况下,当用户点击他们未获得授权的容器时,反复 F5-ing 最终将重定向到身份提供者。
我的思路是,使用 cookie 身份验证,用户在他们的浏览器中存储一个 cookie,该 cookie 随每个请求一起传递,应用程序对其进行解码并获取 JWT,然后从它,并且用户已通过身份验证。这使得整个事情变得无状态,因此无论服务请求的容器如何,它都应该工作。然而,如上所述,它似乎并没有真正以这种方式工作。
我在 Startup.cs
中的配置如下所示:
services.AddAuthentication(options =>
{
options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
})
.AddCookie()
.AddOpenIdConnect("Auth0", options =>
{
options.Authority = $"https://{Configuration["Auth0:Domain"]}";
options.ClientId = Configuration["Auth0:ClientId"];
options.ClientSecret = Configuration["Auth0:ClientSecret"];
options.ResponseType = "code";
options.Scope.Clear();
options.Scope.Add("openid");
options.Scope.Add("profile");
options.Scope.Add("email");
options.TokenValidationParameters = new TokenValidationParameters
{
NameClaimType = "name"
};
options.SaveTokens = true;
options.CallbackPath = new PathString("/signin-auth0");
options.ClaimsIssuer = "Auth0";
options.Events = new OpenIdConnectEvents
{
OnRedirectToIdentityProviderForSignOut = context =>
{
var logoutUri =
$"https://{Configuration["Auth0:Domain"]}/v2/logout?client_id={Configuration["Auth0:ClientId"]}";
var postLogoutUri = context.Properties.RedirectUri;
if (!string.IsNullOrEmpty(postLogoutUri))
{
if (postLogoutUri.StartsWith("/"))
{
var request = context.Request;
postLogoutUri = request.Scheme + "://" + request.Host + request.PathBase +
postLogoutUri;
}
logoutUri += $"&returnTo={Uri.EscapeDataString(postLogoutUri)}";
}
context.Response.Redirect(logoutUri);
context.HandleResponse();
return Task.CompletedTask;
},
OnRedirectToIdentityProvider = context =>
{
context.ProtocolMessage.SetParameter("audience", "https://api.myapp.com");
// Force the scheme to be HTTPS, otherwise we end up redirecting back to HTTP in production.
// They should seriously make it easier to make Kestrel serve over TLS in the same way ngninx does...
context.ProtocolMessage.RedirectUri = context.ProtocolMessage.RedirectUri.Replace("http://",
"https://", StringComparison.OrdinalIgnoreCase);
Debug.WriteLine($"RedirectURI: {context.ProtocolMessage.RedirectUri}");
return Task.FromResult(0);
}
};
});
我花了几个小时试图解决这个问题,但一无所获。我现在唯一能想到的理论上可行的方法是使用粘性负载平衡,但这更多的是应用创可贴而不是实际解决问题。
使用 Kubernetes 的主要原因之一是它的弹性和处理缩放的能力非常好。就目前而言,我只能扩展我的支持服务,而我的主应用程序必须 运行 作为一个 pod。这远非理想。
也许某处有某种机制可以与我不知道的特定实例建立亲和力?
我希望有人能指出我正确的方向。
谢谢!
身份验证发出的 cookie 通过数据保护进行加密。默认情况下,数据保护仅限于特定应用程序或其实例。如果您需要在实例之间共享 auth cookie,则需要确保数据保护密钥持久保存到一个公共位置并且应用程序名称相同。
services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(@"\server\share\directory\"))
.SetApplicationName("MyApp");
您可以在 docs 中找到更多信息。
每当我重新启动我的 Azure 应用服务 (PaaS) 并且我的用户的 cookie 不再有效时,我 运行 都会遇到同样的问题。我的应用使用了 ASP.NET Core Identity 框架。
这里的文档解释了将数据保护配置为跨多个应用程序实例甚至多个网络应用程序的各种方法:
https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview
我发现使用 blob 存储帐户是使其正常工作的最快方式:
var storageAccount = CloudStorageAccount.Parse(configuration["Configuration key to Azure storage connection string"]);
var client = storageAccount.CreateCloudBlobClient();
var container = client.GetContainerReference("key-container");
container.CreateIfNotExistsAsync().GetAwaiter().GetResult();
services.AddDataProtection()
.SetApplicationName("Application Name")
.PersistKeysToAzureBlobStorage(container, "keys.xml");