We Keep Coding

.NET Core 6 : to protect potentially sensitive information in your connection string

How do I move sensitive information below into the 'The Secret Manager Tool'?
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
=> optionsBuilder.UseSqlServer("Server=Test; column encryption setting=enabled;Database=Test;user id=User1;password='Password1';Trust Server Certificate=true");
I know I can right click on the solution name and select "Manage User Secrets", which then generates the secret Json file, but what I am pasting into this file?
And when I move this application over to the production server, do I copy & paste over the secret.json as well?
Thanks in advance.

You need to take a small step back and consider tools ASP.NET Core/.NET provides to work with configuration.
From DbContext Lifetime, Configuration, and Initialization doc you can see that one of the common pattern is to use dependency injection and setup the the connection string on application startup. This will require adding constructor to the context (and modifying/removing OnConfiguring overload - docs):
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}
}
And:
builder.Services.AddDbContext<ApplicationDbContext>(
options => options.UseSqlServer("ConnectionStringHere")); // or AddDbContextFactory
Next step is to read the connection string from the settings:
builder.Services.AddDbContext<ApplicationDbContext>(
options => options.UseSqlServer(builder.Configuration.GetConnectionString("ConnStringName"))); // or AddDbContextFactory
Which will require connection string to be read from the configuration, for example from appsettting.json:
{
"ConnectionStrings": {
"ConnStringName": "ACTUAL_CONNECTION_STRING"
},
}
Also you can move connection string to any of the supported configuration providers, for example - Secret Manager (note, it is for development environment only, for other environments is better to use either environment variables or secured key storages).

In the production server you need to create a configuration key with the same name with the production connection string.
Set the ASPNETCORE_ENVIRONMENT variable to "Production"
When environment "ASPNETCORE_ENVIRONMENT" is in "Production" the secrets.json source is ignored. You can check this in Default application configuration sources
According to ASP.NET Core documentation
WebApplication.CreateBuilder initializes a new instance of the WebApplicationBuilder class with preconfigured defaults. The initialized WebApplicationBuilder (builder) provides default configuration for the app in the following order, from highest to lowest priority:
Command-line arguments using the Command-line configuration provider.
Non-prefixed environment variables using the Non-prefixed environment variables configuration provider.
User secrets when the app runs in the Development environment.
appsettings.{Environment}.json using the JSON configuration provider. For example, appsettings.Production.json and appsettings.Development.json.
appsettings.json using the JSON configuration provider.
A fallback to the host configuration described in the next section.

When running production apps in AWS, GCP, or Azure, we keep all secrets in the cloud provider's respective secret manager (e.g. AWS Secrets Manager) and use scripting when the runtime environment is created to inject those secrets into environment variables.
Note, by Secrets Manager, I don't mean the .NET Secret Manager, which merely stores secrets in a file on the development machine.
.NET can read configuration from the environment, including connection strings.
With this approach, only trusted DevOps personnel ever have the ability to view a connection string. It is never in a file, and certainly never in source control.

Best that you can do for the connection string in the production server is to configure windows authentication.
There must be a network user configured. This user should be given permissions in the SQL Server.
When you configure your Web server pool, run this pool under identity created in #1
At this point your connection string will look like this Server=MyServerName;Database=MyDbName;Trusted_Connection=SSPI;Encrypt=false;TrustServerCertificate=true. As you see - no password or user
With this setup, unless attacker knows password to the account under which your pool runs, this is plenty secure.
If you insist in using Sql Authentication, you need to store your credentials in the secure secrets manager (even if homegrown) and then acquire them and build connection string at runtime.

Use json app settings instead of system environment variables

I am working with a asp.net core project which will have 2 environments that I deploy to a single server, staging and production. My aim is to make staging use the appsetting.json file instead of window environment variable.
I have set up a environment variable on the server.
Environment variable
In my appsettings.json file, I have the process setting with a different value.
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft": "Warning",
"Microsoft.Hosting.Lifetime": "Information"
}
},
"Process": "Not ABC"
}
This is the code to retrieve it in my project.
string process = _config.GetValue<string>("Process");
Issue is both staging and production are on the same server meaning they using the same environment system variable. Both situations, the enviroment variable overrides the one in appsettings.json.
I want staging to use the appsettings.json. Is there a way to do this?
I tried looking over the internet and can't find any solution.

