Am looking for code of a Api backend .... to distribute blockchain node enpoints to users
Http and wss
Thanks
Related
I know one of API Gateway offers is to provide a security layer of any backend APIs. But how if the case is the backend has its own authentication already (let say api key, jwt or other)? What is the better approach / best practice:
Modify those backend APIs to become "plain API" (without any auth), so will rely only on API Gateway auth (OAuth2)
Keep the backend auth as it is, but then create a microservice that will act as wrapper API to handle that backend auth.
The goal is to prevent double authentication & give the same experience to the clients where they only need to pass 1 authentication which is by the API Gateway. Thank you!
I would keep the backend's API security. There is nothing wrong with having secured communication behind an API gateway. As a matter of fact, I recall this being a recommended approach.
To prevent double authentication, would it be a suggestion to define a public (unsecured) end-point on the API gateway to access the authentication end-point of the authentication server used by your backend services. The client receives the authentication token from that authentication server and the API gateway passes the token through to the API of your backend services.
Another possibility could be to authenticate towards the API gateway but let the API gateway use the same authentication server as your backend services. Some gateways allow you to forward the authentication to an authentication server somewhere outside of the API gateway.
I have a set of Microservices in Docker containers in AKS which need to serve only authenticated requests.
I have another Microservice which authenticates with Gigya.
Is there any way in AKS wherein I can put an APIM or Gateway in the middle and have unauthenticated requests to be sent to the Authenticate Microservice and the authenticated requests to be sent to the corresponding Microservice within AKS.
I have been looking for sources on the net for this, but haven’t been able to find any. Can you help?
How about the ORY Oathkeeper?
It works together with ORY Keto and ORY Hydra.
I'm experimenting with Kong API gateway. It has nice features such as API key and HMAC authentication via plugin, so I don't have to implement my own security into each of my API.
But it seems to be trade-off. Suppose I have Payment service. In it I need to check for API key, so I create request interceptor for each request to payment service, needs to provide valid API key.
I use kong as reverse proxy to payment server upstream. I also want to move this API key validation into kong, so my payment service (and other service) become plain-not-secured API. It seems nice since I don't have to re-write interceptors for each service. But if somebody know the IP of payment service, then they can directly hit payment service without Kong API gateway.
What should I do to achieve these:
use kong as API gateway (reverse proxy)
use kong plugin for validation (API key / basic / HMAC) so I don't need to re-configure them in my services
avoid security hole if somebody knows the address of API, and hit them directly (bypassing kong security), but keeps #1 and #2, so the API programmers write is simple API but keep secure
Thanks in advance
I would like to ask about the functionalities of Consul and API Gateway. Is Consul can replace API Gateway as a service referrer ?
Or how to use both of them in term of microservices architecture ?
Thank You
Consul is multi datacenter service discovery (+health checking) and distributed K/V store.
API Gateway is a service that handles all the tasks involved in accepting and processing API calls, including traffic management, authorization and access control, monitoring, and API version management.
so they're quite different..
depends on what you're trying to achieve and your current API Gateway use case, you may be able to use Consul + Consul aware load balancers, such as https://github.com/fabiolb/fabio and https://traefik.io/.
At a high-level, an API gateway would become the single point of entry to your micro services. It would allow you to give a consistent user experience to your clients - irrespective of the backend services.
They act as an abstraction - when you hit a /product/{productId} endpoint, you shouldn't need to know about the internal microservices e.g. /reviews, /recommendations etc - the gateway can do this for you and return a single response.
API gateways will be configured to receive a request on a listen path e.g.
curl http://gateway.com/myservice/mypath -H 'Authorization: secret_auth_token'
Internally, the gateway will receive the request and will see that myservice points to a specific api definition.
And based on that auth-token, will be able to establish whether the user is allowed access, what rate limit / quotas and also what upstream targets & paths they are allowed access. A few typical features:
Authentication & Authorisation
Rate Limits
Body Transforms (Filters / Map Reduce / Json -> XML, XML -> Json)
Header Injection
Json Schema Validation
Method Transforms
Mock Responses
API Versioning Strategy
Send requests to multiple targets
the list goes on.
So the gateway will then proxy the request to myservice.com/mypath for example and return the response to the client.
Now let's assume you want your upstream to be highly available - e.g. you may have myservice1.com and myservice2.com.
The gateway can be configured to load balance requests between these services. And you could use features of the gateway for testing the health of the upstreams, but there are also dedicated tools for this. One such tool is Consul.
API gateways should be able to integrate with service discovery tools. So let's assume myservice1.com goes down for maintenance, the gateway will know never to send traffic there and to only send to service2.com till service1 comes back up.
Screenshot below is example of tyk.io api gateway integration support for Consul.
Clients that communicate against a single point of entry via an API Gateway over HTTPS against a RESTful API
API Gateway: API Keys for tracking and analytics, oAuth for API platform authentication
User Micro service provides user authentication and authorization, generates JWT that is signed and encrypted (JWS,JWE)
Other micro services determine permissions based on claims inside JWT
Micro services communicate internally via PUB/SUB using JWT in the message and other info. Each micro service could be scaled out with multiple instances (cluster with a load balancer).
Question: Can I cluster the the API Gateway and have the load balancer in front of it. What do I need to consider with respect to managing authentication? ie: sharing of API Keys across the API Gateway cluster?
Extra notes, I'm planning on terminating SSL at the gateway and the use of bcrypt for passwords in the db.
Any feedback would be great, thank you.
Can I cluster the the API Gateway and have the load balancer in front
of it.
Yes, you can. Most of the good Api Gateway solutions will provide the ability to do clustering. e.g. https://getkong.org/docs/0.9.x/clustering/ or you can use cloud based Api Gateway: Azure API Management or AWS API Gateway
What do I need to consider with respect to managing authentication?
These specifics depends on your selection of API Gateway solution.