I am working on a distributed web application using Spring Microservices design pattern where individual services are running on different ports like -
Product Management - domain:8500
User Management - domain:8501
Now If the user calls User Management by opening the URL "domain:8501/some_url" which internally calls Product Management i.e. "domain:8500/some_other_url" and also assume that certificate is self-signed i.e. for the browser, the CA is unknown and hence the exception needs to be manually added in the browser.
In this case, while Chrome works fine, Firefox and IE also probably adds the exception for domain with port and hence for internal call as well it waits internally for the security exception to be added.
As a result, my API calling is failed. Is this a Firefox behaviour or I am doing something wrong?
AJ
Try either using an API gateway or a proxy. You can use Zuul for a proxy. Please go through Zuul starter.
You can even do some more interesting things by having a proxy. Like:
Implementing Security: Implement Validation & Verification as security check over the proxy and can avoid the same over other microservices.
Response Handling: You can alter a generic response from your microservices in proxy for the client(Web/Mobile Browser/Mobile App)
Hope this helps.
Related
There is a Spring Boot app running on a host, it exposes number of REST endpoints. One of these endpoints is providing sensitive information.
On the same host resides a client app, over which I have no control.
1 - Is there any way using Spring Security to limit access to the endpoint in question, based on client's port?
I cannot change anything in the client app, since it is a 3rd party app.
2 - is there any other way to limit access based on ports, like iptables rules?
No, it seems like it is not possible to limit access to endpoint based on the port of the caller, only using Spring Security.
Spring Security Doc
1 - However, using Spring Security one can limit access, based on the IP that the request is made - here.
2 - Also one can get the HttpServletRequest request object in the controller method and get the port that the request is made from, like:
request.getRemotePort();
//IP is also available
//request.getRemoteAddr();
=> in the end what I need is doable.
I am developing an application consisting of RESTful services communicating over HTTP. Spring Boot is providing the underlying support.
As part of my investigations, I am currently working with a known working example of a RESTful client and server that uses HTTPS/SSL/TLS ( https://github.com/indrabasak/spring-tls-example ). I have managed to successfully build, run the example and verify that it works.
Part of the client security configuration code involves setting up basic authorization on a org.springframework.boot.web.client.RestTemplateBuilder.
I am under the impression (perhaps incorrect) that authentication is not required. Am I right or wrong in this assumption?
I have been experimenting with trying to remove the authentication and when I run the example, the server emits output indicating that the action is "Unauthorized". On the client side, I get a 201 response (for a POST), but the JSON data does not contain the data I expect.
I have a system with microservice architecture. So I have a setup such that when I hit an URL, for example "http://localhost:8081/data/myId/" I get back a JSON response describing a resource. This is the system which I have created.
It turns out that there is some more complexity as to get this response, I am making a connection to an external service provider - this is what I want to use WireMock to mock, as this service provider has an API call limit. Let us say that I am interacting with this service provider at the following URL "https://api.dummyservice.com/". (So all "http://localhost:8081/data/myId/" calls consist of a "https://api.dummyservice.com/" call.)
So I am using WireMock as follows
java -jar '/home/user/Desktop/wiremock-standalone-2.19.0.jar'
--recd-mappings
--proxy-all https://api.dummyservice.com/
--verbose
--print-all-network-traffic
My intention is to listen to all calls at https://api.dummyservice.com/ through my microservice-based system so that I can stub and mock the responses. The problem is that I am not capturing any traffic at all when I access "http://localhost:8081/data/myId/" and get a successful response back!
Have I misunderstood WireMock's application? How can I debug this issue? It seems that I am performing quite a straightforward task.
I am on an Ubuntu 18.04 system if it makes any difference.
It seems you use standalone WireMock in a proper way, but please check correct params here
--record-mappings
--proxy-all="https://api.dummyservice.com/"
Scenario:
My Application stands in connection to Web service (Master Server). Sometimes i make calls like login on application startup, where my application sents user credentials to the master server for validating.
So, how do i 1st validate that the answer is from my real server and not a fake local webserver with routed hosts file? And 2nd how do i parse this answer?
I always parsed like this (dummy code):
if($answerFromWebserver == "LOGIN_OK") {
doLogin();
}
Are there better, more safe solutions?
some of the security feature I see/use,
You can allow specific IPs to server, can setup firewall for this.
Setting up SSL/HTTPS will be great benefit to secure transport level.
You can send username/password encrypted with every message, so at server side authentication will took place each time. You can use SOAP header for this.
You can read huge article from ms here on securing services..
In Azure, if you choose to use internal endpoint (instead of input endpoint), https is not an option. http & tcp are the only options. Does it mean internal endpoint is 100% secure and you don't need encryption.
Then it comes to another question. If i choose to use input endpoint between mvc application and wcf service. Is it really necessary to have https between them? Is it OK if i have 2 input endpoints for wcf. One with http on port 80, which is supposed to be used by mvc application. Another with https on port 443, which can be used by somebody else. (not our own application)
Do you need to encrypt internal endpoints?
No, a web/worker role cannot connect to an internal endpoint in another deployment. The Azure network prevents this, so man-in-the-middle attacks shouldn't be possible. Therefore, it's not necessary to enable SSL on internal endpoints.
Is is necessary to enable HTTPS on WCF endpoints?
It's certainly possible to configure your application in that way. Why not make the port 80 endpoint on the WCF service an internal one? Or - why not host the WCF application on the same Role, then you can just use the loopback address?
You need to think about the security requirements of your application and go from there.