Possible Regression: ACL Plugin Always Returns 403 with Konnect Application Auth on Fresh Konnect Trial (Gateway 3.15.0.2)

, ,
1

Hi everyone,

I’m trying to determine whether I’ve found a regression or if I’m missing a new configuration requirement introduced in Gateway 3.15.0.2.

Environment

Working Environment

  • Konnect Trial (older)
  • Gateway Data Plane: 3.15.0.1

Non-working Environment

  • Fresh Konnect Trial
  • Gateway Data Plane: 3.15.0.2

Both environments were created independently (not cloned).

Authentication Flow

I’m using the standard Konnect Developer Portal workflow:

  1. Azure Entra ID (OIDC) authentication
  2. Azure Group → Developer Portal Team Mapping
  3. Developer creates an Application
  4. Application Registration is approved
  5. Application is linked to a Gateway Consumer
  6. Consumer belongs to a Consumer Group
  7. Application API key is used to authenticate requests

No Key Authentication plugin is enabled on the Gateway.

Authentication is handled by the managed Konnect Application Auth plugin together with Konnect Access Control Enforcement.

ACL Configuration

ACL plugin is attached to the Route.

Example:



Allow:
<consumer-group>

Include Consumer Groups:
Enabled

Deny:
(empty)

The linked Consumer is confirmed to be a member of the allowed Consumer Group.

Consumer Linking

The Application Registration is correctly linked to a Gateway Consumer.



Application
    ↓
Linked Consumer
    ↓
Consumer Group

The Consumer appears correctly inside the Consumer Group.

Observed Behavior

Without the ACL plugin:

  • :white_check_mark: Application API key authenticates successfully.
  • :white_check_mark: Request reaches the upstream service.

With ACL enabled:

  • :cross_mark: Request returns 403 Forbidden.

Authentication still succeeds.

Only authorization fails.

Interesting Difference

The generated managed konnect-application-auth plugin differs between the two environments.

Working (3.15.0.1)



"principals": {
    "enabled": true
}

Non-working (3.15.0.2)



"principals": {
    "enabled": false
}

Everything else in the generated plugin is effectively identical (aside from expected IDs, scopes, strategy IDs, etc.).

The plugin is Konnect-managed:



konnect-managed-plugin

so it isn’t something I configured manually.

Request Logging

Requests authenticate successfully:



auth_type: key-auth

However, the request only contains an authenticated_entity and does not appear to resolve to a Consumer object before ACL evaluation.

The request ultimately returns:



403 Forbidden

Troubleshooting Performed

Verified:

  • Azure OIDC configuration
  • Team Mapping
  • Application Authentication Strategy
  • Consumer Linking
  • Consumer exists
  • Consumer belongs to the correct Consumer Group
  • ACL Allow list
  • Include Consumer Groups enabled/disabled
  • Recreated the Developer Portal from scratch
  • Recreated Applications
  • Recreated Consumers

The only consistent difference found is:



principals.enabled

Working:
true

Non-working:
false

Question

Has anyone seen this before?

Specifically:

  • Is principals.enabled=false expected on fresh Konnect portals?
  • Is ACL officially supported together with Konnect Access Control Enforcement and Konnect Application Auth in Gateway 3.15.0.2?
  • Could this be a regression introduced after 3.15.0.1?

Any insight would be greatly appreciated.

I intentionally omitted:

  • Company names
  • Personal names
  • Portal names
  • Consumer names
  • Consumer Group names
  • Domain names
  • Control Plane names
  • UUIDs
  • Internal IDs
2

Hi, can you confirm that “application to consumer linking” is enabled for the auth strategy that you are using in the new Konnect Trial org? The default value is disabled.

image
image3434×1136 345 KB

3

Thank you Nate!

That was it :cry: I spent so much time on this, and when you mentioned it, I’m like why did I not see this before :smiley:

Thanks again!