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.
Related
We're developing a web application (SPA) consisting of the following parts:
NextJS container
Django backend for user management
Data API (FastAPI) protected with API keys, for which we also provide 3rd party access
The NextJS container uses an API key to access the data API. We don't want to expose the API key to the client (browser), so the browser sends the API requests to the NextJS container, which then relays it to the data API, see here. This seems secure, but is more complicated and slower than sending requests from the browser to the data API directly.
I'm wondering if it's possible to whitelist the web application in the data API, so that the client (browser) can call the data API directly without API key, but 3rd parties can't. FastAPI provides a TrustedHostMiddleware, but it's insecure because it's possible to spoof the host header. It has been suggested to whitelist IPs instead, but we don't have a dedicated IP for our web application. I looked into using the referer header, but it's not available in the FastAPI request object for some reason (I suspect some config problem in our hosting). Also, the referer header could be spoofed as well.
Is there even a safe way to whitelist our web application for data API access, or do we need to relay the request via NextJS container and use an API key?
Is there even a safe way to whitelist our web application for data API
access,
No, you need in all case an Authentication mechanism, something before the backend that check if the client is an authorize client.
The simplest pattern is using the NextJS container as the proxy. Proxy that have an api-key to call the backend ( what you are currently doing ).
There is many way to implement a secured proxy for a backend, but this authentication logic should not be inside the backend but in a separate service ( like envoy , nginx ... )
Given that I would create an OAUTH2 authentication server.
Given that I would to have separate resource servers, exposing REST APIs.
What are the best communication practies between the authentication server and the API servers?
To explain OAUTH2 server would be a proxy authenticating the user and forwarding requests to different API servers, that are not third party, but under the hood of the OAUTH2 proxy, relying on it to know the agent (user) requesting for the given command\query.
The simplest would be that the authentication server will forward the user id (that is stored with ACL rules also on each API server) under a secure connection, and that access would be restricted to request forwarded from authetication server to resource API servers.
The auth server would in this case forward the user id, but this seems suceptible to mand in the middle attack (altought firewall on API servers would be configured to accept requests only from the authentication server).
Another problem would be compromission of the OAUTH proxy, giving automaticly grant to any request coming from it.
Are there ready solution and patterns to deal with this scenario?
Thanks!
Check the User Account and Authentication Service (UAA) from CloudFoundry. Maybe will help you. It is also available as a stand-alone OAuth2 server.
API Documentation, GitHub
I have an rest HTTP endpoint that is sitting outside of AWS, but I want to use AWS API Gateway to proxy through to that endpoint. What would be the best way to only allow requests to the HTTP endpoint to process that come through the API gateway?
One possibility would be to make your non-AWS endpoint require a client TLS certificate. AWS API Gateway can generate client certificates, and your non-AWS endpoint can:
require a client certificate (if not provided, then ignore / don't allow)
use the API Gateway cert public key to verify the client is your API Gateway.
This would give you good assurance that traffic to your non-AWS endpoint is only coming through the AWS API Gateway, so long as the client certificate generated by AWS is not compromised.
From the AWS FAQs:
Q: Can I verify that it is API Gateway calling my backend?
Yes. Amazon API Gateway can generate a client-side SSL certificate and make the public key of that certificate available to you. Calls to your backend can be made with the generated certificate, and you can verify calls originating from Amazon API Gateway using the public key of the certificate.
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
I'm designing a REST service in Node, and I have a plan for authentication and authorization -- but I'm not certain whether there's an unforeseen flaw in the design.
I have a central API server exposed to the Internet. The server also hosts a manager application (which communicates via AJAX), but is authenticated separately from the API, per requirement.
My initial thoughts are to have the server authenticate the user with a login form, then send the user a token (all over HTTPS, of course) that can be sent with each request to the API server for authentication and authorization.
Are there any flaws with this methodology?