问题
We have an ASP.NET core 2.2 web application exposing some web api controllers. Our application does not have any kind of authentication mechanism, all the exposed endpoints can be called by an anonymous user.
When we host the application under IIS we get three strange warning messages at the application startup. These are the logs we get:
- 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 {GUID} may be persisted to storage in unencrypted form.
All these logs have Microsoft.AspNetCore.DataProtection as the log context and are written by the ASP.NET core framework internals.
The meaning of these logs seems quite clear to me: there is a "key" (whatever it means) that will be persisted in-memory because no registry storage has been provided (and, of course, it will be lost when the application exits). There is also a warning indicating that this key, if persisted, won't be encrypted in any way.
At this point I would ask the following questions:
- what is the GUID reported inside the logs with the name "key" ? What is used for ?
- is there any security risk associated with this warnings ?
- should I take any action ?
SOME ADDITIONAL INFORMATION:
Some blogs online suggest that these kind of data protection warnings are related to the usage of ASP.NET identity, but we don't use identity in our app (we have no authentication enabled). Other blogs suggests to setup the hosting application pool in order to load the user profile: I already tried that, but the warnings are still there.
IMPORTANT UPDATE 2nd April 2019
I solved the issue thanks to the help of the asp.net core dev team. For a complete reference see the github issue I opened yesterday
Put it briefly the issue is related to the IIS configuration on my development machine. In order for the ASP.NET core data protection to work as expected there are some specific configuration for IIS and the hosting application pool (see here for a complete reference)
UPDATE 13th SEPTEMBER 2019
For the ones having the same warnings inside their ASP.NET core 2.2 web applications I suggest to take a look at this github issue.
We now have added cookie authentication to our product and we need to support the kubernetes hosting. In kubernetes with the cookie authentication the warnings discussed in this stackoverflow question are relevant, because you have to provide ASP.NET core with a place where storing the keys needed by the ASP.NET core data protection system.
We opted to implement a persistent key ring in MongoDB. Some details can be found here. I can't show the code here (the project is not open source), but we have basically started from the official entity framework core key ring store and substituted all the usages of entity framework db context with an injected IMongoCollection<DataProtectionKey>. We have also modified the DataProtectionKey class by removing the Id property (we prefer letting MongoDB generating its own object ids).
回答1:
Data Protection is used by various components to encrypt data at runtime, for example:
- Authentication cookies
- Identity password reset tokens
You can read more about it in the docs: https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/introduction?view=aspnetcore-2.2
You understood the warnings correctly, it has created a key but couldn't decide where to store the key. So it'll be lost if the app restarts. If you don't use e.g. authentication cookies, you may be able to ignore these warnings. You can also configure a storage location, outside your app's folder.
回答2:
If you're not using any authentication mechanism (ex: ASP.NET Core Identity which is using this type of keys) and if you're not using DataProtection API somewhere else you're good to go (for now).
What happens there?
You entered a fallback mechanism for storing keys (in memory storage). You will lose your keys when your app will get restarted.
What problems you can face?
Example: If you're using authentication mechanisms, you will end up with screwed authentication cookies, email validation tokens, reset password tokens, etc
What you can do right now?
If you want (future-proof solution) you can store the keys somewhere (ex: Redis).
Further reading: https://cypressnorth.com/programming/solved-using-memory-repository-keys-will-not-persisted-storage-asp-net-core-iis/
来源：https://stackoverflow.com/questions/55452756/asp-net-core-2-2-web-api-logs-warnings-related-to-data-protection-keys-how-shou