I have an ASP.NET web project, and I've placed a dummy connection string in my web.config file pointing to an Azure Sql database.
<add name="YurClanConnection" connectionString="Placeholder connection string" providerName="System.Data.SqlClient" />
See this article for the reasoning behind this:
http://www.hanselman.com/blog/HowToKeepYourASPNETDatabaseConnectionStringsSecureWhenDeployingToAzureFromSource.aspx
This works in production--the real connection string stored on Azure servers replaces the placeholder connection string in my project. From what I've read, putting your connection in Azure under Websites-Config in the app settings, stored as key/value pairs, is the right way to secure your connection string when using an Azure Sql database. However, this does not work in development.
What is the right way to store a connection string securely so that it works properly in both development and production, specifically when using an Azure Sql database?
Here is how I have worked with databases locally and in Azure.
On the dev machine, have a database and your connections string
In Azure, create an Azure SQL database (or any other kind of database)
Go to the Web App Settings in Azure and scroll down to the section where you have connection strings and input the connection string for your db in Azure
Save and you should be fine.
Related
I have a SQL server in a Windows Server which can be accessed by using both Windows Authentication and SQL Server Authentication. I have a username and password for SQL based authentication. I am using this SQL Server database in an asp.net core application in a linux server. Currently, I am using the username and password of the SQL Server in the connection string (in appSettings.json) to connect to this database. But, I don't want to expose this username and password by putting it in clear text in this json file. Is there any other way of connecting to SQL Server database without using username and password in asp.net core application appSettings.json. I came across certificate based authentication somewhere but couldn't find a way to use it.
I have an ASP.Net web application that runs off of Access databases. I want to convert the application to run off of SQL Server. Will this be a simple process to do? I am thinking that it only involves changing the queries that run on an Access format so they can run on an SQL Server.
Is it that simple or is there be more to it?
Migrate DB to SQL Server with MS SQL Server Migration Assistant for Access
Review migrated DB and verify that tables have been migrated and that column data types have been set properly.
Modify connection string in web.config so that it is now pointing to the SQL Server DB
Review your query code and modify as necessary. The T-SQL used in SQL Server will be different from the JET SQL used in Access. Do a search for Quick-Access-JET-SQL-to-T-SQL-Cheatsheet and you'll find a list of differences.
Microsoft SQL Server Migration Assistant for Access
SQL Server Connection Strings
Is it possible to encrypt a database connection string and deploy it to a Windows Azure Website? (NOT a Windows Azure Web Role) If so, how?
The reason I ask is because I can't find examples or documentation anywhere as to how to perform this specifically with Azure Websites. (I'd like to use the "Shared" web site mode)
I have found the following resources, which come close to what I want, but utilize Web Roles instead of Websites:
http://archive.msdn.microsoft.com/pkcs12protectedconfg
http://blogs.msdn.com/b/windowsazure/archive/2010/09/09/securing-your-connection-string-in-windows-azure-part-3.aspx
The proper way to use connection strings on Azure Websites is to add "debug" connection strings to your web.config file (and by "debug" it can be a local db/storage or any string that is safe to share - empty string).
On the Azure portal go to your Azure website --> CONFIGURE tab and under connection strings sections add your actual connection strings with the same names as used in your web.config file, there the connection string are saved as encrypted strings.
The website code will get the proper connection string you set in the Azure portal.
I am using integrated security in an ASP.net application, the IIS and SQL Server are both hosted on the same server machine running Windows Server 2008 R2.
Is it possible to allow users to access the application from across the network AND logged in users but not let them access the database directly or via SQL Server Management Studio?
I am trying to safeguard the database access because my application is going to be deployed on the client's server at client's premises.
Here is my connection string that i am currently using
<add connectionString="Server=.\sqlexpress;Database=DB89akwA;Integrated Security=true" name="LocalSqlServer" providerName="System.Data.SqlClient" />
<add connectionString="Server=.\sqlexpress;Database=DB89akwA;Integrated Security=true" name="MainAppConnectionString" providerName="System.Data.SqlClient" />
These are the two connection strings i am currently using, one is for ASP.net Authentication and second is used by my application. These both strings are the same and of the same database.
Any suggestions?
It is not possible to 'secure' a database running on client's premises. The client's staff can get the password from the ASP.Net connection string. A domain administrator can always gain access to the database (there is an actual MSDN article describing the process: Connect to SQL Server When System Administrators Are Locked Out).
If you want to hide the Intelectual Property you feel your database has, then your only solution is to not deploy the database on the client premise (use a hosted database like SQL Azure for instance).
If you simply want to prevent the client from interfering with the database you can stipulate so in the contract. Auditing and detecting interference is possible.
Yes, that is completely possible. A Person logged in to ASP.NET using integrated security can not log in to SQL Server with the same credentials. Both are completely disconnected. It is only possible if the SQL Server has been set to allow them access.
My Piece of advice would be to create SQL Login and users, and only give them access to SQL Server. In your application, when you create the Connection String, do not set integrated security to true, and just let the user enter his Sql username and password to access the database.
Working with Azure web role that communicates to a SQL Azure database. Currently when I generate an edmx file for the SQL Azure database the connection strings + the username password are added to web.config file. I did a search and there were several entries on how to encrypt web.config/how to use that to switch between dev and prod but I am thinking of moving conn string out of web.config.
Is there a way by which I can move the connection string to the service definition file? Is that a recommended approach? If I move the connection string elsewhere can I still use the edmx and generated objectcontext classes (cause my existing code uses the automatically generated entity class).
It is best to move your connection strings into service config file. This allows you to switch over to a different SQL Azure database w/o redeployment. Switching to a different SQL Azure database w/o redeployment is useful when one has crashed or is timing out and you have a backup ready on a different server to switch over to.
You will need to initialize your object contexts by providing the connection string separately however.
Use the RoleEnvironment.IsAvailable to find out if you're running under Azure and the following code to read the setting in .cscfg:
var connectionString = RoleEnvironment.GetConfigurationSettingValue("ConnectionString");
I recommend having the connection string in both places, Service Configuration file (.cscfg) and Web.config. Where I also recommend from the beginning to have your web role able to run outside an Azure environment. It will impact your productivity in the long run. Especially with daily development where you do small changes and need to run the project locally to verify. Running your service locally in IIS, IIS express or Cassini (the codename for the Asp.net env) is currently faster than running your project in the local azure emulator (the devFabric).
Regarding your second question about storing the username and password. It all depends on the level of security that you're looking for. The information stored inside your .cscfg are transmitted over https and secured in the Azure cloud the same way your application is secured. That being said, I would store the TEST account credentials in the project for testing and would only put the PRODUCTION storage account credentials in the .cscfg at deployment time to the public/production service.