An Architecture Pattern for Digital Integration

This article explores a typical solution architecture for a digital integration scenario where a user performs a transaction on a mobile app, that is processed by a Microservice hosted on a Public Cloud, through fetching and updating of data from on premise systems, and then response is rendered to the user on the mobile app.

Enterprises have a Mobile Device Management and Mobile Application Management solution like Microsoft Intune that allow them to manage devices and mobile apps accessing the corporate network. This is typically a cloud-based solution that manages the mobile devices and mobile apps as per the security policies defined by the enterprise, makes updates to provide protection against potential threats and provides security to corporate data.

Mobile apps developed for an enterprise’s business functions are typically integrated with an Identity Management Solution like Azure Active Directory. A user has to first authenticate against such an Identity Management solution before he can perform functions with the app. Once the device and the user is authenticated to use the app, various functions can be performed. Each function is associated with a specific business need which is implemented through a Microservice that is hosted on a Public Cloud. Internet traffic from the app can communicate securely with the Microservices in the Public Cloud through REST APIs using a token-based Access Management solution.

In this particular example, the user logs in to the mobile app, gets authenticated against the Azure Active Directory, which in turn returns a JSON Web Token Access Token. The app calls an API, based on the functionality requested by the user, and passes the JWT token in the Request header. The API authorizes the Request based on the token and triggers a Microservice to perform a set of specific actions, specified by the scope that was granted during authorization.

In our example, the corporate network has two segments, a DMZ and a private network. The applications in the DMZ are external facing applications that do not communicate with applications in the Data Center.

Firewall 1 filters traffic from the internet that can access the applications in the DMZ.

The applications in the private network do not accept internet traffic and can communicate with the applications in the Data Center over an API Management Platform, which is also in the private network.

Firewall 2 blocks all traffic from the internet except those that comes through the DMZ Gateway.

Thus, the Microservice in the Public Cloud has to first authenticate against the DMZ Gateway before it can access the API Management Platform. This is done through the JWT token that is passed across from the mobile app. The Microservice makes an API call, gets authenticated at the DMZ Gateway, reaches the API Management Platform that triggers the corresponding API, which in turn accesses the resource located at a system in the Data Center, fetches the requested data and sends them back to the Microservice and render the information in the mobile app through the same secure tunnel.

The API Management platform provides an extra layer of security for the APIs that expose the resources in the systems at the Data Center. It also does user conversion if any of the backend systems have a user authentication mechanism that is different from the user credentials passed in the JWT token.

Single Sign On is implemented in the whole process through the JWT token which is passed from one component to another starting from the mobile app to the backend system.