# APIs Under the Hood
source: https://developer.mastercard.com/blog/apis-under-the-hood/index.md

Authors: Steve Fitzgerald. Summary Building a dynamic routing and discovery framework in-house at Mastercard Providing a robust security framework for APIs at Mastercard Evolving along with industry best practices Mastercard Developers is our shop front. It's where the world goes to discover what Mastercard APIs are available to use and how you would go about using them. But let's peel back the covers and take a look at how we manage some of our APIs internally from a platform perspective. In the early quarters of 2015, a small team of engineers started to think about how to effectively enable secure, distributed and dynamic API routing and discovery within Mastercard. Up until then, Mastercard had been doing secure API routing and discovery albeit in a very centralized and static way with the use of an enterprise service bus. That model didn't quite fit with Mastercard's future vision of publishing and consuming APIs or for the Cloud Native journey it was about to embark on. The birth of Synapse When we started building our service discovery framework we didn't have a cool and catchy name for it. We came to call our framework Synapse. syn.apse /'sin.aps'/ noun a junction between two nerve cells, consisting of a minute gap across which impulses pass by diffusion of a neurotransmitter. Imagine that our new cloud-native API architectures are the nervous system driving Mastercard. Each API is a different cell within that nervous system and Synapse is the thing that allows those APIs/Cells to communicate with each other. At the time the service routing and discovery space was still very much in its infancy. Netflix seemed to be leading the charge by pioneering these techniques and open sourcing a lot of the tools they had developed in-house for tackling some of the problems you face when trying to implement distributed, scalable and fault-tolerant systems. Naturally, we leaned heavily on the teachings of the good people at Netflix while we were imagining what Synapse would be. With what we learned from Netflix and other research we did we set about creating Synapse while always keeping some core tenets in mind: Distributed dynamic routing Client-side load balancing Fault tolerance to allow failover or fallback to greatly reduce client-side errors A new security framework allowing group control over service consumption Synapse Architecture Mastercard is predominantly a Java shop so we chose to concentrate our efforts on creating a solution using mainly Java-based SDKs. This meant that the Synapse framework could be used no matter what type of Java application you were. At present, for routing and discovery, Synapse consists of a number of components.All of these components, with the exception of Zookeeper, were designed and build in-house at Mastercard.They are as follows: Apache Zookeeper - Somewhere to store information about each published instance of an API Locus SDK - An SDK for publishing an instance of an API Prism SDK - An SDK specifically for discovery and consuming other APIs published using the Locus SDK Aker Edge Proxy - This is a proxy that allows us to transition calls coming from sources external to Mastercard's network into the Synapse framework With so few components we can provide completely dynamic and flexible routing of API traffic in both East-West and North-South directions. Here are some helpful diagrams so we can try to better understand the two different flows. East West The API adds the Locus SDK as a dependency. Once the API instance starts the Locus SDK handles health checking and registration of the API Instance with the Zookeeper repository The Consumer App wants to consume the API. It adds the Prism SDK and constructs a request targeted at the API. When the call is executed Prism first makes a call to Zookeeper to discover all the registered instances of the API. It then takes the information from Zookeeper and configures a client-side software-based load balancer within the consuming app and then chooses a server to send the request to The Prism SDK then issues the HTTP request directly to the backend API North South The API adds the Locus SDK as a dependency. Once the API instance starts the Locus SDK handles health checking and registration of the API Instance with the Zookeeper repository A call coming from outside of the Mastercard network gets authenticated and authorized by a perimeter device The perimeter device then forwards the call to the Synapse Aker Edge proxy. Aker dynamically provisions an endpoint for any API that is registered with the Synapse framework Aker implements the Prism SDK and discovers and configures a client-side load balancer per API The Prism SDK in Aker then issues the HTTP request directly to the backend API API Security When thinking about securing API to API calls we made a conscious decision to seamlessly integrate the security framework with the routing and discover framework components. So working closely with our compadres from our Corporate Security department we went about creating a security architecture based on declarative policies that would allow API teams secure their APIs all the way down to the HTTP method used on a specific resource on their API. The exact details around the inner workings of the security framework are probably a subject for a different blog post. But for now, I will give a brief description of how the security framework ties in seamlessly with the routing and discovery work we talked about above. Firstly we are introducing a number of new components into the flow. All of which were designed and developed in-house in Mastercard. They are as follows: Policy Administration Point (PAP) - This is where the declarative policy for an APIs security gets stored. A number of components then can retrieve the policies they need from the PAP at runtime. Policy Decision Point (PDP) - This is where a consumer application can ask to be granted a bearer token that is can use to call an API. The PDP makes a decision based on a number of factors, that include the declarative policy, whether or not to grant a token for the consumer to call the API or not. Policy Enforcement Point (PEP) - This is an HTTP filter that sits in front of all APIs that are secured using this security framework. Its job is to inspect the bearer token in the incoming request and grant or deny access for the call to continue. PDP retrieves all available security policies from PAP and stored them in a distributed cache shared between all PDP nodes so it is able to make decisions quickly as retrieval of specific policies is done out of band When an instance of an API starts up it places the PEP at the forefront of its filter chain. The PEP retrieves the policy associated with the API and configures itself to validate incoming traffic based on that policy As above the Locus SDK handles registering the API so it can be discovered by other consumer application When a consumer application comes along and wants to make a call to a secured API it follows the exact same steps as above. But now the Prism SDK is going to perform an additional step which is to call the PDP to get a token for the request it is about to make. When a token is received it is cached locally in Prism and can be used for subsequent requests to the same API endpoint. The tokens expire after 15 minutes so they will be invalidated in Prism's cache and Prism will handle refreshing the tokens for the consumer application Once the Prism SDK has received a token from PDP it then discovers the instances of the API as above The Prism SDK injects the bearer token into the Authorization header of the HTTP request being sent to the API. The PEP then intercepts the call and interrogates the token so it can either allow or deny access The Future of Synapse Synapse currently only supports Java based applications and the application teams need to do some work to reap the benefits that the framework provides. That work entails adding our SDKs as dependencies to their application and configuring them correctly. These facts make our next steps for Synapse very clear. We need to evolve Synapse into something that is going to be completely transparent to application teams. Something that is just baked into the platforms that application teams are deploying their application to. Something that is just there doing important work for application teams without the need for the application teams to know anything about it. Mastercard is now in the process of standing up platforms like Pivotal Cloud Foundry and Kubernetes both on-prem and in the cloud. These platforms are going to provide us the ability to fully realize our future vision for Synapse and allow us to provide all the same capabilities that I have described in this post in a completely transparent way.