-
Type:
Improvement
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: 4.3.4
-
Component/s: Diagnostics
-
None
-
Minor Change
-
v4.4
-
Security 2020-04-06
When I attempt to authenticate against MongoDB server 4.3.4 using AWS mechanism, if the request made by the server to STS fails I see entries like the following one in the server log:
{"t":{"$date":"2020-03-16T19:52:54.525-0400"},"s":"I", "c":"ACCESS", "id":20249,"ctx":"conn325","msg":"SASL {mechanism} authentication failed for {principalName} on {authDB} from client {client} ; {result}","attr":{"mechanism":"MONGODB-AWS","principalName":"AKIANOTFAKE","authDB":"$external","client":"127.0.0.1:60966","result":"OperationFailed: Unexpected http status code from server: 403"}}
If I make a request to the STS and it fails, the response contains information that helps troubleshoot the problem. For example the following are two of the responses I have received by talking to STS directly:
"403" [["x-amzn-requestid", "1c45ec22-87cc-4127-8b4d-a69f052924e3"], ["content-type", "text/xml"], ["content-length", "297"], ["date", "Tue, 17 Mar 2020 03:55:09 GMT"]] <ErrorResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/"> <Error> <Type>Sender</Type> <Code>MissingAuthenticationToken</Code> <Message>Request is missing Authentication Token</Message> </Error> <RequestId>1c45ec22-87cc-4127-8b4d-a69f052924e3</RequestId> </ErrorResponse>
"400" [["x-amzn-requestid", "0f9a1fa4-925d-4416-987c-1f783fd8b6b2"], ["content-type", "text/xml"], ["content-length", "314"], ["date", "Tue, 17 Mar 2020 03:54:42 GMT"], ["connection", "close"]] <ErrorResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/"> <Error> <Type>Sender</Type> <Code>IncompleteSignature</Code> <Message>Request must contain a signature that conforms to AWS standards</Message> </Error> <RequestId>0f9a1fa4-925d-4416-987c-1f783fd8b6b2</RequestId> </ErrorResponse>
These are still rather cryptic but are much more helpful than only having the HTTP status code.
Actual behavior:
It appears that when a request to STS fails, the server does not log the response body or the extracted failure reason anywhere.
Expected behavior:
As a driver engineer implementing AWS authentication, I expect the server to log the full response body or the complete extracted failure reason in the logs so that I can effectively diagnose why authentication is not working.
I imagine this logging will also be helpful to anyone who changes the STS endpoint that the server is using, in the event that a driver, for example, misdetects the region of the endpoint and subsequently creates the wrong signature.
- depends on
-
-
- Closed
-