Introduce LIST action in AWS auth manager

[vincbeck]

Follow-up of #54926 on AWS auth manager side.

The current logic to list resources (e.g. list Dags) is a bit wrong in auth managers. Let's take an example. If a user is authorized to access only the Dag test, with the AWS auth manager today, the list Dags API returns access denied because we are checking whether the user has access to all Dags.

To fix that, I introduce a new action LIST so that admins can easily give LIST access to all Dags but GET access only on few Dags.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[o-nikolas]

To fix that, I introduce a new action LIST so that admins can easily give LIST access to all Dags but GET access only on few Dags.

So is the goal that the user should call list and be able to see a list of all dag ids but can only view the dag runs, code, etc for the dags they have permissions to get?

Is there a case where we want a user to not even be able to see the dag ids of dags they don't have access to? This is kind of a middle ground between how it works today and what I described above.

I kind of expected that when this hypothetical users calls LIST they should only get one item back in this case the test dag they have access to.

[vincbeck]

To fix that, I introduce a new action LIST so that admins can easily give LIST access to all Dags but GET access only on few Dags.

So is the goal that the user should call list and be able to see a list of all dag ids but can only view the dag runs, code, etc for the dags they have permissions to get?

Is there a case where we want a user to not even be able to see the dag ids of dags they don't have access to? This is kind of a middle ground between how it works today and what I described above.

I kind of expected that when this hypothetical users calls LIST they should only get one item back in this case the test dag they have access to.

It is a good question, there is basically 2 operations. When a user call list Dags, a permission check is performed to check whether the user is authorized to list Dags. If so, the operation continues, if not, they get a 403. If they have permissions to list Dags, then the list Dags API calls get_authorized_dag_ids (from auth manager) to retrieve only Dags the user has access to.

Here I focus only on the first check, which is: "whether the user is authorized to list Dags". Hope that helps :)

[o-nikolas]

To fix that, I introduce a new action LIST so that admins can easily give LIST access to all Dags but GET access only on few Dags.

So is the goal that the user should call list and be able to see a list of all dag ids but can only view the dag runs, code, etc for the dags they have permissions to get?
Is there a case where we want a user to not even be able to see the dag ids of dags they don't have access to? This is kind of a middle ground between how it works today and what I described above.
I kind of expected that when this hypothetical users calls LIST they should only get one item back in this case the test dag they have access to.

It is a good question, there is basically 2 operations. When a user call list Dags, a permission check is performed to check whether the user is authorized to list Dags. If so, the operation continues, if not, they get a 403. If they have permissions to list Dags, then the list Dags API calls get_authorized_dag_ids (from auth manager) to retrieve only Dags the user has access to.

Here I focus only on the first check, which is: "whether the user is authorized to list Dags". Hope that helps :)

Ahh okay, so it is true that the final result (for this hypothetical) is that the user will only see the test dag, right?

[vincbeck]

To fix that, I introduce a new action LIST so that admins can easily give LIST access to all Dags but GET access only on few Dags.

So is the goal that the user should call list and be able to see a list of all dag ids but can only view the dag runs, code, etc for the dags they have permissions to get?
Is there a case where we want a user to not even be able to see the dag ids of dags they don't have access to? This is kind of a middle ground between how it works today and what I described above.
I kind of expected that when this hypothetical users calls LIST they should only get one item back in this case the test dag they have access to.

It is a good question, there is basically 2 operations. When a user call list Dags, a permission check is performed to check whether the user is authorized to list Dags. If so, the operation continues, if not, they get a 403. If they have permissions to list Dags, then the list Dags API calls get_authorized_dag_ids (from auth manager) to retrieve only Dags the user has access to.
Here I focus only on the first check, which is: "whether the user is authorized to list Dags". Hope that helps :)

Ahh okay, so it is true that the final result (for this hypothetical) is that the user will only see the test dag, right?

Yes :)