Identity and access rules at the gateway, not in every API
Authenticate callers with OpenID Connect, LDAP, SAML, JWT or API keys at the gateway, require client certificates where you need them, and keep secrets masked by role. Every rule is a Plugin on a Route, and every change to it is recorded.
Every API checks its callers in its own way
Authentication, access rules and secrets end up written into each service, each in its own way, and nobody can say what a given client may do.
Authentication written into each service
Each team integrates the identity provider again, and the versions drift.
With G8Authentication runs on the Route with the provider you already run. The service receives an identified request and a Consumer name.
Secrets in configuration files
Client secrets and API keys sit in repositories and tickets.
With G8Secrets are stored on the engine, shown only to roles that manage the object, and masked in the audit log.
Rules that nobody reviews
Allow lists and CORS settings live in code that few people read.
With G8Each rule is a Plugin with a form. The catalog shows the Routes that use it, and every change is recorded with its values before and after.
Identity, access rules and certificates in one place
API Security runs on the same G8 engine clusters as API Gateway. Each control is a Plugin on a Route, a Service or a Consumer, managed from the console with roles and an audit log.
Verify callers with the provider you already run
OpenID Connect, LDAP, SAML, Keycloak, JWT, API keys or signed requests, and more than one method on the same Route. A client secret is shown only to roles that manage the Plugin.
- Your identity providerG8 connects to the identity provider or directory you already run.
- Mutual TLSA Certificate can require client certificates signed by the CA you provide, and skip the check for the paths you name.
Decide which clients get through
Allow or deny clients by IP address or CIDR range, by User-Agent or Referer, block requests by URI, set CORS rules, and restrict a Route to the Consumers or labels you choose.
- Labels from your identity provideracl can read labels from the claims an authentication Plugin identified, such as a team or a tenant.
- The status you chooseA refused client is answered with the code you set.
Refuse malformed requests before they reach the backend
Check request headers and bodies against a JSON Schema, or the whole request against your OpenAPI document, and answer a refused request with the status and message you choose.
- Say whyA refusal can name the parameter or property that failed.
- Skip what you mustSkip body, header, query or path validation on a Route that needs it.
Keep sensitive data out of your logs
data-mask removes or replaces headers, query arguments and body fields in the lines your logger Plugins write. Traffic Explorer masks authorization, cookie and apikey headers by default, and the fields you add.
- The logged copyThe backend receives the request as it was sent; only the record changes.
- Bodies behind their own permissionViewing a recorded body needs its own permission, and every view is written to the audit log.
A platform team that opens APIs to partners and internal apps
A typical setup, drawn to show how the parts fit together. It doesn’t describe a specific customer.
A platform team runs one gateway cluster per Environment. Internal applications sign in with OpenID Connect, partners present client certificates and API keys, and a security team reviews every rule.
Internal Routes get openid-connect against the company identity provider; partner Routes get key-auth and a Certificate that requires client certificates.
Each partner is a Consumer with an IP allow list and an acl label; a rate limit per Consumer sits beside them.
The security team holds the Viewer role in Production and reads the audit log; request records are masked before they are stored.