Is it possible to expose an API endpoint in AWS API Gateway using basic authentication ?
Basically, an API endpoint which can be accessed using username and password ?
Further I want to take the user's payload to a SNS Topic / SQS queue. ( Customer with Username & Password -> AWS GATEWAY API -> SQS/SNS)
I am seeing quite lot of articles on how to expose using JWT's , but not using basic authentication.
Regards
Guru
You can use AWS proxy integration method on API Gateway to put the payload into SQS from the API endpoint. Basic authentication is currently not supported by API Gateway.
you can create a dummy endpoint in the API Gateway, and create a Lambda function to authorize it handle the login logic inside that authorization lambda function.
Note: it works but not an good practice
Related
Prerequisites
I have two Cloud Run services a frontend and a backend. The frontend is written in Vue.js/Nuxt.js and is using a Node backend therefore. The backend is written in Kotlin with Spring Boot.
Problem
To have an authenticated internal communication between the frontend and the backend I need to use a token thttps://cloud.google.com/run/docs/authenticating/service-to-service#javahat is fetched from the google metaserver. This is documented here: https://cloud.google.com/run/docs/authenticating/service-to-service#java
I did set it all up and it works.
For my second layer of security I integrated the Auth0 authentication provider both in my frontend and my backend. In my frontend a user can log in. The frontend is calling the backend API. Since only authorized users should be able to call the backend I integrated Spring Security to secure the backend API endpoints.
Now the backend verifies if the token of the caller's request are valid before allowing it to pass on to the API logic.
However this theory does not work. And that simply is because I delegate the API calls through the Node backend proxy. The proxy logic however is already applying a token to the request to the backend; it is the google metaserver token. So let me illustrate that:
Client (Browser) -> API Request with Auth0 Token -> Frontend Backend Proxy -> Overriding Auth0 Token with Google Metaserver Token -> Calling Backend API
Since the backend is receiving the metaserver token instead of the Auth0 Token it can never successfully authorize the API call.
Question
Due the fact that I was not able to find any articles about this problem I wonder if it's simply because I am doing it basically wrong.
What do I need to do to have a valid Cloud Run Service to Service communication (guaranteed by the metaserver token) but at the same time have a secured backend API with Auth0 authorization?
I see two workarounds to make this happen:
Authorize the API call in the Node backend proxy logic
Make the backend service public available thus the metaserver token is unnecessary
I don't like any of the above - especially the latter one. I would really like to have it working with my current setup but I have no idea how. There is no such thing like multiple authorization token, right?
Ok I figured out a third way to have a de-facto internal service to service communication.
To omit the meta-server token authentication but still restrict access from the internet I did the following for my backend cloud run service:
This makes the service available from the internet however the ingress is preventing any outsider from accessing the service. The service is available without IAM but only for internal traffic.
So my frontend is calling the backend API now via the Node backend proxy. Even though the frontend node-backend and the backend service are both somewhat "in the cloud" they do not share the same "internal network". In fact the frontend node-backend requests would be redirected via egress to the internet and call the backend service just like any other internet-user would do.
To make it work "like it is coming from internal" you have to do something similar like VPN but it's called VPC (Virtual Private Cloud). And luckily that is very simple. Just create a VPC Connector in GCP.
BUT be aware to create a so called Serverless VPC Access (Connector). Explained here: https://cloud.google.com/vpc/docs/serverless-vpc-access
After the Serverless VPC Access has been created you can select it in your Cloud Run Service "Connection" settings. For the backend service it can be simply selected. For the frontend service however it is important to select the second option:
At least that is important in my case since I am calling the backend service by it's assigned service URL instead of a private IP.
After all that is done my JWT token from the frontend is successfully delivered to the backend API without being overwritten by a MetaServer token.
We have our identity server implemented using identity server
https://github.com/IdentityServer/IdentityServer3
or
https://github.com/IdentityServer/IdentityServer4
And user will authenticate and get the access token from the identity server. We have some APIs developed in AWS api gateway. Just wondering what is the common practice to implement the authentication / authorization in the aws api gateway. We would prefer to use the existing access token from the identity server in the API gateway.
You will need to configure a custom authorizer on your API Gateway. The Custom Authorizer will use a Lambda Function to validate the Access Token. You will need to configure the Lambda Function to validate accordingly to your token. Here are some resources to help you configure the API Gateway Custom Authorizer with Lambda Function:
Use API Gateway Lambda Authorizers
Custom Authorizers in API Gateway and Lambda
Can we use Two Way SSL feature using AWS API Gateway ? We want to use API Gateway as proxy for kinesis in our real-time streaming application.
Below is my requirement
The client make request to apigateway and apigateway needs to put the data in kinesis streams.
The only way to authenticate the clients is using two way SSL. our clients doesnt support other options.
Currently on-premise F5 loadbalancer does this work for us and we have tomcats running behind F5 placing data into kinesis.
Will i be able to achieve the same using API Gateway ? looks like even aws ELB seems to be not supporting this option.
I have taken a look at below link but this to authenticate API Gateway at server not apigateway authenticating the client.
https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-client-side-ssl-authentication.html
Regards
Kalyan
API Gateway can authenticate itself to your back-end with TLS, as you have found, but it does not work in the opposite direction -- it does not support authenticating clients with TLS.
Is there a way to use Basic authentication rather than AWS4-HMAC-SHA256 authentication with the AWS API Gateway Service? I need to support a system that only supports webhook calls with Basic Authentication.
You just need to modify the 401 Unauthorized response template so that it contains the WWW-Authenticate header set to 'Basic'. Apart from that, you'll need to create a custom authorizer that verifies that the provided credentials are correct. You can find more info here
You can configure an API Gateway to support Basic auth, and API Gateway supports integrations with any AWS service.
Setting up Basic auth in API Gateway requires a few steps. Check this post and search down to BobK#AWS response: https://forums.aws.amazon.com/thread.jspa?messageID=799091&tstart=0
I want to set up API Gateway to point to a Lambda function which will process outbound messages from Salesforce.
All Saleforce instances share an IP range, so the way to verify that a message is from our instance is to use a cert from Salesforce to provide mutual authentication.
I know that you can use mutual authentication between API Gateway and your backend service, but I'm not sure about between the client and API Gateway. Is this possible to set up?
API Gateway does not currently support client certificate validation (aka mutual authentication) between the client and API Gateway. We have a feature request for this on our backlog, but we can't commit to a timeline for delivering it.