Add readonly REST API endpoint for roles and permissions

[ephraimbuddy]

This PR seeks to add readonly endpoints for roles and permissions.
Because this two endpoints share a lot together, I decided to have the code for both in one file instead of separate files. Let me know if this should be separated

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, 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 UPDATING.md.

[github-actions]

The Workflow run is cancelling this PR. Building images for the PR has failed. Follow the workflow link to check the reason.

[ephraimbuddy]

I'm lost at what permissions should be used to protect these views @jhtimmins

[mik-laj]

do these endpoints work properly when environments use LDAP or Auth proxy?

[ephraimbuddy]

do these endpoints work properly when environments use LDAP or Auth proxy?

These endpoints are similar to what you would see when you go to Security > List Roles on the webserver. So it will work properly with any auth type since it just reads DB roles and permissions which are part of airflow. That's what I understand, unless I'm missing something. What do you think?

[mik-laj]

These endpoints are similar to what you would see when you go to Security > List Roles on the webserver. So it will work properly with any auth type since it just reads DB roles and permissions which are part of airflow. That's what I understand, unless I'm missing something. What do you think?

This is very confusing to end users. They don't know all the limitations we have in the project. A similar situation occurs when the user uses the Backend Secret. See: https://apache-airflow.slack.com/archives/CCR6P6JRL/p1615394435242400 We should think about how to limit similar surprises because it takes users hours/days to discover that everything works as intended, but they misunderstood our product. This was one of the reasons this endpoint did not appear in the first version of the API.

API for optional components

The goal is not to develop an API for non-fundamental components. There are expectations to develop an API that provides additional features. For example:

allows access to node information when using CeleryExecutor,
for deeper integration between Airflow and Kubernetes when KubernetesExecutor is used
for monitoring
Integration with these components will be covered in other documents.

https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-32%3A+Airflow+REST+API

As the simplest solution, we can disable this endpoint if it doesn't work properly in a current configuration, but we can also write a smart solution.

[ephraimbuddy]

As the simplest solution, we can disable this endpoint if it doesn't work properly in a current configuration, but we can also write a smart solution.

These would certainly cause confusion for people checking roles and permissions just as it currently does on the UI.
Curious on what a smart solution would be. Is there a way we can see Roles and permissions from an LDAP server through airflow? My understanding is that we can get roles and permissions for the current_user but not all that're available in the server. 🤔

[mik-laj]

These would certainly cause confusion for people checking roles and permissions just as it currently does on the UI.

In Web UI, we should also disable it if it doesn't work properly.

Is there a way we can see Roles and permissions from an LDAP server through airflow?

Probably, when you pass * as the username to _search_ldap method, the list of all users will be stored in the search_resulsts variable, but I did not check it.
https://github.com/dpgaspar/Flask-AppBuilder/blob/dbe1eded6369c199b777836eb08d829ba37634d7/flask_appbuilder/security/manager.py#L845

[ephraimbuddy]

These would certainly cause confusion for people checking roles and permissions just as it currently does on the UI.

In Web UI, we should also disable it if it doesn't work properly.

Is there a way we can see Roles and permissions from an LDAP server through airflow?

Probably, when you pass * as the username to _search_ldap method, the list of all users will be stored in the search_resulsts variable, but I did not check it.
https://github.com/dpgaspar/Flask-AppBuilder/blob/dbe1eded6369c199b777836eb08d829ba37634d7/flask_appbuilder/security/manager.py#L845

Hi @mik-laj , after going through the code, I see that we are good with this implementation.
Whatever authentication method that is been used, roles for users are set with AUTH_ROLES_MAPPING config or AUTH_USER_REGISTRATION_ROLE if users are to be registered to the DB.

These roles must be one of the roles in FAB DB, that's why it's calculated here for LDAP.

And you can see where roles in AUTH_ROLES_MAPPING are being searched here

I believe we are good returning roles available in airflow because that's what auths use.

The same thing applies to users endpoint, if user registration is set, users are created in FAB DB, if not, then no users in DB and there'll not be accident of returning users that was not added through LDAP or remote user.

So I think this is different from secrets 🙁

[ephraimbuddy]

Removed mistakenly added users endpoint

[jhtimmins]

What's the different between a permission and an action resource?

[ephraimbuddy]

ActionResource is equivalent to PermissonView Model https://github.com/dpgaspar/Flask-AppBuilder/blob/55b0976e1450295d5a26a06d28c5b992fb0b561e/flask_appbuilder/security/sqla/models.py#L71
It helps tie action with a resource