Skip to content
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

DataProtection Keys folder doesn't sync on Azure Web Sites distribution slots #2334

Closed
tmm360 opened this issue Dec 6, 2016 · 14 comments
Closed
Milestone

Comments

@tmm360
Copy link

@tmm360 tmm360 commented Dec 6, 2016

Cloned from dotnet/aspnetcore#1582 by suggest of @guardrex. @blowdart

I'm running an Asp.Net Core RC2 application on Azure Web Sites, and I noted that every time that I switch staging and production environments, all users log off. So I've tried to test what happened, and I've discovered that on staging and production's "%HOME%\ASP.NET\DataProtection-Keys" folders the keys were different. Reading this page https://docs.asp.net/en/latest/security/data-protection/configuration/default-settings.html they should be synced.

I supposed that keys may be synced by slot, so when I switch slots the keys should keep under original environment. To test this I've created a new Azure web site with two new empty slots, but when I switch environments the "%HOME%\ASP.NET" folder follows its server. This implies that keys of staging are used under production, and keys of production are used under staging. I've discovered the origin of my issue.

Two options here: I didn't understand how DataProtection is synced between distribution slots, and in this case I'm asking you to tell me how I can solve this problem, or this is a bug and the sentence on documentation is wrong. What do you think? Thank you

@guardrex
Copy link
Collaborator

@guardrex guardrex commented Dec 6, 2016

@blowdart If the answer is that the keys will follow the app as slots are swapped, then would something like this cover it ...

If the system is being hosted in Azure Web Sites, keys are persisted to the "%HOME%\ASP.NET\DataProtection-Keys" folder. This folder is backed by network storage and is synchronized across all machines hosting the application. This folder is created for each slot independently, so swapping an application's slot will move the application's keys with it. Keys are not protected at rest.

Also, it looks like they renamed the service slightly to "Azure Apps," "Azure App Service," or "Azure Web App." I thought "Azure Web Sites" was dropped at some point.

@tmm360 You should be able get some fine-grained control over this situation by using one of the other key ring providers, like Redis, Azure Blob Storage, or Azure Key Vault. Then, you could specify in startup which key store to use based on the status (staging/production) of the app.

@tmm360
Copy link
Author

@tmm360 tmm360 commented Dec 6, 2016

@guardrex Thank you, I've found the solution with the new 1.1 release. Because this I had closed the other issue.

@guardrex
Copy link
Collaborator

@guardrex guardrex commented Dec 7, 2016

@tmm360 Excellent. 👍 Yeah, let's hold on a sec here to see if @blowdart thinks a statement there about the key ring going along with the slot would be a good add. He'll get back to us soon.

@blowdart
Copy link
Contributor

@blowdart blowdart commented Dec 7, 2016

@guardrex
Copy link
Collaborator

@guardrex guardrex commented Dec 7, 2016

@blowdart ... then you want to leave the doc as it is? If so, @tmm360 can close.

@blowdart
Copy link
Contributor

@blowdart blowdart commented Dec 7, 2016

@guardrex
Copy link
Collaborator

@guardrex guardrex commented Dec 7, 2016

I was a bit confused tho by the OP description of its behavior. I think I'm clear on it now.

The relevant section is (1) at https://github.com/aspnet/Docs/blob/master/aspnetcore/security/data-protection/configuration/default-settings.md#key-management

Helpful language might be something like ...

  1. If the system is hosted in Azure Web Apps, keys are persisted to the "%HOME%\ASP.NET\DataProtection-Keys" folder. This folder is backed by network storage and is synchronized across all machines hosting the application. This folder supplies the key ring to all of the system's slots, so swapping an application's slot will not change the key ring used. If you desire slot-dependent key rings, use an external key ring provider, such as Azure Blob Storage, Azure Key Vault, a SQL store, or Redis cache. Keys are not protected at rest.
@blowdart
Copy link
Contributor

@blowdart blowdart commented Dec 7, 2016

Wrong way around :)

This folder supplies the key ring to all instances of an application in a single deployment slot. Seperate deployment slots such as Staging and Production will not share a keyring. When you swap between deployment slots, for example swapping staging to production, or using A/B testing any system using data protection will not be able to decrypt stored data using the keyring inside the previous slot. This will, for example, lead to users being logged out of an ASP.NET application which uses the standard ASP.NET cookie middleware, as it uses data protection to protect its cookies. If you desire slot-independent key rings, shared between multiple slots, use an external key ring provider, such as Azure Blob Storage, Azure Key Vault, a SQL store, or Redis cache.

Does that cover it @tmm360 ?

@tmm360
Copy link
Author

@tmm360 tmm360 commented Dec 7, 2016

Yes, it does! Thank you.

@guardrex
Copy link
Collaborator

@guardrex guardrex commented Dec 7, 2016

Ah ... that's what I originally had in my first response. I guess I did understand the OP after all. 😄

@tmm360
Copy link
Author

@tmm360 tmm360 commented Dec 7, 2016

Yes, you did ;) Maybe my question was not very well exposed...

@blowdart
Copy link
Contributor

@blowdart blowdart commented Dec 7, 2016

This is the joy of reading issues in email :) @guardrex do you want to submit the doc update? We're still suffering from the effects of moving buildings

@guardrex
Copy link
Collaborator

@guardrex guardrex commented Dec 7, 2016

@tmm360 Nah ... it's me. I'm a goofy green dinosaur! lol

@blowdart Yeah ... I'll take care of it right now. I'll use that text block you just provided and ping you on the PR.

@tmm360 No need to sweat closing this. The issue will auto-close when the PR goes in. Thanks for mentioning this. I'm just a community guy, but I'm sorry someone didn't catch your issue sooner. It was a good issue ... things are just crazy busy these days with .NET, and it slipped thru the cracks.

@tmm360
Copy link
Author

@tmm360 tmm360 commented Dec 7, 2016

Eheh, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.