I have created multiple microservices like movie-catalog-service, movie-rating-service and movie-info-service.and also created "ZULL API Gateway".
All the request are allowed from the Zuul API Gateway. I want to stop the users from direct access the URL of individual services.
Is there a way to stop users from directly accessing the services mentioned in A and B (only allow the ones that come through the API Gateway)
Related
I'm using Microsoft Graph API to access data from my Azure AD, including adding and updating users.
Is there any way I can limit access to the Graph API based on the client's IP? So that requests originating from a specific IP or an IP range will be served, and the rest will be blocked?
As far as I understand, Graph API deployment https://graph.microsoft.com is a public API that is protected by Azure AD. As long as you have a valid access token you are able to call the API and do what the access token says you are allowed to do regardless of where you are. This means access restriction can only be done at Azure AD level during authorization.
If you apps are user interactive then you can try using Azure AD Conditional Access Location Condition.
For daemon apps that run on server-side, this case may not apply because they run behind your trusted networks in most cases.
I have backend and google endpoints service (both on cloud run). Endpoints service provides information from backend for authorized users. I want to make backend not accessible from outer internet. There are possibility to allow only inner connections by setting Ingress -> Allow internal traffic only. If I do that my endpoints service can't reach backend. All endpoints and backend connected to the same VPC. How can I exclude backend from outer internet? how I want it be
You have 2 solutions:
Continue to expose your backend service to the internet but make it secures (IAM protected service, deployed with --noallow-unauthenticated option). However, grant only the service account of your endpoint service to reach the backend. Like that all the unauthenticated and the unauthorized traffic will be filtered by GFE (Google Front End) and discarded automatically. Only allowed traffic will reach the backend. That solution has the advantage to allow you to also test the backend in case of issue for example, with the correct permissions.
The second solution is exactly what you want:
Set the backend ingress to internal only
Create a serverless VPC connector, add it to the endpoint service with the egress control to ALL.
Like that, all the traffic of the endpoint will be routed through the VPC connector, land in your VPC and then, internally access your backend. Why egress=all?? Because, even if you set your backend ingress to internal, the Cloud Run URL is still public (but an additional check is done to be sure that the traffic comes from your VPC, it's named authenticated network traffic)
At the end, it's always authentication based (on network source or on service account identity). The serverless VPC connection costs about $17 per month
I am building a microservice project in which I need certain clarification on what to do in these situations:
for centralized authentication and authorization or centralized authentication on API gateway, every request must contain jwt token and pass-through API gateway to call other microservice also it should check which user has permission to access API in other microservice. So how can I handle those situations?
I will be using specific tool for exploitation.
users will come through either web browser or mobile app. your api gateway will be exposed to external world. most of the apiGateway nowdays contains plugins for authentication and authorization. for example you can use OIDC plugin with api gatway to authenticate the users which will return JWT token to call the internal apis. you can refer below component diagram link for architecture diagram
Here is my situation:
There is a API service and it'll publish a new version once a season.
I create a web application for each version. So there's a list of web applications under default website that looks like:
API_2016S1
API_2016S2
API_2016S3
...
For clients, the url of API should be the same, even its version has been changed.
The version info won't be a part of the API url.
And the relationship between client and API version is storing in a database.
So the flow of a client's request may looks like:
client
send request(with client id in the header and session's cookie)
a portal application that do:
authentication
determine which API application should be
send client's request to specific API application
specific API application do:
receives request(regardless of authentication)
process request
response to portal application
the portal application responses to client
So for the upcoming new version of API service, I just need to create web applications for them and setting relationships in the database.
For now I'm trying to build the portal application by myself.
My question is: Is there any similar structure or mechanism can handle this kind situation? Or any idea for me. Thanks!
What you are looking for is called API Gateway or API Middleware. Instead of sending requests to the actual APIs, all clients send those requests to this middleware and it serves as a proxy and forwards the requests to a correct APIs.
There are some open source solutions such as KONG, Tyk (and others ) that you can deploy and manage by yourself or you can consider AWS API Gateway as a managed service.
I have a existing application built in ASP.NET. This application has REST APIs. We are wanting to expose these APIs via API connect platform. Now, since our APIs are already authenticated, if we use IBM API connect, then how will end user authenticate to our API and API consumer authenticate via IBM Developer portal?
Lets say our API clientA logs into our developer portal, creates an app and then subscribes to our API. Now when end users try to access our API "VIA ClientA", we need to authenticate the request.
I tried to follow this tutorial http://www.ibm.com/support/knowledgecenter/SSFS6T/com.ibm.apic.toolkit.doc/task_apionprem_redirect_form_.html
But it does NOT get redirected to our external URL.
Please help!
The API gateway (part of API Connect) establishes and enforces authentication between the API end-user/subscriber and your outbound API service running on API Connect. The gateway acts as a service proxy to authenticate potentially many subscribers to a particular API plan (made up of one or several APIs), using API keys that are generated as new subscribers onboard to that plan. The management and enforcement of those API keys is accomplished entirely within API Connect. Nothing is required on your part, except the initial setup parameters for each API.
For that same API, the back-end authentication between API Connect and your existing REST API endpoint is different: it is the same for all end-user subscribers. Every time an end user calls an API they have previously subscribed to, they must first authenticate to API Connect using their unique key (since their usage must be tracked, billed and possibly limited). Once authenticated to the API gateway, all subscribers invoking usage instances for this API will be authenticated to the same API endpoint using the same authentication scheme and credentials as created when setting up the API.
Their are several choices of back-end authentication schemes when using external API endpoints. See this tutorial for more information and links to further resources:
https://www.ibm.com/support/knowledgecenter/SSMNED_5.0.0/com.ibm.apic.toolkit.doc/tutorial_apionprem_security_OAuth.html