Allow option for DataProtection keys to not be cached

[maganuk]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I have a multi-tenant application where I would like for each tenant to have their own data protection keys which are saved in a DB. I find that there is no way to do this (without writing my own DataProtectionProvider) since the keys are always cached. Even if I were to write my own XML Repository, I am unable to use it on a per-request basis as the keys are already valid for a period of 24 hours.

Describe the solution you'd like

Provide an option to not cache keys so that it may be possible for developers to use their own cache and resolve keys on a per request basis.

[adityamandaleeka]

Removing milestone temporarily so it comes up in triage.

[amcasey]

@maganuk Sorry for the delay. Can you please elaborate a bit more on the problem you're encountering? Why would caching prevent you from using multi-tenancy?

[maganuk]

@amcasey thanks for picking this up.

So assume that new tenants are being registered dynamically at runtime. I'd like each tenant to have its own data protection key.

Currently, the way the Keyring provider is setup, the keys cannot be resolved at runtime. They are always picked up from the internal cache. Even if I try to implement my own IKeyManager, the keys will always be cached.

In my case I want to use my own caching layer and be able to resolve keys at runtime rather than depending on the framework to handle the caching. Further, I have a scoped Tenant Service which I need to access to resolve the current tenant to fetch the data protection key. I've therefore had to write my own DataProtectionProvider to do this. Would be better if the framework allows more flexibility for doing this.

[amcasey]

Unfortunately, the term "key" is quite overloaded in this space, so I'd like to make sure we're on the same page. The way Data Protection expects to enable multi-tenancy is through purpose strings, the values of which can be specified dynamically. Separate derived keys (sometimes called Data Encryption Keys (DEKs)) will be created for each purpose.

Is this the sort of key you're referring to when you say you "like each tenant to have its own data protection key"?

[maganuk]

Actually no, I mean a separate master key for each tenant. The reason I say that is because as part of our product offering (it's an IAM service), we would like to offer our customers the ability to store these keys at their end or take the keys with them when they migrate away from us. We are using the derived keys too, but they are scoped to different purposes within a tenant.

[amcasey]

I think it's great that you're giving your customers that level of control, but that scenario's a bit outside the design goals of the data protection system. In particular, it's only intended for ephemeral (i.e. expendable) data, which there would normally be no reason to export. If you did want to offer some sort of export functionality, I would think you'd want to decrypt the data on-demand and then re-encrypt it with a new key specifically for/from that customer.