AWS Authentication: New Features in the Connector Suite

Community action

Another outcome of the Mendix collaboration with AWS has been the wealth of knowledge and tools created to assist Mendix Makers and AWS Builders in their development journey. This enablement material includes blog posts, learning paths, informative videos, and example implementations. It also includes step-by-step guides, best practices, and practical insights in creating solutions with Mendix on AWS for those new to Mendix.

The Mendix community has been instrumental in shaping the content. They’ve provided feedback on the forum, created an environment for growth and innovation, and highlighted areas for improvement. The community has freely shared both their frustrations—such as having to configure the same credentials across different connectors to authenticate—and their ideas, like invoking custom endpoints and overriding HTTP time out configurations to extend the runtime of an AWS Lambda function. All this feedback is reflected in the recent update of the AWS Authentication Connector and elevates the developer experience with the broader AWS Connector Suite.

Upgrades and enhancements

Let’s dive deeper into the details of these changes. I’ll provide a comprehensive overview of the breaking changes, explain the deliberations, and discuss the impacts these changes may have on the workflow of a developer. Hopefully, these insights will lead to a smoother, more efficient development experience.

The updates and enhancements to the AWS Connector Suite go beyond technical upgrades. They enhance the development workflow when combining Mendix and AWS.

These changes will impact applications that use earlier versions of connectors. We’ll delve into what these changes entail and how you can smoothly transition to the new version.

Centralization of components

The most notable change is the centralization of authentication components, including connection detail constants and the microflow for generating a Credentials object. This change will cause errors in applications that have not been updated, as the authentication constants and microflows are no longer in the connector modules, but in the AWS Authentication Connector. These errors can be resolved by configuring the connection details constants and credential generation microflow located in the AWS Authentication Connector.

A request entity each

We’ve standardized all operations to include a request entity, irrespective of whether the operation previously had a request entity. This change brings consistency across the suite. When upgrading, errors may occur for the operations that previously did not have a request entity. To resolve these errors, simply add an instance of the newly introduced request entity to align with the update.

Inheritance from the AbstractRequest entity

This change builds on the introduction of request entities for every operation. We incorporated a new feature where all request entities now inherit from the AbstractRequest entity from the AWS Authentication Connector. This inheritance paves the way for the feature of overriding HTTP client configurations. While this modification aligns to standardize operations, it may cause errors during upgrades for operations that previously did not have a request entity. This shift, though it may necessitate making changes during the upgrade process, grants advanced control of the behavior of the connector’s operations.

Overhaul across the AWS Connectors Suite

Each connector in the suite has undergone an overhaul to ensure uniformity and consistency. It’s important to note that these updates will introduce breaking changes for every connector in the AWS Connectors Suite. The number of adjustments required will vary depending on the specific connector. Crucially, all upgraded connectors now have AWS Authentication Connector 3.0.0 as a prerequisite to align with the suite’s enhanced standards and capabilities.

Understanding these changes and the steps to migrate will ensure a smooth transition to the updated version. This will help Makers leverage the enhanced capabilities of the AWS Connector Suite.

Centralization across the AWS connectors suite

Another change is the centralization of components from across the entire AWS Connectors Suite to the AWS Authentication Connector, a module that is a prerequisite for all AWS connectors. Here are the key elements of that change.

AWS Region enumeration

Gone are the days of struggling to discern which module-specific region enumeration you had to select. The centralization of the AWS region enumeration now simplifies access to the list of all AWS service regions. We’ve expanded this list to include additional regions for broader integration options.

These added regions will ensure that the connectors are up to date with the latest AWS regions, providing developers with more options for the deployment of the AWS workflows. The new regions include:

• Asia Pacific – Hyderabad (ap_south_2)
• Asia Pacific – Melbourne (ap_southeast_4)
• Europe – Spain (eu_south_2)
• Europe – Zurich (eu_central_2)
• Israel – Tel Aviv (il_central_1)
• Middle East – UAE (me_central_1)
• AWS GovCloud – US-East (us_gov_east_1)
• AWS GovCloud – US-West (us_gov_west_1)

Authentication constants

We’ve centralized the connection details constants used in configuring AWS authentication, a change driven by community feedback. The community shared that having to configure multiple sets of constants creates unnecessary configuration overhead during development. The new update eradicates this by relocating these constants to the AWS Authentication Connector. This promotes the reusability of credentials while also retaining the possibility to configure multiple sets of credentials.

We’ve also reviewed the authentication workflow. We’ve removed the constant ‘UseStaticCredentials’, previously used for authentication. The new approach towards the Credentials entity is now more aligned with AWS’s practices.

Static authentication remains unchanged. However, for temporary authentication, we’ve introduced the TemporaryCredentials entity—a specialization of the Credentials object. This not only mirrors the AWS naming convention, but also establishes a clearer and improved separation of authentication concerns.

