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.
Related
I've been asked to look into an AWS setup for my organisation but this isn't my area of experience so it's a bit of a challenge. After doing some research, I'm hoping that API Gateway will work for us and I'd really appreciate it if someone could tell me if I'm along the right lines.
The plan is:
We create a VPC with several private subnets. The EC2 instances in the subnets will be hosting browser based applications like Apache Guacamole, Splunk etc.
We attach to the VPC an API Gateway with a REST API which will allow users access to only the applications on 'their' subnet
Users follow a link to the API Gateway from an external API which will provide Oauth2 credentials.
The API Gateway REST API verifies their credentials and serves them with a page with links to the private IP addresses for the services in 'their' subnet only. They can then click on the links and open the Splunk, Guacamole browser pages etc.
I've also looked at Client VPN as a possible solution but my organisation wants users to be able to connect directly to the individual subnets from an existing API without having to download any other tools (this is due to differing levels of expertise of users and the need to work remotely). If there is a better solution which would provide the same workflow then I'd be happy to implement that instead.
Thanks for any help
This sounds like it could work in theory. My main concern would be if Apache Guacomole, or any of the other services you are trying to expose, requires long lived HTTP connections. API Gateway has a hard requirement that all requests must take no longer than 29 seconds.
I would suggest also looking into exposing these services via a public Application Load Balancer, instead of API Gateway, which has OIDC authentication support. You'll need to look at the requirements of the specific services you are trying to expose to evaluate if API Gateway or ALB would be a better fit.
I would personally go about this by configuring each of these environments using an Infrastructure as Code, in such a way that you can create a new client environment by simply running your IaC tool with a few parameters like the client ID and the domain name or subdomain you want to use. I would actually spin each up in their own VPC since it sounds like you want each client's environment to be isolated from the others.
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.
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.
Im new to working with web services, but if I create a web service in visual studio then deploy it, can't anyone who finds the link just add a service reference to it and use it?
Yes.
That's why you should secure web services that should not be available to the public. Many web services use an API key and/or password to secure access. You can also restrict access to specific IP addresses, depending on your situation.
We have developed a RESTful Web Service which requires access to a Network share in order to read and write files. This is a public facing Web Service (running over SSL) which requires staff to log on using an assigned user name and password.
This web service will be running in a DMZ. It doesn't seem "right" to access a Network Share from a DMZ. I would venture a guess that the "secure" way to do this would be to provide another service inside the domain which only talks to our Web Service. That way, if anyone wanted to exploit it, they would have to find a way to do it via the Web Service, not through known system API's.
Is my solution "correct"? Is there a better way?
Notes:
the Web Service does not run under IIS.
the Web Service currently runs under an account with access to the Network Share and access to a SQL database.
the Web Service is intended only for designated staff, not the public.
I'm a developer, not an IT professional.
What about some kind of vpn to use the internal ressources? There are some pretty solutions for this, and opening network shares to the internet seems too big a risk to do.
That aside, when an attacker breaks into your DMZ host using those webservices, he can break into your internal server using the same API unless you can afford to create two complete different solutions.
When accessing the fileservers from the DMZ directly, you would limit theses connections using a firewall so even after breaking your DMZ Host the attacker cannot do "everything" but only read (write?) to those servers.
I would suggest #2