Govern the Entry to the Service

A policy appears in API Manager, yet a request without credentials still reaches the order flow. The policy listing alone cannot tell us whether the request used the intended deployment, API instance and entry path.

Governance starts by connecting those identities. The contract describes the API; an API instance represents a managed occurrence; the deployed implementation receives traffic. Their names can resemble one another while pointing to different things — and a policy that exists in the control plane has protected nothing until a request has actually crossed a gateway that applied it.

Review the policy boundary from ACB

Open the companion folder in ACB Explorer, then open book/platform/policies/orders-policy-plan.yaml. Keep the worksheet beside book/platform/cloudhub/src/main/mule/app.xml. In the application canvas, locate the orders-api entry flow and follow its Listener into APIkit Router. In Global Configurations, inspect the API autodiscovery association and its ${api.id} property.

Edit the worksheet as YAML in ACB; it is a planning artifact, not a deployable policy. Installing policies and checking their readiness happen in API Manager in the browser. Record the actual instance and environment there, then return to this worksheet to record each admitted and rejected test. ACB’s local Run button does not install API Manager policies.

Associate the managed API with the entry flow

Publishing the orders API as an asset does not prove that the deployed implementation is protected, and a perfect policy attached to yesterday’s test instance will not protect today’s production listener. Autodiscovery ties the two ends together: the cloud reference declares apiId="${api.id}" and flowRef="orders-api". The property must identify the intended managed instance, and the flow reference must wrap the Listener/APIkit entry through which business requests actually arrive. A separate unprotected listener would provide a bypass even if the managed flow’s policies were correct — from an attacker’s point of view, policies on the advertised endpoint are then optional.

This chapter uses the operator worksheet below. It records decisions and acceptance tests; it is not an API Manager import format or a claim that policies were installed.

Example 066 — Plan the orders policy boundary

Source: platform/policies/orders-policy-plan.yaml.

# Operator worksheet; not an API Manager import format.
apiEntryFlow: orders-api
identity:
  policy: JWT Validation
  signingMethod: RSA
  signingAlgorithm: RS256
  keySource: JWKS
  jwksUrl: https://issuer.example.com/.well-known/jwks.json
  requiredClaims:
    iss: https://issuer.example.com/
    aud: orders-api
    exp: future-instant
    tenantId: authenticated-tenant-id
  claimDestination: authentication.properties.claims
accessTests:
  - valid-token-and-owned-order
  - missing-token
  - expired-token
  - wrong-audience
  - missing-tenant
  - other-tenant-order
  - cold-start-before-policy-ready
  - direct-listener-bypass
quota:
  policy: Rate Limiting
  testAllowance: 3
  windowSeconds: 60
  identity: validated-consumer

A useful deployment record keeps four facts together: application release, target environment, managed API ID and entry flow. When a policy test fails, that mapping is the first thing to inspect. Create or select the versioned API contract and its sandbox instance, associate the deployment and inspect policy readiness. Then add one policy at a time: applying six together destroys the relationship between a change and the outcome it produced. First establish the chosen identity provider and required claims. Next prove that the application receives the expected trusted tenant. Only then key a consumer-specific quota on that validated identity.

The required JWT claims in the worksheet are requirements to configure in the policy/provider integration, not checks supplied by the YAML file itself. Real issuer and JWKS URLs, algorithms and audiences must match the selected provider. The example.com addresses are placeholders.

Distinguish admission from fulfillment

The word SLA reads like a promise about how quickly an order will be finished, and a tier in API Manager is nothing of the kind. An API contract and SLA tier regulate access and usage: a rate allowance does not make the catalogue faster, and it cannot make a warehouse response arrive within two seconds. Acceptance latency and fulfillment age remain separate service measures — when the retailer agreement promises both, both need their own measurement.

A deliberately small allowance — three requests in a minute — makes the boundary easy to observe without a load generator, and a production tier still needs its own capacity justification. Send four otherwise valid calls and record which reached the application. Include timestamps and the validated consumer identity; a status code alone is not enough to explain quota accounting.

Fixed windows can permit a burst near reset. Short-interval spike controls address a different capacity question and may delay requests within bounded policy behavior. They do not create a durable queue. A caller can time out while a delayed POST still progresses, so the idempotency contract remains necessary.

Start the capacity arithmetic at the narrowest dependency rather than at the gateway. For two independent gateway instances, a local allowance of 30 per second each can expose a shared 40-per-second dependency to 60 requests per second. Those numbers illustrate capacity arithmetic, not measured service limits. Establish whether the selected policy supports shared accounting in the actual topology, and include other callers and retries in the budget — the public API is not necessarily that dependency’s only source of work.

Test resource selection and policy interaction

A rule written for /orders may express nothing useful about the /bulk-orders route added three sprints later. The same trap springs again when that route arrives on its own listener: a bulk-import endpoint can then expose business operations outside the policy boundary altogether. A path rule must cover the methods and resources intended to be protected, including root, child and near-match paths, and both the intended match and a near miss are worth testing.

Policy order determines which identity and request shape later rules see. A quota keyed on an untrusted header remains untrusted even if a token check happens afterward. Conversely, a coarse ingress limit can reasonably precede expensive authentication when that is the declared contract.

A policy that rejects everybody passes a negative-only test, so the two kinds of case belong in one suite: an invalid token rejected before business work, and a valid owned request that still succeeds. An HTTP status alone cannot prove the business flow was bypassed either — the flow could have run and returned that same status itself. Use correlated logs or a controlled invocation counter to prove rejected calls caused no business effect.

Operate a policy as a release

A policy change is a production change even though no application archive moves: public status codes, headers and admitted traffic can all shift while the JAR stays byte-for-byte identical. A retailer may have coded its client around the existing headers or error responses, which makes a new quota or token requirement an interface change from that client’s point of view. So the change needs an owner, a review with the affected consumers and a rollback to the previous specific configuration — recorded with the policy versions, parameters, API instance, environment and application artifact.

A protection test run ten minutes after the application started says nothing about the interval while it was starting. Test startup before policy readiness, and test direct attempts to reach the implementation: a healthy warm gateway does not establish that a new replica cannot admit unprotected traffic. Network placement and startup enforcement are part of the same boundary.

When admitted volume falls after a policy change, lower backend error counts may mean protection is working — or that legitimate callers can no longer enter. Compare rejected and admitted traffic, accepted orders and dependency outcomes before declaring improvement.

Try it

1. Find the wrong boundary. API Manager shows enforcement, but anonymous requests succeed. What do you inspect first?

Show answer

Confirm DNS/endpoint and deployment, api.id, managed instance, entry flow, applied policy readiness and resource selection. Then test for a direct listener bypass. Preserve a trace showing whether the business operation ran.

2. Divide a shared budget. Why do two 30-request limits not protect a 40-request dependency?

Show answer

Independent instances can admit 60 in aggregate. Allocate capacity across all callers or use a supported shared limit and test that topology. Include retries and non-API workloads.

3. Undo a bad quota. Why is deleting every policy a poor rollback?

Show answer

It also removes the identity boundary. Restore the previous quota/version while retaining required authentication, then repeat one admitted and one rejected request.

Not run. API Manager association, JWT/OAuth enforcement, quota distribution and startup/bypass tests require an authorized environment. The worksheet and cloud source define the intended acceptance work; no account-dependent enforcement result is claimed.

The next chapter carries the application into that environment, with external persistence and explicit deployment configuration.

Next: Move the Service to CloudHub