We're looking into writing a mobile app for our company and have a concern as to the infrastructure of how the application will connect with our data.
Our current structure for our web applications is as follows:
We have an App server which holds our .NET sites, this is externally facing (obviously)
These .NET sites interact with our API server (which is only accessible by anything on our App server) So this is only internally accessible
A mobile app will not be on our servers, but it will still need to be able to access our API's. What would be the best course of action to be able to still maintain a level of securing our data in our API's while being able to have them externally accessible by a mobile app or any other app that would need data from it?
My initial thoughts would be some sort of API key system, or perhaps API users?
Thanks!
You should encrypt your API with ssl. You can also use an API management solution. There are some open source options such as: http://wso2.com/products/api-manager/ and API Agility https://apigility.org/
Related
Hello Everyone!
As you can see in the image, that's essentially the architecture I'm planning but I'm having some doubts.
I need to create a publicly accessible API layer which also needs to access an On-Premise SQL database via Express Route. Express Route connection has already been established.
After doing a some digging, I found that in order to make the Web API access the on-premise database I need to integrate the App Service which is hosting the Web API using VNet integration with the virtual network connected with Express Route. However, I have a couple of questions.
Is VNet integration enough to establish a successful TCP 1433 communication between Web API and on-premise DB? If not please let me know what other services I should configure?
Will I lose public access to the web API? If so what would be the best way to make the Web API public?
Appreciate any help and thank you for taking the time!
You can use VNet integration, but you might also want to look at simply setting firewall restrictions on your DB. You can open up access to the DB for the IP ranges of your Azure App Service. Depending on the App Service Plan you're on, there is a list of 10 - 15 outbound IPs which you might want to whitelist. This gives your API access to the database while the database is still being protected from being public access.
If you want to make your API publicly accessible (at least on some routes) you need to open up your API to everyone. I think the best way to go would be to set up authorization for the routes you want to protect. For example with token/bearer authentication. This way, you make your API accessible, but you require authentication for some routes. You can handle the authentication in your Angular JS app, with something like Auth0 or other OpenID providers.
When I have an ASP.NET web app with some API controllers that has a route /api for example, I can publish the app to Azure Web App and use the api by accessing someproject.azurewebsites.net/api/controller.
However, when I separate a web API part from the web app project, I have to publish the web API project to new domain like someapiproject.azurewebsites.net. I want to integrate the web API project to the web app just as I did with one combined project.
Is this possible?
If you want to combine multiple APIs, you should take a look at Azure API Management.
I doubt that you can publish multiple APIs into a single Web API since both requires a startup where you configure the host.
What you can do to cleanup your code is to outsource the controller into different assemblies and configure them in the middleware. Here is an example.
Martin Brandl's answer is spot on. But if you want to go the poor man's route, you can create a reverse proxy from your ASP.NET Web App and map app traffic from someproject.azurewebsites.net/apiV2 to someapiproject.azurewebsites.net. This is not a HTTP 30x redirect - the URL will not change for users hitting your /apiV2. I've personally used this approach because the Azure API Management service can get a little pricey. If you don't need the sexy features like throttling, this can be a good way to go.
I am in the process of building a Web based client for a Server application which is running as a Windows Service. The server application currently has a Windows Form based Client Application written in C# and the idea is to obsolete it and provide a new Web based Client Application. The Server application will be exposing REST based APIs and the Client Application would be using the REST APIs to communicate with the Server Application. (Currently the Server App exposes SOAP based endpoints which are consumed by the Windows Form Based App)
The Browser based client application would be written using Angular JS. The Client Application would be used by at max 10 concurrent users. The App is targeted for system administrators and would be used inside the enterprise environment.
Another requirement is to integrate Active Directory Authentication for the Client Application. So given the performance requirement and authentication requirements, I am wondering whether I should use IIS for hosting the Web Application. Or should I just use the existing Server to self host the web pages.
If at all I go with Self Hosting option, would Katana Self host be a good option? Or should i use WCF Rest kit to serve the pages?
What are the performance implications of using a Self Hosted mechanism for hosing the Web Application compared to IIS?
Any suggestion would be greatly appreciated.
WCF REST Starter kit is still in second preview 2 version from 2009 so I'd be pushed to recommend using it.
The question of IIS or self host depends, do you need the features that IIS has out of the box like logging, restart after failure, etc?
My suggestion would be to use ASP.NET Web API (or Nancy, which is an excellent choice too) but keep your hosting layer separate from your application layer so you have the flexibility to decide how you host your service later on.
The second suggestion is performance test early on, pick a hosting mechanism and measure how the service copes under load - you may find out that you're worrying about something that you don't need to.
I have a rest service that I need to use in a browser web application using a JS MVC client framework like Backbone or Angular. But I need to ensure that my rest services are not exposed or anyone else may not be able to use my rest service to build apps on any device/client. Earlier I thought of protecting my web service using authentication credentials and hiding it behind a proxy and let the proxy serve html instead of service.
But I would like to know how can I secure my web service if I have to use it directly from front-end using ajax calls.
I'm fooling around with a WebAPI application I've developed in two solutions: one solution is the WebAPI / serverside solution with db access using SQL server, the other is a durandalJS client application. I have the WebAPI bits hosted in an Azure Website right now, but I'm not sure where to put the client solution.
Should I throw it in its own website and just have it make requests within azure across to the other website? I want to avoid putting them in the same solution because I would eventually like to practice load balancing the front-ends when I have more dough to play with.
Idea of cloud like Azure is pay as you go. If you do not have the volume currently to load-balance, why create two websites and pay for them both regardless of the usage? You can have just one web site and host both the web application and web API. In the future, if you want to separate out API piece and load balance web app, you can do that when you have the volume. For this approach to work, structure the solution like this. The Web API piece will be just an assembly which you can reference in the Web application itself and host it in the same web site as the web application. In future, if you want to separate out, create a new empty ASP.NET Web application and host the Web API referencing your Web API core assembly.