Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
Continuing from my last post on
Configuring ASP.NET Core behind a Load Balancer, the next hurdle you may run into is with ASP.NET Core Data Protection.
Specifically I was using Cookie Authentication (without Identity).
In this scenario, ASP.NET Core’s Data Protection must share the same key ring and app identifier for each instance of your application. This means if you are load balanced across multiple containers or even machines, you must configure ASP.NET Core’s Data Protection system.
If you do not, the process that generates your authentication cookie (or bearer token) will be the only process that will be able to read it.
ASP.NET Core Data Protection
Thankfully, there are a a few different solutions that I’d like to point out across Azure, AWS and Redis.
Azure Blob Storage
There is an official package
Microsoft.AspNetCore.DataProtection.AzureStorage that allows you to store your data protection keys in Azure storage. Just use one of the overloads of the
PersistKeysToAzureBlogStorage.
Redis
This is another official package
Microsoft.AspNetCore.DataProtection.Redis that allows you to store it to Redis. Use one the
PersistToRedis methods to configure to your needs.
AWS S3 & KMS
If you are using AWS, you have a couple options as well with a couple community packages
AspNetCore.DataProtection.Aws.S3 and
AspNetCore.DataProtection.Aws.Kms. You can find info and usage on
GitHub.
Here’s how to quickly configure using using S3.
Key Storage Providers
Are you using any other key storage providers? Please let me know in the comments or on Twitter.