-
This might be how it has to work, but all of the methods for DataProtection across multiple web servers requires creating some kind of shared data source, such as DB, AKV or blob storage, which creates both a single point of failure and also has a performance overhead that is not insignificant. Is it possible/it should be possible to generate deterministic keys using data that can shared across web servers at install time like an X509 cert or similar. That way, if a user is sent to another web server than where their session cookie was created (ditto for temp data) then the second server should be able to determine/derive the same key as the first server and decrypt the cookies. Was this a design decision or is there a more fundamental reason for this? Are there any workarounds other than not encrypting session cookies? Thanks |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
The main reason for the current design is to fully support periodic, overlapping key rotation. That's hard to do with static keys. |
Beta Was this translation helpful? Give feedback.
-
I was looking at the example that show: services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"))
.ProtectKeysWithCertificate(
new X509Certificate2("certificate.pfx", "password")); So it looks like it would work with X509 certs, which are rotated, the confusing part is that the examples all show persisting to a shared location. I haven't tried to see what happens if I persist to the local file system but that was my thinking, this way, hitting a new server doesn't require a network trip, it will simply look for a key and if not found, will create it with the same cert? |
Beta Was this translation helpful? Give feedback.
I was looking at the example that show:
So it looks like it would work with X509 certs, which are rotated, the confusing part is that the examples all show persisting to a shared location. I haven't tried to see what happens if I persist to the local file system but that was my thinking, this way, hitting a new server doesn't require a network trip, it will simply look for a key and if not found, will create it with the same cert?