aaron-wolmutt commented on issue #57966:
URL: https://github.com/apache/airflow/issues/57966#issuecomment-3600056264

   
   
   
   > > I was thinking that the call would happen after login. So, the user 
authenticates, the /ui/auth/meta/permissions API is called, then an 
authorization object persisted to local storage.
   > 
   > Yeah. [@aaron-wolmutt](https://github.com/aaron-wolmutt) -> I think you 
did not really grasp the way how Auth Manager works. We have (and that's a 
deliberate decision) no single place where we keep all permissions that user 
has. This is delegated to the AuthManager and we just ask if we can do "this 
thing". And we **always** query "can I do THAT?" before we do THAT (this can be 
cached by Auth Manager, but it's totally dependent on implementation of the 
Auth Manager and is only possible if there is no **dynamic** THAT permission.
   > 
   > The thing is that the THAT can contain (dag_id) for example. There might 
be completely different answer from the Auth Manager when you ask:
   > 
   > * Can I trigger Dag A
   > * Can I trigger Dag B
   > 
   > And the logic which Dags can be triggered can be arbitrary complex and 
fully implemented in the Auth Manager implementation. For example in LDAP Auth 
Manager you could have separate database for:
   > 
   > * users
   > * departments
   > * dags
   > 
   > The department can be taken from some [LDAP 
attribute](https://www.ibm.com/docs/en/cip?topic=api-user-identity-attributes) 
- for example `departmentNumber` to get your department, and ten you can query 
dag list to see which dags are assigned to which departments. This is 
**entirely** dependent on the Auth Manager implementation, how complex and 
flexible it is. But eventually if you have 100.000 Dags - you would have to 
retrieve and cache 100.000 values "Can I trigger Dag X" for each user - and 
retrieve them right after login. Simply "permission" query contains also 
"resource id" as parameter - and result of the query can be different for each 
"resource".
   > 
   > There is simply no "fixed" set of permission + resource combinations that 
user can enumerate effectively. This is why you need to query (Can I Trigger 
Dag 123) **just about** when you are going to show "Trigger Dag 123" button. 
You should also optimise such call for dag list - by being able to have one 
"Can I trigger Dags" fo all (say) 20 Dags you are about to display - and return 
the answer in one response for all 20 of them.
   > 
   > But you cannot have "all permissions" for "all dags" combination. That 
would be just infeasible and require huge queries to backend (say LDAP) when 
you want to retrieve all those.
   
   Thanks guys I'm starting to understand. 
   
   It looks like all of the DAGs that are listed in the UI do only support 
```DAGAccessEntity.RUN``` like mentioned before. 
   
   airflow-core/src/airflow/api_fastapi/core_api/routes/ui/dags.py
   ```python
   dags_router = AirflowRouter(prefix="/dags", tags=["DAG"])
   
   
   @dags_router.get(
       "",
       response_model_exclude_none=True,
       dependencies=[
           Depends(requires_access_dag(method="GET")),
           Depends(requires_access_dag("GET", DagAccessEntity.RUN)),
       ],
       operation_id="get_dags_ui",
   )
   def get_dags(
       limit: QueryLimit,
       offset: QueryOffset,
   ...
   ```
   So could we require the dependency like this into the /ui/auth/meta endpoint 
like this? I just did some debugging for the issue and I'm trying to understand 
it better. 
   
   ```python
   dependencies=[
         Depends(requires_access_dag(method="POST")),
     ]
   def get_dag_meta_permissions():
   ...
   ``` 
   
   


-- 
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]

Reply via email to