I'm trying to share authentication cookies across a .NET Core app and an MVC 5 application. This is possible according to: https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/compatibility/cookie-sharing but requires the servers to have physical access to a shared directory that holds the Data Protection keys.
How does one go about sharing these keys if the servers are not physically located together? In my case they're different Azure Web Sites.
Related
We have developed ASP.NET Application using SQL Server Database & hosted in our Company Intranet Server. The Application using Forms Authentication which checks user in the Active Directory. We have not concentrated much on Security checks due to its in Intranet. Now our question is what are the possible security risk we need to concentrate on our Application If we host in Amazon Server. Also Can we get separate Account like VPN to access our Application in the Amazon Server?
Yes, you have to concentrate on security as the AWS are for internet. Check if you can encrypt the data. Also, it differs from organization perspective. Check with your IT department first.
I am going through how ASP.NET page is processed when the request is send from browser to Server. From many sources i came to know that during asp.net request processing Application Manager instance is created and the Application manager creates the application domain . The Application domain provides isolation layer with in the process. My Question here is for the same application if there are many requests coming up , will all the requests will be processed by same App Domain or it will create many App Domains for each request. How to calculate how much memory the Application Domain is using. Will the App Domains share the dlls if many App Domains are using the same references like (system.web, system)
I have a ASP.NET application with Forms authentication. I also have a subfolder setup as a separate application (not virtual directory), using the same application pool and using the same web.config authentication settings.
For some reason I don't understand, these two applications do not share the same authentication. For instance, FormsAuthentication.SetAuthCookie seems to work independently, and User.Identity.Name returns different values in the two applications.
My question is, how can they share the same authentication? I want to login into one app, and appear under the same identity on the other. I can see the .ASPAUTH cookie has the same value (obviously, since they are under the same domain). But how would single sign-on work?
Thanks
Themos
Even though the Applications are in the same AppPool, the machine keys are different for the two. Typically, the authentication cookie is encrypted with the machine key.
The default behavior for machine key's is to use IsolateApps, which generates a different machine key per IIS site application, not application pool.
Since you have two different machine keys, they cannot decrypt the authentication cookie between applications. You need to add a static machine key (that is the same) for both applications.
You can use sites like this one to generate your own machine key.
Additionally the MSDN article, Forms Authentication Across Applications also specifies the settings that need to match between the two applications.
I am using an application variables to store the values and again access it.but my Question here as we using multiple servers (web farms). will be there any issue whiling access the values or it not worth to store values in application state variables when we are going ahead with multiple server
Thanks
prince
No, Application State is not shared across the servers in a web farm, as per the documentation (see the section entitled Scalability).
Application state is not shared among multiple servers serving the
same application, as in a Web farm, or among multiple worker processes
serving the same application on the same server, as in a Web garden.
Your application therefore cannot rely on application state containing
the same data for application state across different servers or
processes.
You will need to find some other store for this shared information, i.e. via a database or shared cache.
However, you will be able to share viewstate and forms authenticate tickets across all servers in the web farm, but you must set the <machineKey> to the same values on all servers.
From the first article below:
If you deploy your application in a Web farm, you must ensure that the
configuration files on each server share the same value for
validationKey and decryptionKey, which are used for hashing and
decryption respectively. This is required because you cannot guarantee
which server will handle successive requests.
These MSDN articles have more information:
http://msdn.microsoft.com/en-us/library/ff649308.aspx#paght000007_webfarmdeploymentconsiderations
http://msdn.microsoft.com/en-us/library/eb0zx8fc.aspx
I am getting my head around n-tier applications. I understand seperation of code layers eg/UI, BL (Business Logic), DL(Data Layer).
In a ASP.Net application you would just reference the C# project that is doing the BL and the DL and all is well.
What I don't understand is how you would implement this on seperate servers? Do you have the DLL for the BL and DL in the bin folder but a setting in the web.config file which tells it where to go for communication or do you have the actual BL and DL running on a seperate server and then communication from the UI is made via a web service?
At the moment I have a standard ASP.Net webforms app that needs to seperate the security side to the web server and the main app on a application server, however I dont think thats possible.
When we spit in to physical Tiers we use WCF between the tiers. You actualy end up getting many more layers in your application, so do not use it if you do not need it.
Typical layers would by
Client Tier
UI
Business
proxy
Server Tier
Facade
Business
Data access
Server Tier can be implemented as a single Layer if you use an ORM.
This isn't directly possible without clustering, and even that requires exact copies of the application running on both servers.
If you want to run your security layer as a separate server, create it using web services, and make a web request to that service, and return the (encrypted or otherwise) response.
Hope that helps.
EDIT for continued Explanation:
In your case, I would have my security application running on a server that will authenticate, encrypt, and respond to requests made to it from a specific url or domain/sub-domain. Then my main application can live on another server and the requests to authenticate etc can be on a secondary server. However, ASP.NET authentication uses the machine-level key to create a unique salt for the authentication token. So in order to share auth tokens between multiple machines, your machine keys must be identical in the machine.config.
Separate servers would entail the usage of some form of web services. Here at work:
Server (piglet) - database, sql server 2005, firewall prevents connections to tigger
Server (eeyore) - web services - connects to piglet
Server (tigger) - asp.net server - connects to eeyore, firewall prevents connections to piglet
The business logic would be in a dll assembly used by the data access layer, the presentation layer, or both, and is deployed alongside them.
If you want the layers on physically separate servers, then you have to decide how the layers should communicate. You have lots of options for doing this: web services, Windows Communication Foundation, .Net Remoting...
Application Server - Instead of calling the security logic directly, call a security webservice on the web server.
Web Server - Hosts the security webservice. The webservice here does the actual business logic and can call the data layer.