Furthermore, the AWS Connectors Suite has adopted the terminology ‘temporary credentials’ over the previously used ‘session-based credentials’. This terminology is more widely recognized and adopted within the AWS ecosystem. This approach embodies our commitment to staying in sync with AWS standards, enhancing the clarity and consistency of the connectors for Makers.

Out-of-the-box microflow to generate valid credentials

Previously, connector actions included logic for creating a Credentials object within the flow of the action itself. However, this approach has evolved, now requiring the Credentials object as an input parameter. This change, already adopted by newer connectors, enhances flexibility by allowing for customized credentials management.

In the latest update, we’ve standardized all connector actions to this approach. Consequently, every credentials-generating microflow that existed in each distinct AWS connector is now centralized in the AWS Authentication Connector as two distinct microflows for static and temporary authentication. This separation fosters more granular control, enabling developers to opt for static credentials for quick authentication during development or temporary credentials for secure, short-term access in production environments.

The centralization of these components into the AWS Authentication Connector module enhances reusability and efficiency, especially since each connector already requires the AWS Authentication Connector. This approach, driven by community feedback, addresses the pain point of managing duplicate sets of constants in projects with multiple AWS connectors and ensures a smoother, more unified development process.

Overriding HTTP client configurations

When developing the AWS Connectors Suite, we made use of the AWS Software Development Kit (SDK) instead of the native Mendix Call REST service activity. This approach prioritizes efficiency in handling AWS integrations. It eliminates the complexity of customizing HTTP headers and signing requests, as the SDK automates these tasks. Additionally, it offers built-in features like retry logic and throttling management. This foundation sets the stage for discussing overriding the SDK HTTP client configurations, granting developers more control over the behavior of the application.

Overriding the default configurations for the SDK’s HTTP client

To address challenges such as AWS Lambda functions timing out due to default HTTP client settings, we’ve introduced customizable HTTP client configurations. Each connector action has a request entity that inherits from the AbstractRequest entity. To override the default HTTP configurations, Makers set the attributes on an object of (sub)-type BasicClientConfig and associate it with the request prior to invoking the connector action.

Some use cases include:

• Extending the timeout settings to accommodate operations that might run longer, such as AWS Lambda functions.
• Customizing the retry mechanism to alter the behavior for how the client recovers from failed AWS service requests.
• Overriding invocation endpoints (required for use cases such as testing locally), integrating with a self-hosted instance of AWS service, and invoking VPC endpoints (private cloud).

These enhancements provide greater control and flexibility, enabling Makers to tailor the connectors to their specific application needs.

Transitioning from add-on to regular modules

Comments such as ‘What is an add-on module?’ and ‘Why can’t the connector module be found under Marketplace modules?’ are typical questions regarding the module type of some AWS connectors. An add-on module is a specialized component in Mendix that offers capabilities like IP protection and bundled dependencies, making them distinct from the standard modules. Let’s look at how we’ve leveraged the unique features of add-on modules in our development of the AWS Connector Suite.

Add-on modules

One year ago, we released the Amazon Polly Connector as an add-on module in a pilot phase. We aimed to assess the feasibility of deploying the entire suite as add-on modules. Add-on modules (with .mxmodule extension) bundle the connector’s dependencies together, making them ideal for avoiding library conflicts. However, with the introduction of Mendix’ managed dependencies feature in Mendix Studio Pro 10.3, this concern is no longer relevant.

The shift to regular modules

Thanks to the new dependency management capabilities, we’ve been able to complete the transition back to using regular modules. This shift not only simplifies the development process but also allows these connectors to serve as references for those looking to build AWS integrations.

Moving to regular modules opens broader possibilities for customization, aligning with our commitment to making Mendix the fastest and easiest platform for building apps on top of AWS.

Conclusion

In summary, this update to the AWS Connector Suite brings improvements in functionality and usability.

• The centralization of components into the AWS Authentication Connector streamlines the development process by reducing redundancy and enforcing the reusability of those components.
• The introduction of customizable HTTP client configurations offers enhanced control over AWS integrations, including aspects like extended timeout settings and customized retry mechanisms.
• The shift from add-on to regular modules simplifies development and broadens possibilities for customization and integration.

These enhancements collectively mark a significant stride in our ongoing effort to optimize the AWS integration experience. With these advancements in place, the Mendix community is better equipped to build robust, efficient, and scalable applications on AWS.

You might be wondering how you can help pave the way to making Mendix the fastest and easiest way to build applications on AWS. We’re always eager to hear your ideas, field your concerns, and support you in your development journey. We’re one message away! Reach out to us at [email protected], on the Mendix Community Slack in the #aws-general channel, or on the Mendix Forum.