4 posts tagged with "APIs"

We recently had an issue where an OpenZiti network was overwhelmed with client requests when a user change unintentionally caused the request rate to spike. The fundamental problem was that if a request took too long, the client gave up, but the request was still processed. The system ended up doing work that was ignored while causing new requests to wait until they also timed out. Once the requests hit a certain threshold the system didn't degrade gracefully.

I had a fun day solving the problem, and while I'm sure that nothing here is new, I thought others might be interested in where I landed and some ideas that were rejected along the way.

With the first version of ngx_ziti_module, it is possible to take an NGINX-exposed Web API and make it completely dark. This means no open ports in NGINX, and it brings the Zero Trust capabilities of OpenZiti to any NGINX deployment. Yes, replace open ports with open source! OpenZiti works in existing applications or new ones.

In the OpenZiti project, we have created an overlay network that makes network services dark. Part of that system is authenticating devices and users before they connect. The challenge is that most companies already have methods to authenticate human users and hardware devices. The challenge we faced with OpenZiti was to provide ways to integrate both users and devices through external Identity Providers (IdP). Our solution was to allow two of the fundamental building blocks of modern authentication systems to be validated by OpenZiti: x509 certificates and JWTs.

In the late 2000s, I was a software engineer in the telecom industry, working on large data pipelines that would aggregate billing data from any carrier. The older the carrier, the more likely we would write a web scrapper to automate data retrieval. The new carriers had Web APIs. It was exciting and abundantly clear that these servers were exposed publicly on the internet.