Under which category would you file this issue?
Providers
Apache Airflow version
3.3.0
What happened and how to reproduce it?
In the docker compose file the command:
airflow keycloak-auth-manager create-team team-analytics --username "$${KEYCLOAK_ADMIN}" --password "$${KEYCLOAK_ADMIN_PASSWORD}"
was used to create a team. This generated ReadOnly-team-analytics with a decision strategy of UNANIMOUS.
However, this prevented Op and User level roles in that team from being able to access the DAGs since only one of Allow-Op-team-analytics and Allow-User-team-analytics was true. Essentially this is impossible, since only one of these roles will be true, they can never be unanimous.
Manually switching the decision strategy for ReadOnly-team-analytics to AFFIRMATIVE with the keycloak fixed the problem.
What you think should happen instead?
This should automatically work when create-team is run.
Claude suggested the following patch:
diff --git a/providers/keycloak/src/airflow/providers/keycloak/auth_manager/cli/commands.py b/providers/keycloak/src/airflow/providers/keycloak/auth_manager/cli/commands.py
index 705fc4eb0b..ab69caafa4 100644
--- a/providers/keycloak/src/airflow/providers/keycloak/auth_manager/cli/commands.py
+++ b/providers/keycloak/src/airflow/providers/keycloak/auth_manager/cli/commands.py
@@ -792,6 +792,7 @@ def _attach_team_permissions(
policy_name=_team_role_policy_name(team, "Viewer"),
scope_names=["GET", "LIST"],
resource_names=team_readable_resources,
+ decision_strategy="AFFIRMATIVE",
_dry_run=_dry_run,
)
for role_name in ("User", "Op", "Admin"):
@@ -802,6 +803,7 @@ def _attach_team_permissions(
policy_name=_team_role_policy_name(team, role_name),
scope_names=["GET", "LIST"],
resource_names=team_readable_resources,
+ decision_strategy="AFFIRMATIVE",
_dry_run=_dry_run,
)
_attach_policy_to_scope_permission(
Operating System
Debian GNU/Linux 12 (bookworm)
Deployment
Docker-Compose
Apache Airflow Provider(s)
keycloak
Versions of Apache Airflow Providers
apache-airflow-providers-keycloak==0.8.1
Official Helm Chart version
Not Applicable
Kubernetes Version
No response
Helm Chart configuration
No response
Docker Image customizations
No response
Anything else?
I think this would occur anytime that create-team is used and someone tries to access the DAGs with less than Admin permission.
Are you willing to submit PR?
Code of Conduct
Under which category would you file this issue?
Providers
Apache Airflow version
3.3.0
What happened and how to reproduce it?
In the docker compose file the command:
airflow keycloak-auth-manager create-team team-analytics --username "$${KEYCLOAK_ADMIN}" --password "$${KEYCLOAK_ADMIN_PASSWORD}"was used to create a team. This generated ReadOnly-team-analytics with a decision strategy of UNANIMOUS.
However, this prevented Op and User level roles in that team from being able to access the DAGs since only one of Allow-Op-team-analytics and Allow-User-team-analytics was true. Essentially this is impossible, since only one of these roles will be true, they can never be unanimous.
Manually switching the decision strategy for ReadOnly-team-analytics to AFFIRMATIVE with the keycloak fixed the problem.
What you think should happen instead?
This should automatically work when create-team is run.
Claude suggested the following patch:
Operating System
Debian GNU/Linux 12 (bookworm)
Deployment
Docker-Compose
Apache Airflow Provider(s)
keycloak
Versions of Apache Airflow Providers
apache-airflow-providers-keycloak==0.8.1
Official Helm Chart version
Not Applicable
Kubernetes Version
No response
Helm Chart configuration
No response
Docker Image customizations
No response
Anything else?
I think this would occur anytime that create-team is used and someone tries to access the DAGs with less than Admin permission.
Are you willing to submit PR?
Code of Conduct