Leveraging the information from documentation: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-6.0
I propose the following:
Create app settings for both production and Staging.
Create two releases, one for staging and one for production.
In the production configuration file, omit the values you want to load from environment variables.
Add the environment provider first and the app setting one second
In the Staging app config, add your values.
This way, the Staging value will come from the app settings file and the production from the environment variable.

Two connection strings for local and hosting server

I would like to ask if there is a way to tell ASP.NET Core 2 to choose different connection strings.
It is quite annoying to keep changing the connection string in the appsettings.json file every time I publish my website to the hosting server..
I am using this code to get connection string.
services.AddDbContext<AppIdentityDbContext>(options =>
options.UseSqlServer(Configuration["Data:WebDataBase:ConnectionString"]));
Maybe there is an easy way but I am thinking of using an if statement in my Startup.cs:
if (local) {
services.AddDbContext<AppIdentityDbContext>(options =>
options.UseSqlServer(Configuration["Data:WebDataBase1:ConnectionString"]));
}
else {
services.AddDbContext<AppIdentityDbContext>(options =>
options.UseSqlServer(Configuration["Data:WebDataBase2:ConnectionString"]));
}
But how can I set this local variable whether the server is my local computer or a live hosting server?
"Data": {
"WebDataBase1": {
"ConnectionString": "Data Source=DatasoruceName;Initial Catalog=DBname;Trusted_Connection=True;Integrated Security=True;"
},
"WebDataBase2": {
"ConnectionString": "Data Source=DatasoruceName;Initial Catalog=DatabaseName;Trusted_Connection=True;Integrated Security=True;"
}
}

Environment specific configuration is not supposed to be specified within code. ASP.NET Core has a mechanism for that which allows you to swap out the configuration dependending on what environment you run on.
While developing your application, you usually run in the Development environment. When you are deploying your application for production, the Production environment is used by default. But if you have other environments, you can totally make up new names for those too and have specific configurations for them. That all is explained in the Environments chapter of the documentation
What environments allow you to do is create multiple appsettings.json files. The ASP.NET Core by default comes with two files: appsettings.json and appsettings.Development.json.
The former is supposed to contain environment unspecific configuration; things that apply to all environments. The latter file contains development-specific configuration and for example adjusts the logging level so that you get more information during development. You can also use these files to specify a default connection string within appsettings.json and overwrite that for development within appsettings.Development.json.
Furthermore, the configuration file follows a very simple pattern: appsettings.<Environment>.json. So if you run in the Production environment, a file named appsettings.Production.json will be loaded if it exists. This mechanism allows you to configure all your environments differently without having to resort to detections within your code.
In addition, there is also the concept of user secrets during development. These are for development-specific configurations that do only apply to yourself but not for example to other members of your team. This is basically a per-machine configuration that allows you to overwrite both the appsettings.json and the appsettings.Development.json. This is described in the user secrets chapter.
Best practice is to avoid connection strings altogether within configuration files though, since you want to avoid that people that happen to have access to your configuration files (for example through your source code) can know the passwords to your database. In that case you can use other mechanisms, for example environment variables that are local to the process.
In your case, where you are just using integrated security, and as such rely on the credentials of the current user, this is not that much of a problem. The only thing you are leaking is the database name. – So you can definitely start out with putting the connection strings into the appsettings files.
So for example, this is how you would configure your database context within your Startup’s ConfigureServices:
services.AddDbContext<AppIdentityDbContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("WebDataBase"));
Your appsettings.Development.json would look like this:
{
"ConnectionStrings": {
"WebDataBase": "Data Source=DatasourceName;Initial Catalog=DBname;Trusted_Connection=True;Integrated Security=True;"
}
}
And your appsettings.Production.json would look like this:
{
"ConnectionStrings": {
"WebDataBase": "Data Source=DatasourceName;Initial Catalog=DatabaseName;Trusted_Connection=True;Integrated Security=True;"
}
}

Hide/Encrypt passwords and keys in an Azure Data Factory Project

