I have a microservices based web app. Microservices communicate with each other via a REST API exposed. I want an easy, yet secure solution to secure communication between my microservices. I've already used JWT protocol to secure my user-services communication but I can't figure out the best way to secure server-server communication.
Update:
I want an easy way to authenticate APIs. Is is a good way to hardcode key and secret or put them in configurations files and then use them to authenticate to an other end point?
I've heard about OAuth2 protocol but I'm afraid it's an overkill for my need.So What can be the easy and secure way to authenticate APIs?
You should use HTTPS in order to make communication between servers secure. As far as point to point security (transport layer security) is concerned this is the way to go.
But keep in mind that this still doesn't mean that you'll have message-level security (end-to-end security). Intermediaries (i.e. service agents or other services and applications) along the message path will be able to see what is in the message content while processing it.
REST relies on the uniform contract provided by HTTP, so you cannot use the advanced features of WS-Security as you would have with SOAP. The security features of SOAP provide a wider spectrum of options, so if security is key in your case, you should definitely check SOAP web services out.
Also, take a look at this question. It's relevant to yours and I'm sure you'll find it helpful.
Hope this helps!
Related
I'm aiming at applying an api pattern as can be described for instance on https://medium.com/design-microservices-architecture-with-patterns/api-gateway-pattern-8ed0ddfce9df
As it mentions, "since API Gateway handle client request in centralized placed, its best practice to implement cross cutting functionality on the API Gateways" such as authentication and authorization.
I'm wondering about MITM attacks.
We can make sure microservices are only called by the gateway when whitelisting only the gateway IP, that would be a network safety. But I think this network-level protection shouldn't exclude application-level protection. Only another security at application level (mutual TLS?) would protect the microservices from MITM attacks.
So as a conclusion for a most-perfectly-safe application platform, is api offloading pattern really recommended? And if mitm is a real risk then what's best to add to the pattern to make it real safe?
Looking for a simpler approach for authentication between microservices in Kubernetes.
I have dug some previous discussion. I am aware that it has many trade-offs. Depend on the situation, there could be many different approaches.
Mutual TLS is probably very safe. There is a tool Istio. But I think it has a learning curve and probably overkill for my application.
My application is simple. It does not contain any privacy or critical data. I would prefer a much simpler approach to meet the tight deadline of release cycle.
Is there any approach that utilize Kubernetes secret and do not need a SSL handshake?
For example, keep a pair of asymmetric key in kubernetes secret. Then when service A what to access service B. service A sign the request with timestamp, send the signed result to service B. So that service B could decrypt and check?
I have two enterprise servers which need to communicate in a secure way, and am comparing using SSL (with client/server certs to validate both sides) vs two-legged authentication using OAuth 2.0 (optionally with MAC tokens or JWT tokens).
Historically OAuth seems to have been created for a totally different purpose (the 3-legged case where a user is allowing a service to access some data somewhere), and although two-legged is now integrated into the OAuth 2.0 spec, from what I have seen two-legged OAuth 2.0 doesn't seem to offer much additional protection over SSL.
The only point I can think of is that OAuth is potentially easier to configure than SSL, and it is easy to make mistakes with things like accepting bad SSL certs which can compromise security. However I am not sure if this is reason enough to go with OAuth.
Note that I mention these as separate options, but I think using OAuth would probably entail using it on top of HTTPS/SSL, so both would be used.
Is there any real advantage of using OAuth 2.0 two-legged scheme for server-to-server communication (no user involved)?
Note: I did find a a somewhat similar post here, but that is quite old but I don't feel that gave a satisfactory answer on this matter.
Apologies if you already know this but it isn't clear in your post.
OAuth and SSL\TLS are two separate layers of the OSI model. OAuth is for authentication and is at the top in Layer 7 while SSL\TLS is for transport security in layer 4. It's easy to confuse SSL with client certificates because they both use PKI.
You are correct in your understanding of OAuth...it is used for authorizing individuals not organizations\servers. 2-legged OAuth is a term that is thrown around which encompass various alternate OAuth flows, all of which do not follow a standard.
In my opinion, you want to use client certificates to secure your server-server communication...all that is really required is a single x509 certificate that can be used as both SSL (transport security) and client certificate (authorization); although using 2 certificates is the norm.
I'll respond to this comment:
My question is that, assuming I am using SSL with proper client/server certs to identify each machine, what value would using OAuth (2 legged or similar) on top of that to authorize the servers to one another (assuming there is no user involved). Thanks – Locksleyu
Summary: I wouldn't bother doing both.
Details: 2-legged OAUTH is only as secure as the consumer secret is. Similarly mutual auth SSL is only as secure as the private key. I assume that you'll be storing these in some encrypted store on each server. As both are stored in the same place I see no additional security that comes from adding OAUTH.
Now if you are considering a choice between mutual auth SSL and standard SSL with authentication, perhaps OAUTH can play a role there. I would go with whichever of those options seems easier. So if you have an OAUTH system in place and can easily add server auth to it, perhaps that's the way to go. Otherwise, just go with mutual auth SSL. It tends to be a bit of a hassle to configure but works well and quickly once set up.
To answer your question "what value would using OAuth (2 legged or similar) on top of that to authorize the servers to one another (assuming there is no user involved)."
You may refer below
https://salesforce.stackexchange.com/questions/93887/mutual-authentication-two-way-ssl-oauth
The only reason I can think of is that an extra layer of security is needed because Web Services run on top of an application layer protocol. Does this imply the need for an extra layer of security?
Many people new to Web services see SOAP as a way to exchange messages between two endpoints over HTTP. Over HTTP, one can authenticate the caller, sign the message, and encrypt the contents of the message. This makes the message secure in several dimensions: the caller is known, the receiver of the message can verify that the message did not change in transit, and entities watching the wire traffic cannot figure out what data is being exchanged. For those looking at SOAP messaging to solve bigger problems, however, HTTP-based security simply isn't enough. Many of the bigger problems involve sending the message along a path more complicated than request/response or over a transport that does not involve HTTP. The identity, integrity, and security of the message and the caller need to be preserved over multiple hops. More than one encryption key may be used along the route. Trust domains will be crossed. HTTP and its security mechanisms only address point-to-point security. More complex solutions need end-to-end security baked in. WS-Security addresses how to maintain a secure context over a multi-point message path.
Extract from http://msdn.microsoft.com/en-us/library/ms977327.aspx
How to secure WCF service which an Android app will use?
Currently we are building an android app that will connect(by using SOAP) with a WCF service (made on another pc in console host)...
We actually want to secure this server so only people with right credentials can access the app?
How do we do this??? Do we need to use transport or message security... And can transport only use SSL or not??
And also is it better to use IIS for this or not..
Please help
Thnx
Start by configuring everything to use HTTPS (i.e., HTTP over SSL) so that your communication channels are encrypted. Then add some sort of login credential scheme so that clients authenticate to the server. The simplest is username and password. You can use Basic or Digest auth styles; both should be supported by both ends so the choice is up to you (and it's not so important which you choose since it is all inside HTTPS anyway).
All this is independent of which clients you use and which servers you use. (There's also various XML Security things that you can use with SOAP, but that's adding a lot more complexity for very little extra advantage; the big gain comes from going to HTTPS.)