Support auth via reverse-proxy headers #90
Labels
enhancement
New feature or request
Comments
|
Great idea. Adding an auth method that relies on HTTP Headers should be straight forward. To make this even more flexible the headers should be completly configurable. Which Idenity Providers do support this nowadays? I know authentik does. |
redimp
changed the title
weaversam8
added a commit
to Phonebooth/otterwiki
that referenced
this issue
Mar 6, 2024
- This commit adds a new auth manager class for authorizing via proxy
headers `ProxyHeaderAuth` which can be selected by setting the
`AUTH_METHOD` env var to `PROXY_HEADER`
- This auth manager looks for the following headers in order to
create a "pseudo-user" on each request. No users are committed to
the SQLite database when using this auth manager.
- `X-OtterWiki-Name` - the name of the user to include on the
Git commit when editing a page
- `X-OtterWiki-Email` - the email of the user to include on the
Git commit when editing a page
- `X-OtterWiki-Permissions` - a comma separated list of
permissions to grant to the user
- The Docker `entrypoint.sh` script has been updated to pass the
`AUTH_METHOD` config option thru if set in the environment.
- `has_permission(permission, user)` is now a method specific to each
auth manager
- auth managers now implement a `supported_features()` method to detail
which features they support (like whether an auth manager allows a
user to change their name or password, or logout)
- the features object this method returns is present in all Jinja
templates as the variable `auth_supported_features`
- the settings page was updated to prevent a user from editing their
password and name if it is not supported by the current auth
manager.
- the dropdown menu present on all page was updated to hide the
"logout" button if it is not supported by the current auth manager
- The `test_settings.py` test was updated to tolerate extra whitespace
|
See #95 for a crack at solving this problem. |
redimp
pushed a commit
that referenced
this issue
Mar 10, 2024
- This commit adds a new auth manager class for authorizing via proxy
headers `ProxyHeaderAuth` which can be selected by setting the
`AUTH_METHOD` env var to `PROXY_HEADER`
- This auth manager looks for the following headers in order to
create a "pseudo-user" on each request. No users are committed to
the SQLite database when using this auth manager.
- `X-OtterWiki-Name` - the name of the user to include on the
Git commit when editing a page
- `X-OtterWiki-Email` - the email of the user to include on the
Git commit when editing a page
- `X-OtterWiki-Permissions` - a comma separated list of
permissions to grant to the user
- The Docker `entrypoint.sh` script has been updated to pass the
`AUTH_METHOD` config option thru if set in the environment.
- `has_permission(permission, user)` is now a method specific to each
auth manager
- auth managers now implement a `supported_features()` method to detail
which features they support (like whether an auth manager allows a
user to change their name or password, or logout)
- the features object this method returns is present in all Jinja
templates as the variable `auth_supported_features`
- the settings page was updated to prevent a user from editing their
password and name if it is not supported by the current auth
manager.
- the dropdown menu present on all page was updated to hide the
"logout" button if it is not supported by the current auth manager
- The `test_settings.py` test was updated to tolerate extra whitespace
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
OtterWiki currently authenticates users based on the sqlite database it maintains. If hosted in a corporate environment, it may be beneficial to install a reverse-proxy that handles authentication (with SSO, etc...) and then grants the user access to the wiki.
This is technically possible today, but you lost the semantics of tracking which user is editing the wiki. I'd like to propose a configuration option that would allow OtterWiki to use values provided by trusted HTTP headers instead. Maybe something like:
X-OtterWiki-Email- The email address of the userX-OtterWiki-Username- The "name" of the user attached to the commitX-OtterWiki-Role- The role of the user, to control access.The text was updated successfully, but these errors were encountered: