Architecture Recommendations

When building a solution empowered by Ability Platform, you need to make sure that your set of applications integrates with Ability Platform properly in order to be efficient for the end users. We've prepared a set of recommendations to help you with that. Follow these to get the most our of your Ability-based solution.

Use own API Gateway service between your apps and Ability APIs

If you plan to build applications that will run on your clients' machines, do not connect these applications with Ability Platform APIs directly. Instead, set up your own API Gateway service that will act as a proxy between your application and the Ability Platform.

Here's why this recommendation is valid and important:

• when you "own" the API that your client apps are using, it's easier for you to adjust to potential changes in the Ability API contracts. Whenevr such a change occurs, you will need to update just the cloud-hosted API, and not the client apps that might be running on-premise.
• exposing the Platform API endpoints to the public is not desired
• you can expose a subset of Platform functionalities (API endpoints) to your client applications via your gateway
• you can incorporate Backend for Frontend pattern and shape your own API so that your contract is more related to your actual solution. Ability Platform APIs are very generic (on purpose) - your applications will benefit from having a higher abstraction level of communicaton than what Platform offers. To put it in a simple example
• your client apps should work with actual equipment (motors, power lines, whatever), and not type definitions, or object models.

VNet Peering

In most cases, this recommendation is actually a must due to the fact that Ability Platform APIs are "hidden" behind a virtual network (VNet). To access it, you need to have your application's backend connected to that VNet (indirectly) using VNet Peering. You can read more about it here.

Use Web Application Firewall

According to MCSR, your public facing APIs (like the "proxy" that we talked about previously), have to be protected by WAF (Web Application Firewall). It ensures that your APIs are protected from being exploited by some commonly known vulnerabilities. You can read more about WAF on MSDN.

Use MFA

Multi-Factor Authentication (MFA) is a standard nowadays. All your client-facing applciations should use it according to IS corporate mandate. Make sure that the Identity Provider (i.e., Azure Active Directory) you're about to use provides this capability.

Use proper authorization flow

Access to Ability Platform APIs is secured using industry standard OAuth 2.0. Make sure that your applications use proper flows of OAuth 2.0. In particular, we advice agains using the Implicit flow, which is nowadays considered as not suitable authorization method (more on that on MSDN). Follow this to learn more about authorization flows in Ability Platform.