Hello AWS – Authentication Module
![](https://www.mendix.com/wp-content/uploads/Hello-AWS-Authentication-Connector-Thumbnail.png)
I recently launched a new series on Youtube called HelloAWS. To accompany the videos I thought it would be helpful to create a series of blogs which follow along – in a blog I can add as much detail as I want without fear of going over time. Just like the videos, this series is going to be centered on AWS and how to use their services in Mendix.
![](https://play.vidyard.com/qWWj94cN3LQtAPZQz9hVsF.jpg)
We’ve been hard at work creating a bunch of connectors to make AWS services easier to use in a low-code way. In this series, I’m going to cover how each of these modules work, and show you how to use them in your Mendix development.
If you want to use any of these awesome new connectors, you’re first going to have to authenticate your Mendix app using the AWS Authentication Module, so we’re going to have a look at it in this video.
A quick look at what AWS modules and connectors I’m going to cover in this series:
- AWS Authentication
- Amazon Rekognition
- AWS Lambda
- Amazon DynamoDB
- Amazon SNS
- Amazon Textract
- Amazon Polly
- Amazon Translate
- Amazon S3
- Amazon EventBridge
Download
To start setting this up, we can go click on the shopping cart icon in Studio Pro to open up the marketplace panel in the side window. Search for the ‘AWS Authentication Connector’ and click to open it up. Next we can click download and then choose to add it as a new module, and click import to confirm.
Static vs Session credentials
Under the description in the Marketplace, it states that this module supports two forms of authentication with AWS. First, we have static credentials and then we have session based credentials.
What’s the difference?
Static credentials work using an Access Key and Secret Key combination and may be more familiar to most developers. However this method is less secure, if someone gets access to these credentials your app may be at risk.
Session based credentials work using short lived tokens which are only valid for a small period of time. It works by establishing trust beforehand using AWS new Roles Anywhere feature. Once trust has been established you can generate sigv4 headers to sign your requests to AWS.
What are sigv4 headers?
Signature Version 4 is the AWS signing protocol, which is required to authorize REST API requests for AWS services. In other words they are special headers you need to add to your REST call in order to securely connect with AWS.
Creating a trust anchor
We are going to login to the AWS Console for the next part of this build. Once you are logged in, search for roles anywhere in the search bar.
Here we need to create a role in roles anywhere. This is a quick three step process. First, we need to create a trust anchor. So click the button.
Make sure your region at the top of the screen is correct, because this needs to match in your in your AWS project and later in your Mendix app.
Next enter a name for your Trust Anchor – “HelloAWS”. Now we need to provide a Certificate Authority. We can either use AWS Certificate Manager to create a Private CA or we can create our own.
For more information on how to create your own CA, read this blog by my colleague Joe Robertson on how to securely connect with AWS services.
Next, we need to select ‘upload an External Certificate bundle’, and then we can open up our certificates in a text editor. Copy everything in the certificate including the Begin and End certificate lines, and then paste it in the space. To confirm, click ‘create trust anchor’ at the bottom of the screen
Creating an IAM user
Step two of this process is to create a new IAM Role. Before we do that we have to create a profile for that role to use. Click configure a profile
Under step two click “create a new role”. Then choose to create a custom trust policy and paste in this JSON:
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"Service":"rolesanywhere.amazonaws.com"
},
"Action":[
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
]
}
]
}
You then have to add permissions for this policy and this is the part where you select which AWS services you would like to use. I’m going to choose Amazon Rekognition because I’ll be using that in my next video. I’m going to select the full access option – but you should restrict this to only what your app needs in a real world scenario. Finally enter a name for your new role (I’m going to name mine HelloAWS), and click “create role” at the bottom.
The final step in the AWS console is to create a profile using this role we just created, so on the Roles anywhere dashboard, scroll down to policies and we will create one. Just give it a name, select the role we created, attach any policies you want – again I’m going to use Amazon Rekognition here, and then click “create” at the bottom of the screen.
Obtaining session credentials
Now we can directly call our action to get session credentials wherever we want. If I open this up in Studio Pro – you can see it expects a few details from the AWS console. It basically expects everything we just configured and you provide these mostly as ARNs for the role, profile, and trust anchor.
After that we can pass the credentials into the GetSigv4 headers action, which will produce the headers to sign our requests
Now it’s important to note that if you are using this module with another, for instance the Amazon Rekognition one, you shouldn’t actually be calling this directly. Instead the Amazon Rekognition module is already setup to do this and only expects you to configure the correct app using constants.
Uploading the certificate
The last and final thing you need to do is make sure that your Mendix App has access to the same CA which we uploaded into the AWS console. We need to provide a file path to the certificate. It’s really important to note here that AWS expected this certificate in .pem format, but Mendix expects it to be in .pfx format. Once again Joe Robertsons blog covers exactly how to do this in detail. If you have your cert in the correct format, then we just need to provide the file path to where its located on your drive as well as the password you set for the cert when you converted it into its pfx format. If you are deploying your app to the cloud then you will have to configure this in the cloud platform as well.
Calling the module in a microflow
Finally you can call the actions to obtain your credentials, I can run my app and test it out. Have a look at the screenshots below to see how it works – or better yet, go watch the video if you haven’t yet.
Conclusion
It’s important to note you shouldn’t have to worry about creating your own Sigv4 Headers or even calling the get credentials action when using any of the other connectors. The other connectors have been designed to take care of this for you so long as you take care to correctly configure all the required constants, they will obtain the credentials for you automatically. In the next update in this series I will be taking a look at Amazon Rekognition and how to use the Detect Custom Labels action from the AWS Rekognition Connector.
Remember if you get stuck at any point, make sure to check out the documentation on both ours and the AWS doc pages. We have tried to provide you with as much information as we can to ensure your success. I also recommend taking the Mendix Workshop on AWS.
See you in the next one!