🛠 WSO2 MI/ APIM from an AppSec point of view
Salute,
It was a bit stuffy last week,
I hope I’m the only one who experienced this, and the memes were useful for you, sometimes you need to melt your brain 🙃
Often in practice and when researching integration cases, I look towards WSO2, since the days of RB, so now I want to tell you why this solution has an advantage. WSO2 is always perceived as just another ESB and API gateway, but for a secure architecture it is a cool layer between the external and internal segment of the network.
Micro Integrator is responsible for integration and data exchange (you can add authentication, authorization, WS‑Security, encryption, logging and transformation of traffic before it gets into business services), and API Manager for publishing and protection, access control, traffic and developers (in fact, the border for all HTTP/ REST/ gRPC API with OAuth2/ OIDC, JWT, rate‑limit and etc.).
The feature for AppSec is that Security policies are like a configuration, not a code. Passwords, certificates, signature/encryption and authentication rules are formalized as policies and MI/APIM artifacts, versioned and code-reviewed as part of the infrastructure code. AppSec Toolchain scans both the API layer and integration services in MI. That is, MI/APM logs go to SIEM, where it is possible to build a correlation between vulnerabilities and real traffic. Zero-trust approach at the integration level.
Key features
• Authentication and authorization at the integration level - you can check username, token, roles and rights before accessing the backend, including through WS‑Security
• Encryption and signing of SOAP/WS messages, up to 16 typical WS‑Security scenarios (sign, encrypt, username token, X.509 and their combinations)
• Encryption and management of secrets via keystore/truststore - protection of SSL/mutual TLS, keys and passwords, refusal of default storages
• Data validation and sanitizing: checking XSD/JSON schemas, filtering fields, cutting out sensitive data before logging
• Centralization of integration policies
A typical circuit that protects the entire flow of API calls through common policies
• Clients/partners are knocking via WSO2 APIM
• APIM authenticates the request depending on the policy, validates tokens, applies throttling, IP filters, CORS, etc.
• The request goes to a microservice, or to WSO2 MI, where integration flows are executed: routing, enrichment, transformation, system calls
• The MI layer includes WS‑Security, message signing and encryption, additional authentication/authorization, schema verification, and payload validation.
• All events go to logs, and metrics and errors go to APIM analytics and platform monitoring
Total
• WSO2 as a way to bring security and integration into a single managed layer
• Single perimeter for APIs and integrations
• Fewer application vulnerabilities
• Teams focus on business logic, and typical integration and security problems are solved with ready-made WSO2 MI/APIM features; new integrations are added by configuration, not by custom code
• Out of the box there is call tracing, metrics, logging and API analytics
• WSO2 is tailored for scenarios where there is a cloud, on-prem, microservices, and old SOAP systems
Footnote
• ESB (Enterprise Service Bus) is an integration bus, that is, a centralized software layer that connects heterogeneous applications and services, taking on the routing, transformation and security of messages between them.
• API Gateway - a single entry point for API clients, a reverse proxy in front of the backend set, which accepts requests, routes them to services, aggregates responses and simultaneously implements security policies (authentication, authorization, rate limiting, monitoring)
#appsec #pmicases #devsecops #techsolution #reco #toolchain