I have an Azure Data Factory Visual Studio Project within a GitHub repository, and as part of the configuration I have a few linked services, for example, one for an Asure SQL Database, Azure Blob and one for an Azure Batch, all of these linked services have a connection string or account key.
{
"$schema": "http://datafactories.schema.management.azure.com/schemas/2015-09-01/Microsoft.DataFactory.LinkedService.json",
"name": "odsLS",
"properties": {
"description": "Connection to ODS database",
"type": "AzureSqlDatabase",
"typeProperties": {
"connectionString": "Data Source=tcp:<data_base_server>,1433;Initial Catalog=<data_base_name>;User ID=<user_name>;Password=<password>;Integrated Security=False;Encrypt=True;Connect Timeout=30"
}
}
}
I don't want to save the sensitive data (passwords, keys etc) to my repository, only change it in the publish to Azure process.
How can I manage this?

ADFSecurePublish supports store secrets in Azure Key Vault and only need to specify the reference to them in the linked services. Refer to: https://github.com/Azure/Azure-DataFactory/tree/master/Samples/ADFSecurePublish

another option would be to use configuration files which you do not check-in to GitHub

Trying to host a test site with Azure, but SQL Database won't transfer

I am a new web developer and am trying to host a test site with Azure test services.
I can see the test site(you can access this to test ) at: http://kencast20160830102548.azurewebsites.net/
However, if you go to the Services -> Fazzt --> Equipment and Applications pages, I get this error:
Error.
An error occurred while processing your request.
Development Mode
Swapping to Development environment will display more detailed information about the error that occurred.
Development environment should not be enabled in deployed applications, as it can result in sensitive information from exceptions being displayed to end users. For local debugging, development environment can be enabled by setting the ASPNETCORE_ENVIRONMENT environment variable toDevelopment, and restarting the application."
These pages are relying on a SQL database, so I think this is where the problem is.
I've been trying to follow along with the directions published here: https://docs.asp.net/en/latest/tutorials/publish-to-azure-webapp-using-vs.html
however I cannot find the "Configure SQL Database" pop-up box when logged into my Microsoft Azure account.
The directions do not seem to go along with what exists in Azure.
Update- 8/31/2016
I have researched and learned a bit more:
I have one project with two DBContexts.
When I publish to Azure, it publishes tables from ApplicationDBContext but not the tables from MyCompanyContext. I can verify using SQL Server Object Explorer.
I can see my local connection strings in appsettings.json file for both ApplicationDB and MyCompanyDB. Here is the code from appsettings.json:
{
"ConnectionStrings": {
"DefaultConnection": "Server=(localdb)\\mssqllocaldb;Database=aspnet-MyCompany-3097a012-5e00-4c25-ad83-2730b4d73b4b;Trusted_Connection=True;MultipleActiveResultSets=true"
},
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Debug",
"System": "Information",
"Microsoft": "Information"
}
},
"Data": {
"MyCompanyContext": {
"ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=MyCompanyContext-f9de2588-77e8-41dd-abb3-84341610b31a;Trusted_Connection=True;MultipleActiveResultSets=true"
}
}
}
However, when I look at the "SQL Server Object Explorer" window, I see that the database hosted on Azure, mycompanydb.database.windows.net(SQL Server 11.0.9231 -mycompanydb, MyCompany_db) only has the tables from the "DefaultConnection" database, and nothing from "MyCompanyContext".
How do I get the tables from the second database (MYCompanyContext) to Azure?
I have been studying this Stack Overflow response, but it uses Enable-Migration in the PMC. When I do that, I get an error that enable-migrations is obsolete.
Locally, I have always done migrations with this:
add-migrations -c MyCompanyContext
Any help you could give me would be greatly appreciated.
Thanks!

From the comments, I am guessing you need to ensure both your contexts are applied in the startup class like this
services.AddEntityFramework().AddSqlServer()
.AddDbContext<MyCompanyContext>(options => options.UseSqlServer(Configuration.Get("Data:SQL")))
.AddDbContext< ApplicationDBContext >(options => options.UseSqlServer(Configuration.Get("Data:SQL")));
the above assumes two things:
1) you have the connection string set up like this in your appsettings.json
"Data": {
"SQL": "Server=tcp:yourDbServer.database.windows.net,1433;Initial Catalog=yourDb;Persist Security Info=False;User ID=youId;Password=YourPswd;MultipleActiveResultSets=True;TrustServerCertificate=False;Connection Timeout=30;",
}
2) Both the contexts share the same Db, if not then substitute the appropriate connection string (make sure to have it matched to the way you have it in your appsettings.json) for the context like this sample:
.AddDbContext<MyCompanyContext>(options => options.UseSqlServer(Configuration.Get("Data:SQL2")));