Skip to content

ASP.NET core 2.2 web api does not use the default data protection key management settings when hosted on IIS #8963

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
EnricoMassone opened this issue Apr 1, 2019 · 4 comments
Labels
area-dataprotection Includes: DataProtection

Comments

@EnricoMassone
Copy link

EnricoMassone commented Apr 1, 2019

Hi,

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 (put another way: we don't use ASP.NET identity at all).

When we host the application on windows machine using IIS we get 3 strange warning messages at the application startup. These are the logs we get:

  1. Using an in-memory repository. Keys will not be persisted to storage.
  2. Neither user profile nor HKLM registry available. Using an ephemeral key repository. Protected data will be unavailable when application exits.
  3. No XML encryptor configured. Key {GUID} may be persisted to storage in unencrypted form.

After some investigation on the subject i understood that these logs are related to the ASP.NET core data protection stack and, based on my understanding of the subject, I guess that we can safely ignore the warnings because we don't need authentication cookies, password reset tokens, email verification tokens and similar stuff.

My first question is just a confirmation of the previous point: is it safe for us to go on and ignore the warnings ?

We found an article that explains this specific issue.
The article refers to this Microsoft documentation which explains that the data protection stack has some defaults configuration and it should know out of the box where to store the keys it uses.

Actually, if we try to run the same application by using an Azure app service, we don't see any warning logs at startup so I can conclude that, at least in Azure, the default key location is being used as expected.

I have checked that the IIS application pool hosting the web application has the option Load User Profile set to True as explained in the article linked above, but the warning logs are still there. Why IIS is not able to use the default storage for data protection keys ? My understanding is that this issue depends only on the configuration of our local IIS. What should we check ? Is it possible to fix this issue ?

Thanks for helping

@jkotalik
Copy link
Contributor

jkotalik commented Apr 1, 2019

@Tratcher ?

@jkotalik jkotalik added the area-auth Includes: Authn, Authz, OAuth, OIDC, Bearer label Apr 1, 2019
@davidfowl
Copy link
Member

@Tratcher Tratcher added area-dataprotection Includes: DataProtection and removed area-auth Includes: Authn, Authz, OAuth, OIDC, Bearer labels Apr 1, 2019
@EnricoMassone
Copy link
Author

EnricoMassone commented Apr 1, 2019

I believe you need this https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/?view=aspnetcore-2.2#data-protection

Hi and thanks for helping. I'm going to give it a try

@EnricoMassone
Copy link
Author

I believe you need this https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/?view=aspnetcore-2.2#data-protection

I finally solved, at least on my dev machine, thanks to the guide you linked in your reply.

The issue was related to the setProfileEnvironment inside the applicationHost.config of my dev machine. I just need to perform a complete test on a server machine (I have a Windows 10 professional installation on my machine), but I guess it's going to work.

@ghost ghost locked as resolved and limited conversation to collaborators Dec 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-dataprotection Includes: DataProtection
Projects
None yet
Development

No branches or pull requests

4 participants