EphemeralDataProtectionProvider isn't used by XmlKeyManager

[charles-slc]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Was noticing the following warning messages, from Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager in the logs for our C# API application running as an AWS Lambda Function

Using an in-memory repository. Keys will not be persisted to storage.
Neither user profile nor HKLM registry available. Using an ephemeral key repository. Protected data will be unavailable when application exits.
No XML encryptor configured. Key {1b2f40f0-fd24-439a-8f31-620d12828a8b} may be persisted to storage in unencrypted form.

This issue, Explicitly specifying UseEphemeralDataProtectionProvider should NOT log a warning

And this issue An error occurred while reading the key ring

Along with the documentation

application itself is transient ... This type provides a basic implementation of IDataProtectionProvider whose key repository is held solely in-memory and isn't written out to any backing store.

Led us to expect that adding
builder.Services.AddDataProtection().UseEphemeralDataProtectionProvider();

Would get rid of the Warnings, however it had no effect.

I'm no expert, but looking at the code it seems that XmlKeyManager is not really connected to EphemeralDataProtectionProvider or if it is, the AddDataProtection() is setting up the XmlKeyManager before the builder.Services.Replace(ServiceDescriptor.Singleton<IDataProtectionProvider, EphemeralDataProtectionProvider>()); line in UseEphemeralDataProtectionProvider kicks in.

Or maybe we are missing something else somewhere.

Expected Behavior

Given a C# API application, that handles authorization via JWT bearer tokens, we need an easy way to start it without seeing warning messages from an XmlKeyManager that we don't actually need as far as we can tell.

When running in AWS Lambda, we can prevent the first two message

Using an in-memory repository. Keys will not be persisted to storage.
Neither user profile nor HKLM registry available. Using an ephemeral key repository. Protected data will be unavailable when application exits.

By setting the APPLOCALDATA environment variable to a writable location, `"/tmp/".

But it would seem that the only current way to prevent the third is to

• use ProtectKeysWithCertificate() and a x.509 certificate
• write our own IXmlKeyManager as in this issue Allow data protection without writable storage

Both of which seem to be way overkill.

Steps To Reproduce

Here's a basic app created from a AWS template.
https://github.com/charles-wilt/Lambda.Minimal

I added the
builder.Services.AddDataProtection().UseEphemeralDataProtectionProvider(); line to Program.cs

When started, you can see that the XmlKeyManager is still being stood up with defaults...

Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager: Information: User profile is available. Using 'C:\Users\CHARLES.WILT\AppData\Local\ASP.NET\DataProtection-Keys' as key repository and Windows DPAPI to encrypt keys at rest.

Exceptions (if any)

No response

.NET Version

7.0.400

Anything else?

No response

[martincostello]

Another possible low-effort approach you can take today is to change the log level for these specific types when you're not concerned about their output: https://github.com/martincostello/dependabot-helper/blob/415acd4ddbad4ea5c615c39014c9a37d7fdf81c6/src/DependabotHelper/appsettings.json#L33

[charles-slc]

Yeah, we recognize that we could set logging for Microsoft.AspNetCore.DataProtection to "Error" instead of the default "Warning". But we'd rather not suppress any possible future valid warnings.

[martincostello]

My point was mainly that there's easier options than implementing your own XML repository if it's bugging you.

Another option is to use the https://www.nuget.org/packages/Amazon.AspNetCore.DataProtection.SSM package and have the Lambda not use ephemeral keys by reading/storing them in SSM. There's also a similar community package that uses S3, but that's been deprecated for a while.

[charles-slc]

Thanks for the package link...I was unaware of it...
I'll see what effects using it has.
And it the warnings don't bug me...they bug management 🙄

[amcasey]

This appears to express the same concern as #47410. Any objection to dup'ing against that issue?

[amcasey]

I'm taking that as "no objection".