I am working on an asp.net mvc-5 web application. and i am calling a 3rd party API from my server side using security token generated by the 3rd party application.
now i am passing the token in a secure manner as follow:-
i am adding the token to the http header.
and we are using https to communicate with the 3rd party system.
so i think the token can not be hacked during its transmission. but the problem i am facing is how i can store and read the token itself. currently i am storing this inside our web.config section:-
<appSettings>
.....
.....
<add key="SecureToken" value="12345" />
.....
.....
</appSettings>
and i am retrieving the value inside my application as follow:-
string Token = System.Web.Configuration.WebConfigurationManager.AppSettings["SecureToken"]
so the security problem i am facing is that if someone access the live server he can read the web.config file and get the secure token. so i read that i can encrypt part of the web.config sections using aspnet_iisreg command. but now i am not sure how i can force this to work across my environments? i mean where i need to run the aspnet_iisreg inside one environemnt let say the Dev ? or i need to run this command on the three environments seperately?
It should run through a deployment script, it can be a msi or powershell or something else. If you deploy manually, it requires aspnet_regiis -pe "yourappsettings" -app ... which is also a manual job and error prone. So develop a package with all your pages, dlls, .js, images etc. and install that package (msi or powershell or something else) and install that to your server. In that package include a script which does aspnet_regiis command and this command should run after virtual directory creation, mainly it should be kinds of last action. If you are using powershell, it's a set of instructions - so one instruction should be aspnet_regiis command. Try with post build event for VS web deployment package.
Related
I am new to web development. We are having a legacy intranet web application using ASP.NET web forms.
We have encrypted web.config using ASPNET_REGIIS tool for the connection strings, based on security feedback. I am able to test it locally using IISExpress.
What are the steps to follow to update the old web.config with new web.config, in an environment.
We need to update web.config in multiple environments(DEV,TEST, UAT) before refreshing in production.
We will be announcing downtime for the same. Please list down the steps like resetting IIS etc.
Since the key used for encrypt/decrypt is different on different server. You can decrypt the connection string section before publishing. Then just override the web.config on your target server, then encrypt the connection string with asp_regiis tool again. You can find aspnet_regiis under the root folder of .NET framework.
Of course, there is a way to sync up RSA container for mutiple servers.
https://learn.microsoft.com/en-us/previous-versions/aspnet/yxw286t2(v=vs.100)
After that, please don't forget to grant permission for machinekey file in \Microsoft\Crypto\RSA\MachineKeys.
Finally you just have to recyle the application pool.
I had to do below steps:
First and Foremost: Took a backup of existing web.config, so that, if something goes wrong, I can fallback to original web.config
As web.config encryption is machine specific, I encrypted the web.config using ASPNET_REGIIS tool, as mentioned in the codeproject Link
Web.config changes are automatically picked by IIS. I did not have to restart IIS or recycle APPPool. The site was working fine with the new web.config changes, I made.
I've been trying to get our web app auto-deployed using TFS/MSBuild with WMSVC. The problem is that I can't use a build script that exposes a password. I'm hoping that I can take the identity that the build server is using to authenticate with WMSVC on my IIS 7.5 machine and get the app deployed with all the web.config goodness that has been promised.
There is another post here that offers work-arounds and states that WMSVC defaults to BASIC auth and to encrypt the password. This isn't something we want to do. Our requirements are to do a deploy without embedding user/pwd into the build scripts.
We want to be able to use NTLM via delegation or adding the build server to the administrator group on the IIS machine.
Is this totally impossible? There is no way to do this without a username and password specified in the build script? I just want the credentials I have already assigned on the IIS side for my build server to work. Any idea if this is just simply wishful thinking?
I believe you are looking for the -authType NTLM flag in the msdeploy command line described here
msdeploy -verb:sync -source:webServer,wmsvc=Server1,authtype=NTLM
I have a web application and I am trying to deploy it on a webserver using MSDeploy.exe (Web Deploy 2)
I have tried 4 scenarios:
Through VS2010 Publish method with following settings:
Publish Method: Web Deploy
Service Url: https://MyServerName:8172/MsDeploy.axd
Site/application: MyWebSiteName
Allow untrusted: checked
Username: MyUsername
Password: MyPassword
This method works just fine.
On MyServerName machine I have Web Management Service running; I have a website MyWebSiteName, an application MyWebAppName and MyUserName is an IIS Manager for it.
Through VS2010 Publish method with following settings:
Publish Method: Web Deploy
Service Url: https://MyServerName:8172/MsDeploy.axd
Site/application: MyWebSiteName/MyWebAppName
Allow untrusted: checked
Username: MyUsername
Password: MyPassword
This method works just fine.
Through MSDeploy.exe command line (within a Powershell script)
$Source = "contentPath='...._PublishedWebsites\MyWebApp'"
$Destination = "contentPath=MyWebSiteName,computerName='https://fc-wapps-trial:8172/MsDeploy.axd?Site=WebSiteTest',Username=MyUsername,Password=MyPassword,AuthType=basic"
MSDeploy -verb:sync -source:$Source -dest:$Destination -allowUntrusted
This method also works fine.
Through MSDeploy.exe command line (within a Powershell script)
$Source = "contentPath='...._PublishedWebsites\MyWebApp'"
$Destination = "iisApp=MyWebSiteName/MyWebAppName,computerName='https://fc-wapps-trial:8172/MsDeploy.axd?Site=WebSiteTest/MyWebAppName',Username=MyUsername,Password=MyPassword,AuthType=basic"
MSDeploy -verb:sync -source:$Source -dest:$Destination -allowUntrusted
This method doesn't work. I am getting the following error.
Error Code: ERROR_USER_UNAUTHORIZED
More Information: Connected to the destination computer ("MyServerName") using the Web Management Service, but could not authorize. Make sure that you are using the correct user name and password, that the site you are connecting to exists, and that the credentials represent a user who has permissions to access the site.
Error: The remote server returned an error: (401) Unauthorized.
I was looking at what is the actuall MSDeploy command that the method 2 uses and I got something like:
msdeploy.exe
-source:manifest='...\MyWebApp.SourceManifest.xml'
-dest:auto,ComputerName='https://MyServerName:8172/MsDeploy.axd?site=WebSiteTest',UserName='MyUsername',Password='MyPassword',IncludeAcls='False',AuthType='Basic'
-verb:sync
-disableLink:AppPoolExtension
-disableLink:ContentExtension
-disableLink:CertificateExtension
-skip:objectname='dirPath',absolutepath='...\App_Data$'
-setParam:kind='ProviderPath',scope='IisApp',match='^...\PackageTmp$',value=WebSiteTest/WebAppTest
-setParam:kind='ProviderPath',scope='setAcl',match='^..\PackageTmp$',value=WebSiteTest/WebAppTest
-allowUntrusted
-retryAttempts=2
Now this doesn't seem to be anything close to what I am using in method 4. I tried running it myself without success, but I assume I wasn't able to properly re-create all those parameters.
So my questions are:
- What I am doing wrong in method 4?
- How can I deploy a web application as a website application in IIS7 using MSDeploy.exe command
Thanks in advance for your help
Iulian
I ran into the same issue as you did. I solved it by only use site name in
https://computername:8172/msdeploy.axd?site={websitenameonly}. Then set your webapplication path in the parameter using -setParam IIS Web Application Name= {your web application name here} or use a parameter file. And everything deployed fine.
It seems that the site querystring value is required to authorize the request only. I haven't find any definitive documentation from MS on any other querystring parameters that might solve this. But I actually tested 2 cases. 1) Deploying to a web site in IIS 7.5, this parameter is required. 2) Deploying to a web application under a web site, this parameter is actually optional, but if you want to include it, then it has to be a root site.
You actually answered your own question here just probably didn't realize it.
Please check your Management Service Delegation (if you haven't already). Click on the main site in IIS Manager to bring up all Web Deploy options in the center panel. At the bottom (past ASP.NET, IIS, etc), under Management, you should see several options, including "Management Service Delegation".
Under this configuration is all the Provider contexts you might run into and the paths/types you might use them against (and under what usernames, etc... can get pretty granular).
Make very sure that the provider type you're trying to communicate under (iisApp, contentPath, etc) is not only listed, but has the path/scope you require and that you're operating under permissions that have been cleared.
Remember: you don't have to use an administrator-type user if delegation is set up correctly. AND you've gone to the applicable site's IIS Manager Permissions and added an Allowed User, like Domain\User, or even a custom IIS Manager User.
I just inherited a very old ASP.NET 2.0 web application.
In the application it has SEVERAL support class library projects. In the DataAccess class library, is an app.config (and setting.settings file) with a connection string named ConnString1.
I always thought that a .DLL couldn't have a app.config/setting.settings file (or at least you can include them but they won't be used), so this is what is confusing to me.
The web.config also has a connection string named ConnString1 with the same server login credentials, but a different server name.
When I run the application from Visual Studio DEBUG, it uses the connection string that is located in the app.config/settings file, and not the one defined in the web.config/machine.config.
I thought .DLLs wouldn't do this, but use the web.config instead?
However, when I pushed this application in RELEASE mode to our production server (in test website), it seems to be using the correct connection string in the web.config.
Can anyone explain this?
There's got to be something that is confusing you to think that the config file that's a part of that DLL is being used - as opposed to the applications (entry point's) config file (yourapp.exe.config or web.config). Maybe that conn string is hard-coded somewhere for the use in debug mode, e.g. by using conditional compilation via "#if DEBUG" preprocessor directive (so, maybe search for "#if DEBUG" across your solution to see if this particular thing is happening).
MSDN article about app settings
See the yellow "Note" in the section "Creating Application Settings at Design Time": "Because there is no configuration file model for class libraries, application settings do not apply for Class Library projects."
I found the issue:
In the above example, I am using the web.config/machine.config to set the connection string for the application.
If the connection string isn't defined in the web.config, it defaults to the machine.config. If the connection string isn't defined in the machine.config, it will use the app.config setting found in the .dll.
It's important to note, that placing the connection string in the machine.config, it must be defined in the correct Framework/CONFIG.
On my development machine, the connection string wasn't defined in the web.config but in the environment.config, but in the Framework64/CONFIG -- however, the application is compiled in 32-bit, thus, the reason for using Framework/CONFIG that did not have the connection string defined in it and causing it to default to the app.config in the class library.
I hope that explains that?
All config settings must be specified in the executable config file. For windows and console apps it's app.config, for web projects it's web.config.
Libraries can specify config settings, but you have to copy the settings to the executable's config file in order for the application to be able to read them.
Difference between Web.config, AppSettings.json and App.config
Web.config:
Web.config is needed when you want to host your application on IIS. Web.config is a mandatory config file for IIS to configure how it will behave as a reverse proxy in front of Kestrel. You have to maintain a web.config if you want to host it on IIS.
AppSetting.json:
For everything else that does not concern IIS, you use AppSetting.json.
AppSetting.json is used for Asp.Net Core hosting. ASP.NET Core uses the "ASPNETCORE_ENVIRONMENT" environment variable to determine the current environment. By default, if you run your application without setting this value, it will automatically default to the Production environment and uses "AppSetting.production.json" file. When you debug via Visual Studio it sets the environment to Development so it uses "AppSetting.json". See this website to understand how to set the hosting environment variable on Windows.
App.config:
App.config is another configuration file used by .NET which is mainly used for Windows Forms, Windows Services, Console Apps and WPF applications. When you start your Asp.Net Core hosting via console application app.config is also used.
Summary
The choice of the configuration file is determined by the hosting environment you choose for the service. If you are using IIS to host your service, use a Web.config file. If you are using any other hosting environment, use an App.config file.
See Configuring Services Using Configuration Files documentation
and also check out Configuration in ASP.NET Core.
I have an MVC2 .NET 4.0 app, hosted on TFS 2008 (soon to be TFS 2010) that uses connection strings in web.config to connect to a database on another server. I need to encrypt these connection strings.
As I understand it, I can use aspnet_regiis.exe to encrypt the connectionstring portion of the web.config file, but I have to do it on the deployment machine because the encryption uses the machine name to generate the encryption key.
Now, it seems to me that this represents a problem - every time I deploy my code to the dev server won't it overwrite the web.config file, and need to be re-encrypted? This sort of manual process seems kludgy.
Is my understanding about needing to re-encrypt after deployment correct?
If so, is there some way to automate this process? I don't want to forget this or get a new team member who doesn't know the process and have the connectionstring exposed to the world.
web.config files aren't typically part of a deployment (though Visual Studio 2010 supports configuration file transforms in web application deployment projects). I wouldn't expect that you should be overwriting the web.config when you deploy (because the web.config is where you would place those things that are specific to that machine/environment.
So, encrypt it once, and then don't overwrite it, would be my advice.
Since that isn't available in your situation, it is possible to specify a key when encrypting, so that you can share the encrypted file between machines. By default, the command to encrypt uses the DPAPI to encrypt the section (which is tied to the machine) but you can also use RSA for encryption. More info is available on MSDN in Specifying a Protected Configuration Provider.