Protect IFS Cloud APIs with Azure API Management

Explore this learning path

Documentation-based guide draft · Reviewed against sources on 2026-09-27 · Not executed in an IFS environment. IFS references use 26R1 unless stated otherwise. Confirm available APIs, components, and permissions in your installed release.

Put one read-only IFS operation behind Azure API Management (APIM), validate the caller’s IFS token, and prevent the caller from selecting arbitrary backend routes. This example forwards the caller’s identity to IFS; it does not exchange an Azure token for an IFS service token.

Before you start

You need an APIM instance, permission to edit its APIs, network access from APIM to IFS and its OpenID metadata endpoint, and a working GET request under the intended IFS user. Record the projection base URL, entity collection, approved fields, token issuer, and accepted audience. Obtain these from the environment’s IAM configuration and API Explorer.

1. Prove the direct call

Use Postman to call the intended IFS entity collection with $top=1, an appropriate $select, and the intended user’s bearer token. Save the status and sanitized response. Do not continue until the direct call succeeds; APIM cannot repair missing IFS grants.

Choose a narrow initial contract: GET /ifs-lab/records always returns at most ten approved records. It accepts no caller-supplied OData query. The IFS identity’s business permissions still determine which records are accessible.

2. Create the API and operation

1. In Azure portal, open the APIM instance and select APIs → Add API → HTTP.
2. Set a display name such as IFS read lab, the API URL suffix ifs-lab, and the web service URL to the confirmed projection base ending in .svc.
3. Add one operation: method GET, URL /records, display name List approved records.
4. Keep other methods and paths undefined. A broad catch-all operation would defeat this exercise’s restricted contract.
5. Keep subscription requirements enabled if your APIM product requires them. A subscription key complements authentication; it does not replace the user’s bearer token.

3. Create named values and apply the policy

Under Named values, create these non-secret values from verified environment settings:

Name	Meaning
ifs-oidc-metadata-url	The realm’s OpenID discovery document URL
ifs-api-audience	Audience accepted for your IFS API token
ifs-projection-base	Fixed HTTPS projection base URL

On the GET operation, open the inbound policy code editor. Adapt this policy by replacing YOUR_ENTITY_SET and YOUR_FIELD_1,YOUR_FIELD_2 with names already proven in step 1:

<policies>
  <inbound>
    <base />
    <validate-jwt header-name="Authorization" require-scheme="Bearer"
                  failed-validation-httpcode="401">
      <openid-config url="{{ifs-oidc-metadata-url}}" />
      <audiences><audience>{{ifs-api-audience}}</audience></audiences>
    </validate-jwt>
    <set-backend-service base-url="{{ifs-projection-base}}" />
    <rewrite-uri template="/YOUR_ENTITY_SET" copy-unmatched-params="false" />
    <set-query-parameter name="$top" exists-action="override">
      <value>10</value>
    </set-query-parameter>
    <set-query-parameter name="$select" exists-action="override">
      <value>YOUR_FIELD_1,YOUR_FIELD_2</value>
    </set-query-parameter>
    <set-header name="Accept" exists-action="override">
      <value>application/json</value>
    </set-header>
  </inbound>
  <backend><base /></backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>

Review inherited policies before saving: this example assumes they preserve the incoming Authorization header and do not override the chosen backend. Inspect APIM’s effective policy. Fixed query values prevent a caller from enlarging $top or selecting extra fields through this operation.

4. Call the gateway

In Postman, call your APIM gateway’s /ifs-lab/records URL. Supply the IFS bearer token and, if required, Ocp-Apim-Subscription-Key. Compare the returned records with the direct request under the same identity.

Use the APIM test/trace tools in the restricted development environment to confirm the actual backend route and status. Avoid retaining Authorization headers in diagnostic exports.

5. Test the restrictions

Test	Expected outcome
No bearer token	Rejected before the backend call
Expired or wrong-audience token	Rejected by JWT validation
Valid identity with insufficient IFS grants	IFS authorization failure
Add $top=1000 or another $select	Effective backend query stays fixed
POST or an undefined path	No matching permitted operation
Backend unavailable	Controlled gateway error; no write is involved

A 401 during metadata validation can indicate an inaccessible discovery/JWKS endpoint, issuer mismatch, or wrong audience. A 404 after forwarding usually means the projection base and rewritten path do not combine as expected. Inspect those before changing security settings.

Remove the test API/product access after the exercise. If you later need service-token exchange, implement it as a separately reviewed design with secret storage, token expiry handling, and explicit caller-to-business-scope authorization.

Additional policy references: backend routing and URL rewriting.

Sources and scope

• Microsoft API authentication overview
• Microsoft JWT validation policy

Older IFS Applications examples are historical context, not evidence of Cloud compatibility. No third-party code, screenshots, or downloadable workflows are reproduced.