potiuk commented on issue #37971: URL: https://github.com/apache/superset/issues/37971#issuecomment-4040885764
> Apache Airflow is built on FAB. I wonder if they have implemented something like this or would want to collaborate and use this? I posted in our slack (thanks for pinging us @sfirke) - we wentt in a different direction. For us now FAB is moved to provider and is one of many AuthManagers we can use. I will copy my rumbling from the Slack thread: We already moved away from FAB quite a bit - so submitting it upstream is not easy: we switched Airflow 3 to completley JWT-based authentication where we use JWT tokens to authenticate easch request. The token is generated via "AuthManager" - which is abstracted away from whether we use FAB AuthManager or any other FAB manager. We currently have: `FABAuthManager`, `SimpleAuthManager`, `KeyCloakAuthManager`, `AWSAuthManager` and there is an `LDAPAuthManager` implemented in community (and likely more) So - we decided to essentially delegate out the authentication from Airflow as such. Whether API Key Authentication is supported - is more of a question of Auth Manager - whether it supports it or not. "Airflow" does not care - it's up to the AuthManager which intial authentication mechanism is supported, - what auth manager does it will return the JWT token to the user and then that JWT token should be used for all interaction with api_server. So essentially - if FAB will support API Key authentication - we might also support it - it's just a matter in our FABAuthManager to exchange API_KEY into a temporary JWT Token - for the time of session This gives our users a lot of flexibilty - for example https://www.open200.com/post/mastering-keycloak-a-step-by-step-guide-to-authentication-and-authorization KeyCloak support all possible ways of athentication mechanims already, also "Auth" in our case means not only Authentication but also Authorization - > which essentially means that we can use all the complexity (or simplicity) of whatever we have as AuthManager. For example in case of KeyCloak, you can configure - very easily via some javascript code snippets - that a given user from given geographical location has access to given functonality between 9:00 am and 6:00pm with 12:00 - 13:00 lunch break where it is not possible, and that this only applies to pepople who are in a given department. So ... We kind of ... don't really need to think about the Authentication and Authorization mechanisms too much :smile: So yeah. 5. could be Airflow, happy to get it, but it's likely few lines of code to get the JWT token in case API key is valid - no change on our side. We already have buit-in mechanism to refresh the JWT-token as well when it expires (in FAB AuthManager) (edited) In our case that was implemented as part of AIP-56 https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management If you would like to learn from us -> delegating authentication out is probably best option This was our hypothesis and I think it worked out really well -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
