The Case for API Gateway Self Service
Published: June 1, 2023
Your API GW (or Gateways) are hard at work in your organization, securely sharing APIs or services to B2B or B2C or B2E consumers deployed in public/private/hybrid cloud models throughout the organization.
Likely, you have administration and/or operations teams managing operational aspects of the API Gateway. Typically they’ll be working to expose new API services, and ensure things are up and running. Someone, somewhere, however, is also having to administer the Gateway. This means onboarding new applications, granting contracts, setting up and sharing credentials, changing contact and operational information, and sharing details about the APIs exposed via the Gateway.
But what about self serve? Which of these kinds of activities might you want to offer self service for, and what kinds of benefits might this offer?
Administrative Tasks
In dealing with an application profile that’s authenticating to APIs, there are a number of basic administrative tasks. Resetting credentials, looking up API information, setting up and managing other application attributes, even contact information for partner details. Managing these takes time for your team, time probably better spent exposing new business value. Administering partners and their profiles can represent almost a full time job for someone, and is certainly a distraction for anyone that can do it as part of their other work. The tendency is for people to neglect administrative updates to things like contact information if they’re busy doing other things. Self serve operations for these items helps application owners and partners manage some of the basics themselves.
Service Catalogue & Documentation
A lot of questions that come to API Gateway teams are about the shared APIs themselves. While the API Gateway team may not be responsible for the services exposed on the platform, they are the first port of call for developers trying to integrate. Questions about URLs, service names, operations supported, who to contact about an API, and indeed documentation for the full service, are common. A well built catalogue in your self service portal for the Gateway can head off a lot of these questions before they bother your team. While this might not seem like it, service catalogue and even documentation repositories, or links to them, are a key aspect of enabling self service.
Delegated Authority & Time to Onboard
Self service doesn’t just extend to the applications that connect to your gateway. Self serve can be extended to roles in more authority, who can grant access to services/APIs, add and remove individuals to administer groups of partners or application profiles, or even remove people from the platform.
Delegating authority allows for people who are best positioned to understand the particular business and security case for API access to grant services to the right application. Often these people are motivated to keep projects or initiatives moving and need to get the work done as part of their role. Removing your team as a middle man can help speed everything up and offload work. This speeds up time to delivery and getting to realizing the business benefits your projects represent.
For one of our clients, a robust self serve system that we helped design and build meant that a project team within the organization was able to onboard and setup over 4,000 applications in just a couple of years. Previous to these tools, that would have been a significant amount of work for the existing operations team and likely insurmountable. In fact, the team that was delegated the administration role extended their group to several people to help with the entire process, which involved more than just onboarding to the gateway, but some custom setup for the services too. This team was already planning to do much of this work, and a shared well built API Gateway gave them the tools to do this work themselves without interrupting the development of further gateway tools to other clients.
There’s even a role for delegating authority to the API or service owners themselves. Who better to authorize and support people trying to integrate to an API than the team who built and owns the service in question? This is another role we’ve found has benefited from some delegated control of seeing who is calling their API, and updating operational information in the service catalogue for how to reach out when clients are experiencing an issue with their API.
Integration Services
When developers start to onboard client side applications to API Gateways, they typically want to test out integration and connectivity. Does my code call your API Gateway correctly, do I have routing access to the main endpoint(s), am I passing credentials or tokens correctly? Having teams do this last minute against real services makes things more confusing. An alternative to this is to have some simple ‘sandbox’ or ‘mock’ services accessible via the Gateway. These dummy services can be granted to anyone and everyone at extremely low risk, and provide an ideal way for a customer to work through integration while your team gets on with solving the harder problems.
Security & Reliability
It’s hard not to mention the security benefits of self services. It might sound contradictory, but having a partner development team in charge of their own credentials means their application is more secure because credentials are not being shared across organizations. Traditionally, a lot of the communication with partner developers or employees and the API Gateway team occurs through clear text email exchanges. Even a ticketing system means extra place credentials are stored which they don’t need to be. Allowing the application owner to acquire, encrypt, and store application credentials (username and credentials) means fewer people handling those sensitive credentials.
Offering self-service credential management can mitigate the risk of a service outage. If your layered API Gateway security architecture uses expiring credentials (i.e. client TLS/SSL certificates), then enabling your customer teams to renew the certificates at their convenience and schedule is preferred versus emailing your API Gateway team with a request, and your team filling that request not in the timeline needed by the customer. Believe it I have seen this happen. It also reduces the risk of clicking around to update credentials or renew certificates, whereby ‘fat finger’ the wrong application profile and break someone else’s integration to the platform by mistake.
API Self Service – Even More Automated Security!
The icing on the cake is when your API Gateway exposes an API to allow applications to administer themselves. That’s right, having an API Gateway expose an API to enable a business service – what a concept! What a self service API for application credentials means is that client side applications can roll their own. Encouraging and having applications that are consuming services in your Gateway, automatically call APIs to reset their own credentials on a regular basis improves security greatly. Firstly, this means that no human needs to be involved in handling credentials at all. Secondly, it means application credentials can be changed by software on a regular basis, so if someone does compromise them, they become effectively useless quickly. While authentication patterns such as OAuth help with reducing the frequency that credentials are passed around, they still rely on some form of authentication somewhere. Imagine having an application that not only uses temporary tokens for every request, but when retrieving these tokens the credentials are only used one before being discarded for fresh ones!
In summary, self service in API Gateways has real value in terms of cost savings, security, reliability and customer experience benefits. If your API Gateway doesn’t have these features, I would encourage you to add to your feature list roadmap.
