I think the main idea here was to delegate the authentication to what connexion provides (it has various authentication plugins). And I agree authorization should be addressed in the design as it cannot be solved by connexion "standard" plugins nor Open API definition - this is more of application choice.
I think we should get som simple, yet configurable mechanism for authorization - which should be similar to what we have in FAB now but we should learn from its problems. I think we should first agree on the principles and features we want to achieve and then decide how to proceed. What I think this authorization system for the API should/should not do (this is my personal view - others might have different opinion, so feel free to express yours): * it should not be view-centered but API endpoint-centered. * It should allow assigning the users to different Roles - example roles - "Admin", "Editor", .... * It should allow to bundle several API calls together and assign rights to the API "bundles" to the user roles. Example "connections", "dags", "pools" .... . Again - those should be per API not per View. * the Bundles should have "Read"/"Write" access types * the Roles do not have to have UI to manage it - it could be done by a configuration file * it should be discoverable - the UI code should be able to discover which API Bundles it has access to (this will allow implementing dynamic views that will adapt to the different Roles). * optionally the users should have the capability of constraining rights to certain resources per "resource" (so for example access to some dags only). We could implement a very simple 1-1 mapping of the current "owner" approach, and in the future, we could implement "User Groups" and have "Resource-per-Group" authorization. I don't think it is for Airflow 2.0 and we should add it later (this is application level rather than API level feature). J. On Thu, Mar 19, 2020 at 1:31 PM Ash Berlin-Taylor <[email protected]> wrote: > -1 (binding) for the moment, sorry. This is mostly because of the proposed > permissions solution. > > I am happy with the spec-first approach, and feel we can get there on > the exact API methods, what IDs we expose or don't etc, but this > permissions is a deal breaker for me as it stands. > > From your last response I am still not sure 100% what you are proposing, > and it feels like we are fighting against FAB rather than working with > it. For example you say: > > > all we have to do is replace steps 4 and retrieve information from the > > code, not the database. > > Do the permissions management screens in FAB still work -- i.e. can > someone choose to give a user/role access to only a single API endpoint? > If so how do we achieve that without having to re-write the Security > screens from FAB. > > What is wrong with the FAB database approach that means we have to > re-write or > customize it's behavoiur? > > Yes our current permissions approach isn't great, but that is just how > we've "chosen" to do it in Airflow, it's not a problem with the > underlying permissions model. For example a different way of doing it: > > > https://github.com/apache/airflow/pull/7251/files#diff-948e87b4f8f644b3ad8c7950958df033R2719-R2722 > > This added a (AJAX-style) method to DagModelView, and reuses the > "can_list" permission to achive it - because the "action"/verb is about > listing, it doesn't ever make sense to deny autocompletion if you can > list. > > If I understand your proposal correctly, you are suggesting something > like "can_edit_variable on APIView"? Why not "can_edit on > Variable" (or VariableView), and then that one permission could apply to > web UI and API. (Without the "on X" part I think a lot fo FAB won't work > right.) > > So specific things I want to see addressed before I will +1 this. > > - How do we manage API permissions for custom roles? (i.e. do the > existing screens work, how usable are they?) > - What "ViewMenu" is the permission tied to? > - What do these look like the Security screens? > - How do we manage these API permissions on a per-DAG level? > - Are we unifying the API permissions and the front end-permissions? > > I feel we are close on this AIP! > > Ash > > On Thu Mar 19, 2020 at 10:55 AM, Jarek Potiuk wrote: > > +1 binding > > > > > > On Thu, Mar 19, 2020 at 10:32 AM Tomasz Urbaszek < > > [email protected]> wrote: > > > > > > > +1 binding > > > > > > On Thu, Mar 19, 2020 at 10:29 AM Kamil Bregu=C5=82a > <kamil.bregula@polide= > > a.com> > > > wrote: > > > > > > > Hello all, > > > > > > > > This email calls for a vote on the design proposed in AIP-32, found > her= > > e > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-32%3A+Airflow+RES= > > T+API > > > > > > > > > > > > https://lists.apache.org/thread.html/r2a0d0fb3d4610432fa52148d7d9e59c7632= > > dd8f2fa61a580430b814c%40%3Cdev.airflow.apache.org%3E > > > > > > > > A few notes: > > > > > > > > - The proposed in AIP is to use an the "Specs first" approach. > > > > First, we make the change in the openapi.yaml file, and then > > > > we change the code. > > > > - This AIP allows for high granulation. Many people can work on > > > > smaller independent tasks. Already the application from Outreachy > > > > internships asked me how they can work on this AIP. > > > > - Details of the API structure may still change until the first > version > > > > is released. > > > > > > > > This vote will last for 72 hours until 2020-03-22T10:30Z, and until > at > > > > least 3 votes have been cast. > > > > > > > > > > > > > > > > https://www.timeanddate.com/worldclock/fixedtime.html?iso=3D20200322T1030= > > &p1=3D262 > > > > > > > > This is my +1 vote. > > > > > > > > Thanks, > > > > Kamil > > > > > > > > > > > > > -- > > > > > > Tomasz Urbaszek > > > Polidea <https://www.polidea.com/> | Software Engineer > > > > > > M: +48 505 628 493 <+48505628493> > > > E: [email protected] <[email protected]> > > > > > > Unique Tech > > > Check out our projects! <https://www.polidea.com/our-work> > > > > > > > > > > > > > --=20 > > > > > > Jarek Potiuk > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > > > M: +48 660 796 129 <+48660796129> > > [image: Polidea] <https://www.polidea.com/> > > > > > > > > > > -- Jarek Potiuk Polidea <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea] <https://www.polidea.com/>
