I have a web app and a web service (which will be uploaded to Azure as an web app). How can i make my web service private (not accessible to the public, only accessible by the web app). Apparently you're able to do it with an App Service Environment but there isn't much documentation on it.
Is it possible?
You can follow this article to set it up: https://azure.microsoft.com/en-us/documentation/articles/app-service-web-how-to-create-an-app-service-environment/
The main difference between App Service and App Service Environment (ASE) is that App Services run on a pre-built, shared tenant hyper scaled web farm, but ASEs are purpose built (on demand) web farms provisioned directly in your subscription that must be attached to a VNET. Because you can attach your ASE to a VNET, you can then apply Network Security Groups (NSG) to the VNET to prevent/allow traffic to flow to the ASE.
Here is the page describing how to add the layered security to your ASE once you've built it:
Layered Security Architecture with App Service Environments
So with ASE you get the deployment/monitoring/management features of App Services, but with the network layer control of a VM.
How can i make my web service private (not accessible to the public, only accessible by the web app).
Network Security Groups could be used to control network traffic rules at the networking level, we could apply Network security group to the subnet to let Network security group act as a firewall in the cloud. #Russell Young has shared us a good article about setting up Network security group, you could read it. And you could check this blog that explained securing network access using Network Security Groups.
Besides, it is easy to implement a custom authentication to prevent unauthenticated client from accessing to your Web service at application layer. For example, we could use SOAP headers for authentication. Web service client credentials would be passed within the SOAP header of the SOAP message when the client want to access to Web service, and then Web service will validate SOAP header, if it contains the authentication credentials, the client will be authorized to access to the Web service.
You could check Implement Custom Authentication Using SOAP Headers.
Related
We have architecture pattern (Layered DMZ) where:
1. External facing applications are deployed in 3 layered DMZ (DMZ1 for Web Server, DMZ2 for App Server and DMZ3 for Database server)
2. We do not allow DMZ1 directly talking to LAN, however DMZ2, DMZ3 can talk to LAN
WSO2 API Manager will be installed in LAN, the issue is how do we expose services from LAN API store to external world. Which design pattern is best suited for this? I have couple of options
Option 1:
Deploy another instance of API Manager in DMZ1 which 3rd party can access
Deploy set of services in DMZ1 API Manager only for 3rd party access
Have reverse proxy in DMZ2 which talks to LAN server
Option2:
Single instance of API Manager deployed in LAN
Reverse proxy in DMZ1
Forward proxy in DMZ2 (which currently we do not have)
Forward proxy talks to LAN
I remember IBM has virtual/physical Datapower appliance which acts as ab external API gateway, how do we achieve similar design pattern with WSO2?
Many thanks in advance
WSO2 API Manager will be installed in LAN, the issue is how do we expose services from LAN API store to external world
WSO2 API Manager has a component API Gateway. Actually todays there are two ways to do that
Use API Gateway
API Gatway is an instance of API Manager with parameters specifying, that the instance is a gateway, so other modules (key manager, store, publisher) are disabled or not used
We use API Gateway in DMZ. This instace will authenticate and authorize the calling clients. However, the gateway still needs to call KeyManager web services for token validation and the publisher needs to call gateway for API deployment
(KeyManager and publisher are the services in the APIM in LAN)
Using API Micro Gateway
Needs to be deployed as individual modules and are able to validate client's tokens (jwt tokens) even without any connection to the LAN instance
Note: When not using static api keys, but OAuth authentication, then you need to expose a route to the token and revoke service
Resources:
https://docs.wso2.com/m/mobile.action#page/97564467
https://apim.docs.wso2.com/en/latest/Learn/APIGateway/overview-of-the-api-gateway/
https://wso2.com/api-management/api-microgateway/
There are several common deployment patterns recommended by WSO2 for API Manager which can be found below.
https://docs.wso2.com/display/AM260/Deployment+Patterns#DeploymentPatterns-WSO2APIManagerdeploymentpatterns
You can go for pattern #4 or #5. Pattern #5 will keep your total cost down in terms of license fee and infrastructure fee.
We currently have a large array of customers (1000 different on-premises installations).
We use a single server to host our sites which communicates with on-premises WebAPI's.
Currently we limit the traffic to the local servers in the router to allow only our server to access the local API's.
However we are considering moving alot of these webservices/sites to Azure which in turn means limiting on the IP's addresses becomes not feasible.
What approach would you recommend to allow the Azure servers to access the on-premises servers?
Best case scenario would of course be that no ports needed to be open in the routers (limit maintenance) however this seems very hard to accomplish if we still would like the ease of development that WebAPI gives us.
Otherwise we have thought about opening for public access to the API's but securing with https and authentication.
Does anyone have any alternative solutions?
Note: The on-premises WebAPI services are hosted with selfhost inside a Windows Service.
You could try using 'Azure Hybrid Connections' to access your on-premises Web API.
You could host your websites as 'Web Apps' in Azure App service and access your Web API.
You do not need to open any firewall ports or change your network perimeter configuration to allow any inbound connectivity into your network
Is there a 'quick and dirty' way of funnelling calls to a web service via a certain IP address? Possibly in code (C#)?
I'm working on this Azure website (PaaS no VM) that's got it's own domain secured by SSL.
e.g. myapp.azurewebsites.net -> https://myapp.com
The system is using a 3rd party web service that uses whitelisted IPs for access control. Unfortunately they are not happy whitelisting the standard Azure egress IPs.
So what I need to do is find a way to call that web service via our own IP address (the one that came with the domain name package).
If possible, only that traffic, not all outgoing.
I've come across several solutions but I’d rather not want to compromise the stability of the production website by experimenting with App Service Environment.
I think the scenario being asked about is outbound calls from an app running on Azure App Service (aka Azure Websites), to an external endpoint.
In that scenario, the outbound calls from the web app are NAT'd using a pool of IP addresses allocated for the App Service scale unit that is running your app.
Using the "preview" portal (portal.azure.com), drill into the website blade for your app and click through "All settings" --> "Properties". In the properties blade that appears, there is a textbox called "OUTBOUND IP ADDRESSES". Those are the values you need to give to the third party provider to whitelist.
Does anyone know whether it is possible to route network traffic from an azure mobile service through a VPN to an on premise web service? None of the documentation I have read precludes that, but neither does it say we can. So far we have had no success though we can access the web service using a web browser VM in the same subscription. We can't run any new software at the site hosting the web service, so it would seem like Service Bus Relay cant be used and the web service can't have a publicly exposed ip address.
have a look at Mobile Services with an Azure Hybrid Connection. The walkthrough talks about exposing an on-premise database, but i think you can use the same steps to expose a different TCP port for your on-premise web service
I wanna to grant access to specific IPs to access the web service which deployed with EAR application on Weblogic.
I know one of the solution for this issue is restricting access to WS URL, by set up security constraints on a web resource collection on webservices.xml file. But I don't know how to do it.
Any help will be appreciated.
Usually it is done on firewall level, rather than application server level.