Is there a limitation on Neptune HTTP API endpoint compatibility when using a proxy and IAM Auth?
Hi,
Got a weird one today. I'm working on bringing full compatibility for the use of proxies fronting Amazon Neptune services.
In my setup I have an Amazon Neptune cluster and an nginx proxy. The proxy runs on an EC2 container and provides connectivity to Neptune over a public domain.
Additionally, my Neptune DB has IAM authentication enabled.
The issue I'm encountering is the following:
When attempting to make API calls to the Neptune instance through the proxy, (e.g. status/explain/profile APIs), the calls are getting consistently rejected with a 403 Forbidden despite using the correct credentials. (when accessing the Neptune DB via SSH tunnel and using the same credentials, the requests are authorised).
For WebSocket auth, this proxy setup appears to work (using the NeptuneNettyHttpSigV4Signer utility).
For HTTP auth, it fails (using the NeptuneApacheHttpSigV4Signer).
To allow this setup to work correctly using WSS, the handshake interceptor takes an extra step to replace the Host header in the request with the original Neptune DB endpoint (not doing this causes the Neptune API to respond with a 400 error).
I've implemented the same mechanism for making HTTP API calls to Neptune using the Apache HTTP Client and unlike the Netty implementation this causes the API call to fail with a 403.
I'm struggling to get the signature generated on my end to match the format expected server side on Neptune, using these utility classes. Is there any recommended way to sign REST API calls to Neptune endpoints made behind a proxy?
1 Reply
Ok so apologies for responding to my own question so quickly but I just found out I'd made a typo which led to an extra trailing slash in the URL, causing the signature to mismatch where it's targeted
The way I've done this is perhaps unconventional but I couldn't really figure out any other way, so I'll put it down here for anyone's reference in the future:
At the stage of signing the Apache HttpRequest object to be submitted to the Neptune API, I do the following:
Set the URI object of the request to use underline Neptune endpoint hostname rather than the proxy value
Sign the request using the NeptuneApacheHttpSigV4Signer.
Restore the URI object of the request to its original value (at this stage this means the request object has signature headers that would be as if pointing directly to the Neptune endpoint, but it is in fact submitted to the proxy endpoint)
Submit the request
I'd previously investigated just setting the header value of the request to the underline Neptune endpoint but it turns out the AWSSigner class just overwrites the host header based on the request's URI object value, hence the weird workaround