Use Case :: Trying to mock a destination that would help us connect to a cloud S4 system behind an IDP and requires Oauth2 authentication.
I have been able to mock a local destination to connect to system behind basic authentication.
We are trying to understand how to mock the additional components susch as XSUAA service that would require us to generate the token
We want to use this destination to enable us to connect to remote systems locally without modifying the code developed for the cloud enviornment.
To basically recap the discussion in the comments:
It is not easily possible to consume Cloud Foundry services locally. The SDK reads many of the necessary configuration and credentials from the VCAP_SERVICES to communicate with those services. The only option, which is not recommended, is to copy this down locally. However, this poses security risks, as the environment variable contains sensitive information.
If the only reason is easier debugging of your application you could have a look at this answer to see how remote debugging can be set up.
Related
I am developing a small demo API for my organization. I use Azure AD for authentication for the API (and the OpenAPI docs). Everything works perfectly in my local development environment and I don't have the hassle of SSL since the oauth2-redirect is localhost. I am now ready to make my demo accesible inside my organization's network. However, Azure App Registration mandates that a oauth2-redirect link has to be https (or localhost which is why it works perfectly for me). I can understand why, but I am eager to demo my API and so, if at all possible, I would like to avoid the hassle of setting up a reverse-proxy, configuring TLS etc. So my question is - if I use https://10.x.x.x.nip.io/oauth2-redirect what are the security implications of this? I fear they are major unfortunately. I guess nip.io could sniff my authorization if they wanted to?
This is not strictly an answer, since it doesn't discuss the security implications of nip.io. However, if TLS is an issue for a demo it is automatically configured for an Azure App Service. For small demos it is therefore very convenient to deploy as an Azure App Service especially if you protect it behind a private link.
It is well documented that Google Apps Script run on Google App Engine servers that would not have access to a company's internal network/server:
https://developers.google.com/apps-script/reference/url-fetch/url-fetch-app
https://cloud.google.com/appengine/kb/#static-ip
https://developers.google.com/apps-script/guides/jdbc#using_jdbcgetconnectionurl
Per the documentation, if you want a Google Apps Script project to have access to an internal network/server then you will have to white-list Google's IPs. But we all know that isn't the safest option. In fact, the documentation even says so:
Note that using static IP address filtering is not considered a safe and effective means of protection. For example, an attacker could set up a malicious App Engine app which could share the same IP address range as your application. Instead, we suggest that you take a defense in depth approach using OAuth and Certs.
The issue is I cannot find any documentation, reference material, or articles on how best an organization should do what it suggests.
So my question is, how can an organization using G-Suite Enterprise securely allow Google Apps Script projects to access the company's internal network?
The documentation made it quite clear, that since App Scripts are ran on shared App Engine instances, it is impossible to restrict with IP, and that also implies the networking capability would be very limited (i.e. no VPC peering or alike). Therefore, as in the highlighted block, they suggest implementing authentication over just IP restriction.
Apart from authentication, App Script also supports encrypting and authenticating the server with SSL (sample code). This should protect the connection from being eavesdropped when sent over the Internet.
Further more, you can implement a "semi IP restriction" mechanism, technically called Port Knocking, which briefly works as follow:
First create a special endpoint, requires authentication, accepts an IP address as input. When requested, you open up your firewall to accept connection from that IP to your internal network for a limited time (e.g. 5min).
In your App Script, use URL Fetch to request that endpoint, so that your scripts instance is temporarily allowed to access your network.
Of course that will not be perfect, since one App Engine instance runs many scripts concurrently and the whitelist is opened for a set time, but still this is considerably better than persistently opening the port to all Google (App Engine) IPs.
Apps Script is a great tool for simplifying tasks when you are using G Suite services, unfortunately, what you are trying to achieve is not available. Also, keep in mind Apps Script is not built on App Engine, it's a completely different product.
Therefore if what it is shown in the documentation can't fulfill the requirements you have, please check other Google alternatives like App Engine or Google Cloud Platform, instead of G Suite.
I have developed an application which is hosted on an iPaas provider. This application has to make a REST API call to a service which is running inside an AWS EC2 instance.
Please note that the application is not pushed to AWS. In order to do so, I've to provide access to the cloud provider so that the REST call can be made successfully to the API residing in AWS. That means, in order to make a successful REST call, my application (hosted on some cloud) has to get permission from AWS (where a service is hosted and to which the application is making REST request). But AWS doesn't provide the option to enter the URL. How can we make this possible?
You should look up the documentation of your Cloud Provider.
They for sure must have provided you with the public IP of the machine made available to you.
Another way of solving your problem could be by using the ping command. If you trying to ping the URL of your cloud provider, it will show you the IP address.
But here one issue you may encounter is, depending on your cloud providers size there could be more than one machines which may be providing the service
and it may happen that the IP provided by ping command and the IP of the machine where your app is pushed may be different and your purpose may not be fulfilled.
Here you may try to use the network masks (which you use while providing the access to any IP in AWS security groups)
Try providing access to a supernet.
Or you can also explore the usage of some standard tools like "tracert", "traceroute", "nslookup"
At the firm I am working currently, we have a lot of microservices, currently, most of them are deployed to Azure. In Azure, service to service authentication is simple: Azure Active Directory is an authorization server, and the service can request OAuth 2 tokens from it using either client credentials or client assertion (with JWT) flow. Then, the service can use this token to authenticate to other services.
In the last few months, we started moving some of our services to AWS. And this makes me wonder - is there an alternative to Azure Active Directory? I could not find something myself, so I thought it is better to ask: What is the recommended way to implement service to service authentication outside Azure? I know you can use Azure Active Directory also outside Azure. I am asking that because I guess there must be other tools out there, maybe with easier integration with AWS.
I didn't mention any programming language (we are using mainly C# here, and a little NodeJS recently) because I feel this question is language-agnostic - I will prefer solution that works well with many languages.
Thank you,
Omer
Amazon has AWS Directory Service.
It's Microsoft AD in AWS Cloud.
I wouldn't know of any AWS services that'll help you with that exact use-case. However, you could solve this by exposing two ports in the application; one for internal requests and one for external. You can use security groups to shield off the internal port for requests from the internet.
Another option that might involve more changes to your setup is to use a gateway. This pattern is used a lot for microservices, an elaborate description can be found e.g. here. The basic concept is that all outside (internet) requests go through a gateway service that allows certain routes and disallows certain other routes. In cases where users have to login, the gateway will usually handle the authentication.
Environment variables are the means by which the Cloud Foundry runtime communicates to the application about its environment. One of the most important pieces of information it communicates are the services which are available and how to connect with them.
Source
The same page gives a sample of environment variables containing connection parameters like user-name password for MySQL database.
VCAP_SERVICES: {
"mongodb-1.8":[{"name":"hello-mongo","label":"mongodb-1.8","plan":"free","credentials":{"hostname":"172.30.48.64","port":25003,"username":"e4f2c402-1153-4dfb-8d98-2f6efc65e441","password":"f17f81e4-9855-4b9c-a22b-e6a9e6f113c3","name":"mongodb-5751dac0-3b5e-405b-a1e1-2b384fe4026d","db":"db"}}],
"redis-2.2":[{"name":"hello-redis","label":"redis-2.2","plan":"free","credentials":{"node_id":"redis_node_4","hostname":"172.30.48.43","port":5002,"password":"e1d7acb0-2baf-42be-84bc-3365aa819586","name":"redis-96836b7c-0949-45fd-a741-c7be5951d52f"}}],
"mysql-5.1":[{"name":"hello-mysql","label":"mysql-5.1","plan":"free","credentials":{"node_id":"mysql_node_5","hostname":"172.30.48.24","port":3306,"password":"pw4EKJqL6na6f","name":"dd9b58515e3cb41958a30bf2af88126fc","user":"uLfJbOmxfSEUt"}}]
}
The page further states:
You can read this information into your application using Java's environment variable API and/or existing Spring XML features but it is easer to consume this information using the new cloud namespace (described here) which parses it out into a convenient Properties object.
Reading this I wondered what implications this setup have for application security. Specifically what measures should the developer take to keep malicious attackers from gaining direct control of backend services like mysql database?
EDIT: Apart from the risk of attacker gaining control of backend service, I also can imagine the risk of attacker causing the application to connect to a malicious backend.
If you want to connect to a backend (database) service, you must provide the application with credentials somehow. To be able to dynamically bind to services, environment variables are a good choice to pass application private information to to the application.
As with any application compromise, the backend gets exposed when the application is hacked.
The only way you can connect to a malicious backend is if the attacker can setup a malicious service on the Cloud Foundry infrastructure and is able to compromise the Cloud Controller to pass the application forged environment variables.