How to Connect Mendix to Amazon Bedrock via REST Activity?

0
Hello everyone,   I am currently attempting to connect my Mendix application to Amazon's Bedrock service, and I am receiving the following error:   403 Forbidden (InvalidSignatureException): The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.   I have successfully made a connection using Temporary Credentials and the Bedrock Connector module, which includes an activity for the InvokeModel API, however I now need to connect to Bedrock's ConverseStream API, which unfortunately is not currently included in the module. I created a microflow (see below), closely following a Mendix blog post, and it seems like I have configured everything accordingly apart from the SigV4Builder and REST activity. I believe the mismatch in signatures is caused by either of the configurations for these microflow components.   Microflow Overview:   SigV4Builder Details:   REST Activity Details:   Based on the above screenshots, are there any obvious discrepancies in my configurations or additional headers I need to include?   Additional Notes: I do not believe my static credentials are the issue - I have tried two sets of access keys from my IAM user account, as well as an additional set from a newly created IAM user account which still resulted in the same error (i.e., 403 Forbidden: signature mismatch). I noticed when I test the request in Postman, it adds a "Content-Length" header in the request. I tried adding it to the REST service activity, but I received a Java exception stating that this header was already added. I am wondering if this might be why there is a signature mismatch, if in fact, the SigV4Builder/GetSigV4Headers logic is not incorporating this header into the signature. The tutorial I followed included an "x-amz-target" header, but I could not find any documentation on Amazon Bedrock requiring this header, nor a value for the header if it exists for this service. I noticed the logs from the REST service activity added an "HTTP/1.1" string to the end of the URL in the request. Although this is not a request header that one manually adds, when I included it in the "path" member of the SigV4Builder as follows: "...%20HTTP/1.1", I finally received a 200 OK status but an invalid operation error. This led me to believe I may have at least successfully authenticated. Any insight or guidance would be much appreciated!
asked
4 answers
0

Hi Matt Hargenrader,

For the ConverseStream, the service in the builder should be 'bedrock' (as you have it). This leads to the host being generated as 'https://bedrock.us-east-1.amazonaws.com', however ConverseStream needs to have the host 'https://bedrock-runtime.us-east-1.amazonaws.com' So you could overwrite the $SigV4Headers/Host you are using in the REST call with 'https://bedrock-runtime.us-east-1.amazonaws.com'.

Please let me know if this solved your problem.

Best regards,

Daan

answered
0

Hi Daan,

 

Thank you for your response and feedback.

 

I was in contact with someone from the Mendix team, and they advised the same thing and to set up the SigV4Builder as follows:

 

SigV4Builder.png

 

When I followed the above implementation, coupled with overwriting the Host header in the REST activity, the 403 Forbidden (i.e., signature mismatch) error was seemingly resolved, but I did receive a 400 Bad Request error instead.

 

This recommended solution makes sense, but I think something else is causing the signature mismatch error. If you look at the Java source code for the GetSigV4Headers action within the AWS Authentication module, the Host header is calculated as follows:

 

GetHost.png

 

The getSubDomain method actually defaults to the ServiceName value if the SubDomain member is either null or empty, as seen below:

 

GetSubDomain.png

 

With this in mind, it seems the proper approach is to add the SubDomain member to the SigV4Builder (i.e., "bedrock-runtime"), which properly calculates the Host header, but as stated previously, this still results in a 403 Forbidden error.

 

Please let me know if you have any other ideas.

 

Best regards,

Matt

answered
0

Hi , 

Are you able to resolve this issue. If yes , please give me the details how it was. I am also facing this same issue. But I am able to execute Retrieve API , but not Invoke and converse APIs. 

answered
0

I encountered a similar issue and managed to resolve it.

 

The request worked in Postman because Postman automatically handles AWS Signature Version 4 signing. I inspected the request using the Postman console and noticed that the Host header sent by Postman differed from the one generated by the Mendix Java action GetSigV4Headers.

 

In AWS SigV4, the Host header is not just a regular HTTP header—it is one of the signed headers used to generate the signature included in the Authorization header. If the Host value used during signature generation does not match the actual Host header sent in the request, AWS will reject the request with a 403 SignatureDoesNotMatch error.

 

Therefore, it's not sufficient to simply set the correct Host header in the REST API call. You must ensure that the exact same value is used during signature generation. This is especially important when using proxies, custom endpoints, or when the request is routed differently than expected.

 

Solution:

1. Make a copy of the Java action GetSigV4Headers you're using to generate the headers.

2. Edit the method getHost(String awsRegionString) in the Java action to return the correct Host value identified from postman.

 

Java code before and after:

Before

JavaCode_Before.png

After

JavaCode_After.png

 

This ensures that the signature generated by your Java action matches what AWS expects, avoiding signature mismatch errors.

 

answered