APIGEE API Onboarding

Program Objective

Molina Healthcare, a major healthcare provider and administrator in the US, has APIGEE as their API Management Platform. As part of their digital transformation effort, several APIs are to be onboarded onto APIGEE, therefore providing a centralized API ecosystem for their internal and external consumer (consuming applications). There are a variety of consumer applications which include, Web Portals, IVR, Mobile Apps etc.

The key objectives for this program are:

• Provide a centralized API management solution.
• Configure and Implement centralized security protocols in the APIGEE layer.
• Implement Traffic Monitoring, Logging and Caching policies for these APIs in the APIGEE layer.
• Develop robust analytics using API transaction data and metadata.
• Secure the backend APIs/data sources behind the APIGEE layer.

Environment

As part of this program, approximately 1,700 APIs will be onboarded onto the Apigee platform, thereby enabling the implementation of policies identified as required at the use case level.

All APIs are classified at an application level, namely:

• Public Website: APIs for Publicly available website of Molina Healthcare (www.molinahealthcare.com)
• EPortal: APIs for Self-Service Portal for Members and Providers
• IVR: APIs for Telephony system for Members and Providers
• CRM: Internal CRM application APIs
• Mobile: Mobile Application(s) related APIs

All the backend APIs are .NET based services which are hosted on Azure IaaS.

APIGEE has five environments—Dev, QA, UAT, Staging, and Production—and all APIs and related configurations will be promoted through these environments while maintaining environment-specific settings.

Program Execution

API Development Lifecycle is followed as part of executing this program under a waterfall (SDLC) methodology.

Requirements

Requirements are collected from each API/App owner. Since the APIs on the APIGEE layer primarily function as pass-throughs with various policies applied, the collected requirements are largely non-functional, focusing on areas such as security, logging, performance, traffic monitoring, caching, and monetization.

Design

OpenAPI Specification based design was followed as part of this program. All proxies were designed using Swagger 2.0 and the OpenAPI specs were leveraged for development to remain consistent.

 

Development

APIGEE Edge UI was used for initial development of the proxies. Additionally, Swagger Hub plugins for APIGEE development were leveraged to develop the proxies in an automated fashion directly from the OpenAPI specifications.

Testing

Unit and system integration testing were performed using POSTMAN. All aspects of security, logging, monitoring, and exception handling were covered during these two test cycles. Security scans were conducted using Fortify on Demand (FOD), and performance testing was carried out using JMeter.

Deployment

Integrated DevOps process was implemented to build and deploy the proxies through the value chain of APIGEE environments. APIGEETOOL was leveraged to implement DevOps process for both Continuous Integration and Continuous Deployment.

Program Key Deliverables

The following were the key deliverables addressed as part of this program:

• OpenAPI Specification (design) for ~1700 APIs.
• API Proxies for ~1700 APIs.
• Robust, Reusable and Configurable frameworks such as
  • Security Frameworks
  • Traffic Monitoring Frameworks
  • Logging Frameworks
  • Exception Handling Framework(s)

• Developing API Build accelerator using APIGEE Management APIs.
• End to End OpenID Connect and SAML Implementation using AZURE AD.
• APIGEE SSO into Edge UI.
• APIGEE CI and CD (DevOps) using Azure DevOps pipeline.
• Enabled and Published APIs onto Developer Portal.
• Mock APIs for all the ~1700 APIs.

 

Program Key Differentiators

There are several reusable frameworks and accelerators that are developed as part of the program delivery.

API Proxy Development Accelerator

• As part of this accelerator, the least common denominator design was analyzed and developed which could be applied to most of the APIs (current and future).
• This design enables the development of a base proxy that can be applied to any specific application API and customized with API-specific requirements and policies, such as security, monitoring, and logging.
• A script was developed that leverages Apigee Management APIs to build and deploy the base proxy with zero effort required from developers.
• This eliminates the need to develop an API from scratch, thereby significantly reducing development effort.

 

Reusable Security Frameworks

There are 4 security frameworks developed as part of this execution:

• OpenID Connect Framework
• OAuth 2.0 Framework
• SAML 2.0 Framework
• JWT Framework

All frameworks were designed as Shared Flows and utilize Azure AD as the external Identity Provider (IDP). They were developed using out-of-the-box Apigee policies such as ExtractVariables, AssignMessage, and others to streamline implementation and ensure consistency.

To manage security, Key-Value Maps (KVMs) are used to store encrypted credentials, while Trust Stores are leveraged to store certificates for SAML 2.0 frameworks. This architecture ensures secure handling of authentication and authorization across all frameworks.

Reusable Logging Framework

A fully configurable logging framework was developed, allowing defined data to be logged—via configuration—into external logging tools such as Splunk.

The following were considered for this framework:

• Design a logging framework within APIGEE.
• Decouple the design from the logging tool (SPLUNK) for future extensibility.
• Design the framework with a variable/configuration-based approach which will ensure APIs can have the flexibility to log any required metrics.
• Develop policies which can applied to the APIs.
• Develop a Shared Flow based approach which can be applied to any APIs without understanding the underlying implementation.
• All messaging will be logged in JSON format.

 

 

Logical Design of the Logging framework

Reusable Traffic Monitoring Framework

As part of this program, a robust traffic monitoring framework has been developed to provide a flexible and agile design for monitoring API traffic, allowing threshold values to be set and alerts to be defined at the API level.

The following were considered for this framework:

• Design a traffic monitoring framework within APIGEE.
• Decouple the design from the alert mechanism.
• Decouple the design from the threshold values being set at each API level.
• Design the framework with a variable/configuration-based approach which will ensure APIs can have the flexibility to send alerts for different thresholds (both API hit count and time counter).
• Develop policies which can be applied to the APIs.
• Develop a Shared Flow based approach which can be applied to any APIs without understanding the underlying implementation.

Logical Design of the Traffic Monitoring framework

Program Benefits

Several benefits are derived from the program delivery approach and the associated deliverables:

• A centralized API management solution for maintenance and scalability.
• Centralized security management for the APIs.
• Secured the backend APIs and data sources behind APIGEE.
• Enhanced security using the latest industry-standard advanced security protocols.
• Mock APIs to accelerate and guide the consumer application development and testing.
• Developer Portal to end to end engagement with the API consumers.
• Reusable and Configurable frameworks which reduce the API development time by 75%.
• Logging Management into external logging tools for enhanced API monitoring and security.

Program Retrospective

During the execution of this program, we have identified several key considerations that must be considered, such as:

• Connectivity between APIGEE Servers and App Servers: Ensuring appropriate level of network connectivity and SSL implementation between communicating servers is established and maintained.
• On-Premise to Azure Connectivity: Ensuring network is established and maintained between On-Premise application environments and Azure APIGEE environments.
• Connectivity to external services: Several APIs had internal calls to services which were outside Molina network. Ensured these were identified in a timely fashion to address schedule issues.
• Mock APIs: In the absence of backend services availability, developed Mock APIs which can be leveraged and enabled development progress for the consumers.