René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Authentication and authorization","articleBody":"Creating this issue to track the discussion around user authentication \u0026 authorization. \r\n\r\n### 1. Prior Art: Auth as proposed in the Feast Projects RFC\r\nIn the [Feast: Projects RFC](https://docs.google.com/document/d/14-QBz9X8zK_aGAY2ti43a7PqMxvqp0035ec7QYgmEBM/edit#heading=h.c29o6bkcurw9) we proposed a basic form of authentication as a \"minmal\" implementation for Feast 0.5.\r\n\r\n**Overview**\r\nAt a high level, this proposal adds user authentication based on a new user table that Feast maintains. No API is made available to manage the creation/removal of users, but the actions taken by users is on the Feast Core API is limited to the resources they have access to. Resource access is managed only based on membership of users to projects. \r\n\r\nNote on Roles: \"Roles\" were originally proposed but will be delayed until a future release can implement them properly. Right now there is only a full \"owner\" role which is implicit. All users either have ownership of a project, or not.\r\n\r\n**Assumptions**:\r\n- User authentication only applies to Feast Core, not ingestion or \"serving\".\r\n\r\n**Out of scope**:\r\n- Full user management (create or remove users, or manage user profiles).\r\n- JWT or functionality like sessions on user auth.\r\n- RBAC\r\n\r\n**Data model**\r\n![image](https://user-images.githubusercontent.com/6728866/75601939-4d655880-5afb-11ea-8fc4-249bf3ae0df4.png)\r\n\r\n**API**\r\n- Feast Core API\r\n  - New RPCs\r\n    - AddMember: Add a user to a specific project\r\n    - RemoveMember: Remove user from a specific project\r\n    - ListMembers: List members in a project\r\n    - ~~AddRole~~\r\n    - ~~RemoveRole~~\r\n- Feast Core Data Model\r\n  - New table\r\n    - Users: Users table\r\n    - UserProjects: Relation between users \u0026 projects\r\n    - ~~Roles: Roles table~~\r\n    - ~~UserProjectRole: Relation between roles, users, and projects~~\r\n  - New classes\r\n    - Users\r\n    - ~~Roles~~\r\n- Python SDK\r\n  - Addition of user auth configuration\r\n  - New methods:\r\n    - add_member()\r\n    - remove_member()\r\n    - list_members()\r\n    - ~~add_role()~~\r\n    - ~~remove_role()~~\r\n\r\n### 2. Objectives\r\nThe main objective of this issue is to finalize two proposals. The first is a \"minimal\" set of functionality that we want to support, and the second is a \"full\" set of functionality. Since Feast 0.5 is our next release, the priority is to finalize the implementation of the minimal release.\r\n\r\n* **Minimal**: To implement a basic form of authentication in Feast 0.5. \r\n* **Full**: Create an extensible/pluggable authentication \u0026 authorization system that supports multiple providers, can be used by both services and users, and covers ingestion, Core, and serving. No PR exists for this functionality yet.\r\n\r\n### 3. Requirements (minimal release)\r\nThe following user stories should be supported as part of the first minimal release (Feast 0.5).\r\n\r\n#### 3.1 User stories\r\n1. As a Feast user, so that I can prevent other users from modifying my feature sets, I would like to have a way to prevent modification of feature sets by unauthorized users.\r\n2. ~~As a Feast user, so that I can prevent other users from seeing my feature sets, I would like to have a way to limit access to certain users to view my feature sets~~ [Edit: Removing this story. It would be simpler to allow full view access]\r\n3. As a Feast user, so that I can allow my team to modify/view my feature sets, I would like to have a way to selectively grant or revoke access to feature sets for specific users.\r\n4. As a Feast user, so that I can grant access to multiple feature sets in a project, I would like to manage access control to feature sets at the project level\r\n5. As a Feast user, so that Feast can uniquely identify me, I would like to be able to authenticate myself to Feast.\r\n\r\n#### 3.2 In Scope\r\n- Authentication of users\r\n- Management of membership of users to projects for the purposes of granting access to feature sets within those projects\r\n- Project level access control (read vs write) based on membership of projects\r\n\r\n#### 3.3 Out of Scope\r\n- Full authorization or RBAC.\r\n- Stream, ingestion, and serving are also out of scope for the purposes of authentication and authorization.\r\n- Full user management (create or remove users, or manage user profiles).\r\n- JWT or functionality like sessions on user auth.\r\n\r\n### 4. Open questions\r\n- Which authentication frameworks or providers should be supported for Feast 0.5?\r\n- Are there any frameworks or open source services that would make implementing authorization safer, especially offload the responsibility of managing user credentials?\r\n- Do our long term and short term goals for both user authentication and authorization align?\r\n- What should be in scope for authentication for Feast 0.5?\r\n","author":{"url":"https://github.com/woop","@type":"Person","name":"woop"},"datePublished":"2020-02-29T06:14:01.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":21},"url":"https://github.com/504/feast/issues/504"}