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.
Related
We are planning to use EXTJS framework for presentation layer which would be calling WCF based Rest Service or WebAPI Service(Http services) . My requirement is to have 3 tier architecture (physical separation) so my understanding is that we need to put Service layer on another server and host services on IIS there to be consumed by presentation layer hosted on different IIS server.
I am getting few doubts regarding this architecture.
Should we use Webform approach to host EXTS libraries as in this case ASP.Net MVC would be irrelevant considering that all the rendering logic is done by EXTJS.
If we host services on another server which service authentication should be used .In this case I think we can’t use Form Authentication as the web and service are hosted separately.
Is it really required to host Service layer on another server to make it three tier ,considering the third tier is the Database server. Isn’t browser a tier considering EXTJS library directly renders on the browser.
Since no body answered i will try to answer myself based on my research and response i got from another forum.
We can use MVC approach as well, the Controller method can be used to return JSON result for the EXTJS API to consume. But the downside is with this approach we cannot use strongly typed model in views along with other features like use of Html helper and automatic validation based on the models.
With this approach we can still use MVC routing or can go entirely with a Single View and ExtJs Routing.
Place the services your Ext.js needs on the web tier, where your Webforms/MVC application also runs. Separate your business logic/data logic via other services on another server if needed (second tier). Don't call these directly from your Ext.js. Keep presentation in the first/Web tier.We can use Form Authentication to call service in web-tier and Windows authentication to call the service from Webtier to second tier.
From the server side perspective a browser's not really considered a tier.However with modern approaches it's debatable.
I am trying to migrate an application A to a Weblogic 10.3.6 Application server running on Oracle Enterprise Linux Operating System. An application B is already residing in that weblogic server. Application A has a GUI with user login feature. However, application B does not. Currently application A and B are interfacing through an MQ.
My queries are:
1. Is it a feasible design to have both applications A & B ears in the same server?
2. If yes, how can they internally communicate?
3. Is there a security breach risk for application B due to user login feature of application A?
1) Yes, it is perfectly reasonable to run one or more Ear files on a server. There can be performance issues, and you may need to watch the JVM/Heap memory carefully (one app causing OutOfMemoryError will take down both).
2) Depends how you want them to communicate. The easiest way is probably to use remote lookup. WebLogic provides all lookups for application context etc in a JNDI tree. As long as the methods are exposed to allow remote calls (e.g. #Stateless #Remote annotations in JEE), you can call methods remotely. You can also use other methods such as MDB (message driven beans) if you don't want fast communication, or even Web Services (just bind to the same local server with a different Context root).
3) It depends how you login. If you use weblogic state to check if someone is logged in, then logging in to one application will log you into the other. You would need to look at WebLogic Roles and Policies. Basically set certain users into one Role for one application, and possibly have two different authentication mechanisms setup. Then use #RolesAllowed (or any other ways you fancy) to block access to classes/methods to only the given roles.
If you use your own log in method, I can't see an issue from the user side. Just be careful of what code gets used, and make sure you dont allow remote lookups you arent aware of (ie watch out for methods that could be subject to injection attacks, where malicious code could do a remote lookup to the other application). If you wanted you could still use WebLogic Roles and Policies to block this off anyway.
I have an application which is structured as:
Web Application - WCF Service - Database
All communicate to and from the database goes through the WCF Service, the Web Application is not able to directly talk to the database. I needed to protect the data as it travels across, so i setup SSL on my local machine to test and configured it in IIS, so now the WCF Service has to be hit using HTTPS. However, I did not setup my Web Application to use HTTPS, is that ok? I thought since the WCF Service is doing all the transferring of data, it's the only one that needs HTTPS.
Thanks.
If you're interested in encrypting your data, you need to make sure it's passed encrypted on all tiers of your application. From your description it seems that the data passed from the user to the WebApplication itself is unencrypted and therefor passed in clear text. This means that anyone that "listens" to the traffic between your users and the Web Application can intercept the data.
I recommend adding SSL on the Web Application too, to make sure that your data passes encrypted through all 3 tiers of your application.
I have a web based application that uses lot of client side requests in various .asmx files.
I am wondering if I can use those web services only from client side and restrict the requests from other sources.
The reason for this is because I want to use those web services only from the current application and to restrict requests from other sources. For security reasons I could use soap authentication but since I requested the services from client side, I don't think the authentication it matters.
I'll appreciate any comments.
Thanks
The webservices are by definition public, publicly visible and available (unless they run on private network or standalone computer). I.e. anybody can access them. So, just deploying a webservice and hoping for the best is not a good approach.
And how do you intend to restrict other access?
I have a public desktop site, a public mobile site, and a private intranet site on the same server. They are all written in C# (ASP.Net 4.0).
Each has their own code to process credit card payments. I would like to write a single application that handles credit card payments for all 3 sites. I want this application to only be accessible from these 3 local applications.
The only way I know how to do this is to create a web service and restrict traffic to the localhost.
Is there a better ("right") way to do this? Should I create a windows service instead?
The general approach is sound. However, I would not only rely on access being restricted to localhost. A single misconfiguration at some later point in time would expose your payment web service. Also, if the server is compromised, any process running on that local host would have unchecked access.
Always use authentication to secure your payment web service.
If you must deploy the authentication service on the same physical box as the front end websites, take particular care securing the payment service (e.g. if you are storing credit card numbers or PII related to the credit accounts e.g. name, address, ... ensure the database is correctly secured). If at all possible, place payment services in an additional layer separate from the public-facing (or co-worker facing) websites, protected by appropriate firewall rules.
I don't think windows service would be good option if you have calling applications. As far as I know about WCF, we have option for NetTcpBinding and NetNamedPipeBinding which you might consider.
NetTcpBinding - A secure and optimized binding suitable for cross-machine communication between WCF applications.
NetNamedPipeBinding - A secure, reliable, optimized binding that is suitable for on-machine communication between WCF applications.