Cloud Front Door

The OpenMethods cloud is comprised of several services that provide various web-based user interfaces and APIs. There are also multiple versions of these services as customers are not always on the same version of our software. Today these services are accessed using URLs that identify the service and version in the domain name. Although this system works in general, it causes issues for customers that whitelist all external URLs for security purposes. When a security conscious customer is upgraded to a new version of our platform, the list of URLs to whitelist must be changed and updated. This can include lengthy security reviews and delay the upgrade as the whitelist changes can take several days to be performed.

Adding a true front door to the OpenMethods cloud is designed to eliminate the need to update a customer’s whitelist. The only exception would be in the case a new service is created. The front door will be implemented in multiple phases beginning in 6.5 and being completed with the roll-out of 7.0. 6.5+ will provide a single domain naming convention for all services and standardize the whitelist required of customers. 6.5+ will still require some services to be upgraded for all customers simultaneously but will not require changes to whitelisting. 7.0 will include a centralized authentication service and formalization of the Customer and Deployment records. These features allow all existing services to be upgraded on a customer by customer basis.

There are 2 types of resources that need a front door. The services that are shared between multiple customers and their deployments, such as App Manager and Config Server, require an approach that handles changing versions. The tenant specific services like HIS and Queue Adapter need a different solution that not only supports changing versions but also allows scaling the number of endpoints based on usage and upgrade scenarios.

Shared (per shard) Resource Location

Each shared resource will have a dedicated application load balancer created. For example, the App Manager service in the dev shard load balancer will serve URLs with the domain name apps.dev.openmethodscloud.com. The different versions of app manager deployed in the dev shard will be available through a URL that looks like https://apps.dev.openmethodscloud.com/[version]. To support this approach, a path based rule is created for each version that delivers the traffic to the associated App Manager version beanstalk’s scale group. A customer would only need to white list apps.dev.openmethodscloud.com even as the underlying service version is changed. This approach will work for:

App Manager - apps.[shard.]openmethodscloud.com
PopFlow Designer - pfdesign.[shard.]openmethodscloud.com
PopFlow Data API - pfdata.[shard.]openmethodscloud.com
Config Server - config.[shard.]openmethodscloud.com
Connect API - connect.[shard.]openmethodscloud.com
MediaBar - mediabar.[shard.]openmethodscloud.com

The initial front door implementation in 6.5 still requires App Manager to be updated for all customers at once. The https://apps.dev.openmethodscloud.com/6.5.0 rule will be present but the URL https://apps.dev.openmethodscloud.com/ will also be directed to the 6.5 version of App Manager. This is because App Manager will still handle authentication in the 6.5 release. When 7.0 is released including the new Authentication service, the URL https://apps.dev.openmethodscloud.com/7.0.0 will be deployed and customers will be moved to this new endpoint as they upgrade to 7.0.

HIS & Queue Adapter

Each customer deployment with telephony services enabled will have an application load balancer created. The load balancer will service harmony-[some_unique_id].[shard.]openmethodscloud.com. The unique identifier is used to link this load balancer and host name to a specific customer deployment. The short id of the shard that hosts the customer deployment is used when not referring to the general population shard. For HIS, a path based rule is created for /hisselect that delivers requests to the auto scale group for the HIS selection service of the Harmony version associated with the customer deployment. For each HIS instance configured for the customer deployment a path based rule is created in the form of /[instance-id]/* and directs traffic to the the associated HIS instance. When in cloud mode, the MediaBar sends the list of his endpoints it receives from config server as a POST to /hisselect. The selection service performs the normal HIS selection process and returns the client id, any service ids that were bound, and the /[instance-id]/ path associated with the selected HIS endpoint. The MediaBar then continues communication with HIS normally using the provided client id and path.

Queue Adapter endpoints will also be fronted by the service load balancer. Each Queue Adapter for a customer deployment will have a path based rule created in the form of /[instance-id]/* and directs traffic to the Queue Adapter instance. The configuration for Queue Adapter in Config Server will make this path information available to the Media Bar. The Media Bar would perform normal Queue Adapter selection as it does today.

Each customer deployment has its own service load balancer due to the 100 rule limit for application load balancers in AWS. Although this limit can be increased, it will be easier for the implementation team to keep track of if each service front door handles a single customer deployment and all but eliminates the possibility that a customer will have to add an additional whitelist entry if they expand the use of our product.

Required Product Changes

There are several product changes that have to be made to support both the initial and secondary front door implementation:

All services must support configuration of a context path for UI and API endpoints. The context path is an additional path element in the URL which in this case identifies the version of service or service id, e.g apps.dev.openmethodscloud.com/6.5.0
UI html and javascript must use relative paths for all internal references of documents and APIs as the context path will not be known at build time
All services must not use the domain name to determine any information about a request other than the shard associated with the request
Service UIs other than App Manager that are accessed directly prior to user login should display an error page to the user instead of redirecting to the App Manager login page. This is to avoid the incorrect selection of the App Manager service and to train users for the upcoming centralized authentication service. We do not want customers to interact with our cloud in any way without first going through the login process
The deployment of applications into elastic beanstalk must also update the appropriate load balancer rules