Fix DAG-level RBAC by using claim_token per UMA spec (#61137)

[y-sudharshan]

Fix DAG-level RBAC by using claim_token per UMA specification

closes: #61137

Description

This PR fixes a bug in the Keycloak Auth Manager where context attributes (such as dag_id) were not being properly transmitted to Keycloak during authorization requests, preventing DAG-level RBAC policies from functioning.

Problem

When attempting to configure DAG-level authorization policies in Keycloak, the dag_id and other context attributes were not available to JavaScript-based policies. Network traces showed that instead of sending the actual attribute values, the literal string context=attributes was being transmitted in the authorization request.

Root Cause:
The original implementation used a non-standard context parameter with a nested dictionary:

payload["context"] = {"attributes": attributes}

This approach failed because:

1. It is not compliant with the UMA (User-Managed Access) specification
2. Nested dictionaries in form-urlencoded requests cannot be properly serialized by the requests library
3. Keycloak does not recognize the context parameter for authorization requests

Solution

Implemented the correct UMA specification for pushing claims to Keycloak by using the claim_token parameter:

claims= {key: [value] forkey, valueinattributes.items()}
claim_json=json.dumps(claims)
claim_token=base64.b64encode(claim_json.encode()).decode()
payload["claim_token"] =claim_tokenpayload["claim_token_format"] ="urn:ietf:params:oauth:token-type:jwt"

Key changes:

• Use claim_token parameter instead of context (per UMA spec)
• Base64-encode the JSON data
• Format claim values as arrays of strings (required by Keycloak)
• Add claim_token_format parameter

Reference:Keycloak Authorization Services - Pushing Claims

Impact

After this fix:

• ✅ DAG-level RBAC policies will work correctly
• ✅ dag_id and other context attributes are accessible in Keycloak policies
• ✅ Fine-grained authorization per DAG is now possible

Example Keycloak policy that now works:

constcontext=$evaluation.getContext();constattributes=context.getAttributes();constdagId=attributes.getValue('resource_id').asString(0);if(dagId==='sensitive_dag'){// Apply specific permissions$evaluation.grant();}

Testing

• Code passes ruff format and ruff check validation
• Tested claim_token encoding/decoding with validation script
• Verified form-urlencoded transmission preserves data correctly
• Confirmed backwards compatibility (no impact when attributes are not provided)

Changes Made

Modified files:

1. providers/keycloak/src/airflow/providers/keycloak/auth_manager/keycloak_auth_manager.py
   - Added import base64
   - Updated _get_payload() method to use claim_token parameter

2. providers/keycloak/docs/changelog.rst
   - Added bug fix entry for version 0.5.2

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: GitHub Copilot

[n-badtke-cg]

lgtm

EDIT: Is a bump of the version number already needed with this PR? https://github.com/apache/airflow/blob/main/providers/keycloak/src/airflow/providers/keycloak/__init__.py#L32

[ddroessler-ext]

I tested the changes locally and can confirm that it works as expected - thanks a lot for the quick implementation.
The dag id is correctly sent to Keycloak and also available in JavaScript policies.

Small nit on your example in the PR, the id of the requested dag is in key resource_id instead of dag_id.

[vincbeck]

Thanks for fixing that issue. I added some comments, also, can you update/create test to cover that?

[bugraoz93]

Still a quite bit of CI failing. Could you please check?

[n-badtke-cg]

🥳

[y-sudharshan]

🥳

Thanks!
Thanks for your relevant and quick review