FileMaker 2024 (i.e. FileMaker 21.0), was released on June 4, 2024. Learn more about FileMaker 2024 on the Claris website. If you’re exploring a new solution on the Claris platform, we encourage you to sign up for a free trial here.
The latest update to the Claris FileMaker platform for 2024 (FileMaker 21) has brought many useful additions and capabilities. Those include a small addition to the curl options noticed. Notably, the flag “–aws-sigv4” which has been available in the normal curl library for a while is now supported in FileMaker.
So, what does this allow you to do? It makes it much easier to integrate with many popular AWS (Amazon Web Services) services. While it was previously possible to make calls to the AWS API directly, doing so meant you had to calculate the correct HTTP headers to generate the required signature algorithm, version 4 referenced here.
With the inclusion of the newly added curl option, developers no longer need to manually calculate those signatures and let the curl library generate the correct values and orders for those API calls.
Use cases are practically endless. AWS offers much more than just providing virtual machines and object storage (S3) that other competing cloud providers offer. including integrating with services like Rekognition for processing images with Machine Learning, accessing Secrets Manager or encrypted Parameter Stores, invoking serverless compute, like Lambda functions that returns JSON replies, Generative AI, and much, much more.
AWS Planning
Managing AWS accounts and resources requires some forethought and planning before starting. As an AWS Advanced Tier Partner, Soliant has a number of people on staff that hold AWS Certifications at both the Associate and Professional level and can provide some guidance regarding some best practices and general advice.
We would like to call out some best practices for working with AWS resources when planning and building your integrations.
The Principle of Least Privileged
For starters, you will want to use the least privileged access when creating credentials to use in your API calls. For any API call, you will need credentials used to make that call. Those credentials should allow access only to what you need to do, without being too permissive. Scoping access in AWS is primarily done with IAM (Identity Access Management) policies. There is a GUI for creating policies, but you can also write them in JSON. In either case the default in IAM policies is to “deny” all, and only “allow” for the actions and resources that your API calls will require.
As tempting as it may be to create a set of credentials tied to Administrator level access so you are not restricted with what you can do, effort should be made to correctly scope access to not be overly permissive. It is best to create your own IAM policy, then attach it to the Role that will be used. Optionally, you may need to attach the policy to a User that you can issue credentials to, but more on that later.
There are also some AWS built in policies that may be OK to use and attach to IAM users or roles. Depending on the AWS account and how it is structured, policies may need to be scoped down tighter than what default policies allow. For example, a built-in policy may allow all resources with a wildcard “*” instead of only applying to specific resources. For example, you have a specific Lambda function that you want to invoke, without being able to invoke other Lambda functions that exist in the same account.
AWS Best Practices Regarding Credentials
There are a few scenarios to consider when integrating with AWS services and resources.
It is common practice in AWS development to inherit credentials from the IAM role assigned to instance/container/function. These credentials are short lived and rotate automatically. Doing so will require an additional http header for the security token, in addition to access key id and secret access key.
It is also possible to make a call to the STS (Secure Token Service) to get temporary credentials scoped to what you need to do. This could be used to assume a role in the same or different AWS account, for example if your AWS Organization is structured into multiple accounts.
Instance Meta Data Service
Applications inherit IAM credentials from the instance (where FileMaker Server may be running) they reside on via Instance Meta Data Service, or IMDS. This is available only from a locally accessible address.
The initial version of IMDS allows for making http calls to the local endpoint, but IMDSv2 requires an extra step to get a token before allowing access. It is recommended that all instances make IMDSv2 required, to prevent third-party and external application vulnerabilities that could be used to try to access the IMDS.
From a FileMaker application, you can get access to those by using the “Perform Script On Server” script step to make a call to that local address to get those credentials and token. With those short lived and on-demand credentials, you can use them in your curl options used by AWS API calls. There is no need to store credentials in your application at all in this scenario, and access is scoped at the IAM policy. You could also get those directly from the Secure Token Service, which is where IMDS gets its tokens from.
IAM Users
While not preferred, there may be scenarios where you need to create an IAM user and issue credentials for your use. Examples might be standalone FileMaker files not hosted on a server, or not hosted on a server in an AWS environment, where you still need to interact with the AWS API. It is still possible to do that, but caution should be taken with those credentials.
There may be differing opinions on how to handle those credentials in a FileMaker solution. Those might include setting them in a script as variables or creating custom functions. Ideally, those credentials would not be part of the file or hard coded in a script, but this will depend on your application’s needs and requirements.
It may also be subject to compliance standards that need to be met. In those cases, credentials should not be hard coded and/or unencrypted. You may need to create a dedicated table and use FileMaker’s encryption functions to handle those use cases.
As a best practice, I would lean toward handing those in a dedicated table that could be secured, if it were required. Ideally, I would get the required credentials from the IMDS as stated above.
Again, this will depend on the use case and what exactly you are doing with your API integration and application. Under certain circumstances, this is an option to consider.
Microservices vs. curl options
There are also plenty of good reasons to use a microservice, such as several microservices that we have developed under the SideCar family in our hosting environment. Those reasons include not having to manage IAM credentials or confusing policies, where the developed infrastructure already has that thought out and provided for.
I must stress, using a supported SDK is much easier than trying to reverse engineer the proper curl options for all the services and actions in the AWS API. You can get much further, much faster with the better documented SDKs.
Some workflows are better suited to a webhook type of event, where queued messages get sent to a waiting server on demand instead of the need for continued polling to see if there are any messages in the queue.
There may also be longer lived processing, such as transcribing audio into text, where an event can occur upon completion and send notification back to the server at that time, rather than needing to keep checking with a polling script.
Another common example could be generating a pre-signed URL, since the “–aws-sigv4” flag will not help you. Generating a pre-signed URL with FileMaker may still be difficult without the “–write-out” flag supported as a curl option, whereas SDKs have methods built in for this kind of extended functionality.
It really comes down to the exact use case and knowing what to use and when. Knowing all the options and making the best choice is what Solutions Architects need to do when planning a project or deployment.
AWS Account vs. Service Access
AWS is a top tier cloud infrastructure provider and can be intimidating to properly architect in their environment. While it is easy to start, there are several best practices to consider when creating your own account, including properly setting up root and user accounts that will access the AWS account. Then you will want to set up some monitoring around what is running and manage billing, so it does not get out of control.
Your organization may also already have an AWS account. In such cases, you might need to be able get the resources created for you by internal IT. That may also come with its own challenges, as regulatory and governance requirements may dictate how you use those resources.
Of course, if you are not ready to manage your own account or have IT that is difficult to work with, using an MSP (Managed Service Provider) may be an option. Of course, our team of certified Solution Architects are always available to assist, should you need us. We can also host infrastructure along with our world class managed FileMaker hosting service that is already in AWS, Soliant.cloud.
Example with explanation
As a remarkably simple example, the following could be a calculation in FileMaker to set the curl options for an insert from URL script step.
" --request GET" &
" --aws-sigv4 \"aws:amz:{region}:{service}\"" &
" --user \"" & $aws.AccessKeyId & ":" & $aws.SecretAccessKey & "\"" &
Where {region} is the AWS region and {service} is the AWS hosted service being called. Those might be “us-east-1” and “s3” respectively, with the credentials referenced above. In that case, the URL to use might be the object URL of a file stored in s3, like “https://your_bucket_name.s3.amazonaws.com/object_name.png” for example. Simple, right? The “–aws-sigv4” flag takes care of generating the correct request headers for you. If you get your credentials from ISDM or STS (as outlined above) then you would also need to specify the “x-amz-security-token” header and value from there.
Note that when working with S3, this curl option can also work with S3 compatible services like Cloudflare R2 and Wasabi. While the resulting code required to perform some basic tasks can be minimal, it can be challenging to find the correct values to plug in to make API calls work as expected. There is decent documentation for AWS supported SDKs, but not as much for making direct API calls such as what you can do with curl. In some cases, you may have to dive into code used by their SDKs to find the correct options to include.
Takeaways
Hopefully, this points you in the right direction for your own development and planning. We would hope the FileMaker community embraces well architected principles and best practices. Just to review, here are some key points to keep in mind.
- Scope credentials for least privileged access
- Handle credentials responsibly
- Select the best development strategy depending on use case
- Properly configure AWS environment or use an MSP
We look forward to continued growth in this space and hope to continue to bring added value to the FileMaker platform by extending its capabilities with AWS cloud infrastructure and services.
Resources
- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html
- https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure/
- https://help.claris.com/en/pro-help/content/curl-options.html
- https://curl.se/docs/manpage.html
