alexanderzg opened a new issue, #74357: URL: https://github.com/apache/airflow/issues/74357
### Under which category would you file this issue? Providers ### Apache Airflow version 3.2.2 ### What happened and how to reproduce it? I am using Apache Airflow 3.2.2 with apache-airflow-providers-keycloak 0.11.0 and Keycloak 26.4.7. Authentication works correctly. Users can log in to the Airflow UI through Keycloak, and Airflow recognizes the assigned Keycloak client roles such as Viewer and Admin. The problem occurs with authorization depending on the Keycloak client's Authorization -> Settings -> Decision Strategy. With the resource server Decision Strategy set to UNANIMOUS, users receive 403 responses for resources that should be accessible according to their role. For example, evaluating an Admin user for: Resource: Pool Scope: LIST produces: ReadOnly: PERMIT (Affirmative) Op: DENY (Unanimous) Admin: PERMIT (Affirmative) The final authorization result is DENY because the resource server uses UNANIMOUS. This causes an Admin user to receive 403 errors for operations/resources that Admin should be able to access. A similar problem occurs for Viewer users. For example: User: Viewer Resource: Pools Scope: MENU ReadOnly: PERMIT (Affirmative) Admin: DENY (Affirmative) With the resource server Decision Strategy set to UNANIMOUS, the final result is DENY, and the Viewer receives 403 errors for UI resources that ReadOnly explicitly permits. Changing the resource server Decision Strategy to AFFIRMATIVE resolves the Admin 403 errors, but introduces the opposite authorization problem. For the same Viewer evaluation: ReadOnly: PERMIT Admin: DENY the final result becomes PERMIT because one permission grants access. As a result, Viewer users begin seeing Admin settings/features in the Airflow UI that should not be available to them. The permissions and policies were generated using the Keycloak Auth Manager CLI, including create-all/create-permissions. Running create-permissions --dry-run shows the expected policy attachments: Allow-Viewer -> ReadOnly Allow-User -> ReadOnly Allow-Op -> ReadOnly Allow-Admin -> ReadOnly Allow-User -> User Allow-Op -> Op Allow-Admin -> Admin Allow-SuperAdmin -> Admin There are no composite/associated roles configured for the Admin client role. Keycloak Policy Enforcement Mode is set to Enforcing. Therefore neither resource server Decision Strategy appears to produce the expected Airflow role authorization behavior: UNANIMOUS: - Prevents privilege escalation, but legitimate users including Admin receive 403 errors because DENY results from lower-level/resource-specific permissions veto otherwise valid permissions. AFFIRMATIVE: - Allows Admin to work, but ReadOnly PERMIT results can override Admin/Op DENY results, causing Viewer users to see features/settings that should be restricted. ### What you think should happen instead? The Keycloak authorization model generated by apache-airflow-providers-keycloak should correctly enforce the Airflow role hierarchy without requiring a choice between legitimate access and privilege isolation. An Admin user should be authorized for resources and operations covered by the Admin role even when a resource-specific Op or User permission does not match that user. A Viewer user should retain only the access intended for Viewer/ReadOnly and should not gain Admin-only UI features or permissions. The generated Keycloak permissions should work with a clearly defined resource server Decision Strategy so that: - Viewer receives the intended read-only access. - User receives User plus appropriate read-only access. - Op receives operational plus appropriate read-only access. - Admin receives administrative access. - A DENY from a permission intended for another role does not incorrectly veto a valid higher-level role. - A broad ReadOnly PERMIT does not override restrictions on Admin-only functionality. The provider should either configure the required resource server Decision Strategy and permission structure automatically, or document the required Keycloak authorization configuration if additional configuration is necessary. ### Operating System Linux ### Deployment Official Apache Airflow Helm Chart ### Apache Airflow Provider(s) keycloak ### Versions of Apache Airflow Providers apache-airflow-providers-keycloak==0.11.0 ### Official Helm Chart version 1.22.0 (latest released) ### Kubernetes Version v1.33.11 ### Helm Chart configuration KeycloakAuthManager configured as the Airflow authentication/authorization manager. No unusual Helm configuration known to be relevant to reproducing the authorization issue. ### Docker Image customizations No relevant customizations ### Anything else? Keycloak version: 26.4.7 Keycloak Policy Enforcement Mode: Enforcing The Admin, Viewer, User, Op, and SuperAdmin roles referenced above are Keycloak client roles for the Airflow client. Authentication itself is working. The issue appears specifically related to authorization evaluation and the interaction between the generated ReadOnly/User/Op/Admin permissions and the Keycloak resource server Decision Strategy. Keycloak's Evaluate feature reproduces the authorization conflict directly, so the behavior can be observed at the Keycloak authorization layer independently of the Airflow UI. ### Are you willing to submit PR? - [ ] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
