Support for external user authentication
See original GitHub issueAuto-reviewers: @NiharikaRay @matthewwardrop @earthmancash @danfrankj
I want to integrate the knowledge repo with our internal identity services (ldap and saml) such that we can control access to certain posts (although we would like all authenticated users to be able to discover the posts and read the TLDR field which I think is how the private field works today).
I believe the expected configuration is that a reverse proxy sets some authentication headers based on the configuration file. However, just grepping through the code it does not look like the AUTH_GROUP_REQUEST_HEADER
is used.
I am also worried a little bit about keeping the users/groups in the knowledge_repo database in sync with our ldap system. Specifically I’m worried that if a user is booted from a group that there is not a good mechanism for updating the knowledge_repo server’s view of the groups.
I’m definitely willing to contribute some changes to work this out if you guys are interested. I just wanted to discuss some approaches before I go making a lot of changes. Personally I would like to see something like how JupyterHub works with auth plugins that allow each deployment of the knowledge repo an extension point to integrate with whatever AAA services are provided. I started looking at existing Flask extensions like Flask-security, Flask-principal, and Flask-login, but integrating those seemed like a massive change to the architecture. I’m also not entirely convinced that the managing auth through a proxy is not sufficient.
One of the goals for the Knowledge Repo for us is to get some discoverability to our data science teams reports. Really like that the TLDR is still viewable even though the post is private. This kinda sets a gate up so other teams can see an analysis was done, but have to ask for approval to see it.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:12 (1 by maintainers)
Top GitHub Comments
@sunilkpai (Moving from the #299 to general issue tracker). I have mostly implemented this feature locally, and am sorting out some extra considerations (like keeping track of authors and users separately), but should look to land this by next week.
Hi @matthewwardrop! I have a related requirement to this one, which is that we intend to store the knowledge repo as a private repo on a cloud git service (most likely Bitbucket) and serve the web app from a cloud container service (likely Heroku or Azure). I’m intending to add the ability to use Bitbucket’s OAuth API to authenticate users and check that they have read access to the underlying repo before serving it up.
Are you still intending to work on the auth functionality in June? If so, it would be great to combine our efforts. If not, I’m happy to implement something in my fork.