Case Study

GSMA

How GSMA Accelerated Open Gateway Innovation with Microcks and Keycloak

GSMA leads the Open Gateway initiative, which standardizes telecom network capabilities through CAMARA APIs. The initiative aims to provide developers and the broader ecosystem worldwide with standardized access to mobile network services, including SIM swap detection, number verification, and device location.

By leveraging Microcks and Keycloak, the team reduced development time by months, enabled 100% mock-driven API testing, and created a zero-risk environment for developers to experiment with telecom capabilities at scale.

Challenge: Breaking Down Barriers to Telecom API Adoption

GSMA faced a fundamental challenge: telecom APIs are powerful but difficult to access, test, and standardize across operators.

Developers required a way to safely experiment with security-sensitive network APIs and test realistic behavior without live operator networks. This enabled them to validate interoperability across multiple operators and support complex authentication flows like CIBA and JWT bearer, all while keeping up with the rapidly evolving CAMARA specifications.

Building this environment traditionally would have been prohibitively expensive and slow because each API required custom backend development and authentication flows needed bespoke security implementations. Furthermore, updates introduced ongoing operational overhead, and existing commercial sandboxes remained limited, gated, or costly.

Without a better approach, GSMA risked slow time-to-market, a fragmented developer experience, and high infrastructure and engineering costs.

Solution: A Cloud Native Sandbox Built for Scale and Simplicity

GSMA selected Microcks and Keycloak to design a fully cloud native sandbox that removes these barriers.

Architecture Highlights

The architecture is powered by Microcks for API mocking and contract validation, while Keycloak delivers identity, authentication, and authorization. A Spring Cloud API Gateway provides a unified entry point for routing, security, scope validation, and CORS. Every service ships as a standards-compliant OCI container image stored in Amazon ECR, hosted on AWS ECS Fargate for serverless container orchestration automated via CloudFormation. Persistence for Keycloak state is managed by AWS RDS PostgreSQL, with the entire AWS VPC deployment ensuring isolation, scalability, and control.

The same OCI images run unmodified under Docker Compose locally and under ECS Fargate in production and can be redeployed to any Kubernetes distribution (EKS, GKE, AKS, k3s) without changes. ECS Fargate was selected to minimize operational overhead for a small platform team while keeping all workloads portable.

This architecture enables a self-service developer playground where users can explore APIs without production dependencies.

An image of the Open Gateway Sandbox

A Standards-First, Spec-Driven Workflow

The sandbox sits at the intersection of three Linux Foundation initiatives: it implements CAMARA APIs, is driven by OpenAPI 3 contracts, and is powered by the CNCF Incubating projects Microcks and Keycloak.

All CAMARA APIs are defined as OpenAPI contracts, version-controlled in Git alongside example payloads and metadata. Microcks consumes these specs directly; there are no hand-written mock servers and no drift between spec and runtime behavior. When a CAMARA specification is updated, the new mock is deployed by re-importing the YAML.

Flow chart image of the set up

Why Microcks and Keycloak

Microcks: Mock-Driven API Innovation

Microcks became the core engine for API simulation by mocking CAMARA APIs with realistic request/response behavior and enforcing OpenAPI contract compliance. It provides deterministic and repeatable testing through dynamic, request-aware responses configured declaratively without writing a backend, enabling rapid API updates as specifications evolve.

This eliminated the need for backend implementations during early development phases.

Keycloak: Production-Grade Security Without Complexity

Keycloak provided out-of-the-box identity and access management with full support for OAuth 2.0 and OpenID Connect flows, including advanced flows like CIBA and JWT bearer. It also allowed for customization of CAMARA-specific login hints and logic, ensuring consistent token issuance and validation across all APIs.

Together, these technologies created a secure, standards-based environment without heavy engineering investment.

Observability and Operations

Each internal service exposes Prometheus-compatible metrics endpoints via Spring Boot Actuator and Micrometer, ready for ingestion by Prometheus or any OpenMetrics-compatible monitoring system. Runtime container logs are aggregated to Amazon CloudWatch. AWS Systems Manager Session Manager provides zero-inbound-port administrative access with no SSH and no bastion hosts.

A Concrete Developer Flow

A typical end-to-end interaction:

  1. A developer authenticates via Keycloak using one of the supported OAuth 2.0 / CIBA flows
  2. Keycloak issues a JWT with the relevant CAMARA scopes 
  3. The developer calls a CAMARA endpoint through Spring Cloud API Gateway
  4. The gateway validates JWT scopes against the route’s required scopes, then forwards to Microcks
  5. Microcks returns a contract-validated response drawn from the OpenAPI examples

No backend integrations, no operator network calls, no production risk.

Flow chart 3

From Months to Days: Measurable Impact

GSMA achieved significant improvements across development speed, cost, and scalability.

Industry:
Cloud Type:
Published:
November 2, 2026

Projects used

By the numbers

20+ CAMARA APIs

planned in the sandbox

100% mock-driven API coverage

with contract validation

~5 months

total development time saved annually

Unlocking a New Developer Experience

The sandbox fundamentally changes how developers interact with telecom APIs by removing long approval processes and paywalls, providing immediate access to all CAMARA APIs in one place. This allows for safe experimentation without operational risk and the ability to validate use cases before production.

This reduces onboarding friction and accelerates innovation across:

Lessons Learned

GSMA’s journey highlights several key takeaways for organizations adopting cloud native technologies:

Most importantly, cloud native technologies allowed GSMA to focus on innovation rather than infrastructure.

Future Plans

GSMA is continuing to expand the platform and ecosystem:

The sandbox also serves as a repeatable model for other industries looking to standardize and democratize complex APIs.

Conclusion

By adopting Microcks and Keycloak, GSMA transformed a complex, high-cost problem into a scalable, developer-friendly platform.

The result is more than a sandbox; it’s a foundation for global telecom innovation, powered by cloud native technologies.