Bug 13932 - Allow a header to be considered trusted to provide the userid
Summary: Allow a header to be considered trusted to provide the userid
Status: Patch doesn't apply
Alias: None
Product: Koha
Classification: Unclassified
Component: Authentication (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Robin Sheat
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-31 00:27 UTC by Robin Sheat
Modified: 2024-03-09 15:59 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Medium patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 13932: add support for a trusted HTTP header (4.72 KB, patch)
2015-04-22 05:12 UTC, Robin Sheat
Details | Diff | Splinter Review
Bug 13932: unset userenv when using trusted header (1.30 KB, patch)
2015-04-29 05:28 UTC, Robin Sheat
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Sheat 2015-03-31 00:27:48 UTC
When Koha is placed behind an SSO system, it'd be useful to be able to get the user ID, like happens with basic auth.

This patch allows a header to be considered an authoritative source of user ID.

This only works with a plack-like environment, when apache is running Koha as CGI I think the headers come through using a different method.

An example configuration would be:

   <Location />
        ... mod_auth_mellon config goes here ...

	Header unset X_REMOTE_USER
	RequestHeader unset X_REMOTE_USER
	RequestHeader set X_REMOTE_USER %{MELLON_sfdcid}e
   </Location>

(REMOTE_USER seems to have a special use to apache that means it doesn't work, hence using X_REMOTE_USER.)

For testing, you can fake it by replacing the variable with something hardcoded and ignore all the SSO guff.
Comment 1 Robin Sheat 2015-04-22 05:12:42 UTC
Created attachment 38301 [details] [review]
Bug 13932: add support for a trusted HTTP header

This adds support for a 'trusted_header' option in koha-conf.xml that
specified an HTTP header that you trust that contains the userid. This
is to allow Koha to be behind a reverse proxy (for example, running
plack fronted by apache) that does user authentication/authorisation.

Note: for reasons I can't really tell, this doesn't work when apache is
running Koha as CGI, but does work under plack.

Test plan:
* have a koha-plack setup.
* configure apache to send it a header:
  RequestHeader set X_REMOTE_USER "testuserid"
* add <trusted_header>X_REMOTE_USER</trusted_header> to koha-conf.xml
* verify that the user behaves as though they're logged in.
Comment 2 Robin Sheat 2015-04-29 05:28:03 UTC
Created attachment 38627 [details] [review]
Bug 13932: unset userenv when using trusted header

As the trusted header system doesn't keep a session hanging around, when
running with plack it can end up with the userenv of another user, which
is bad. So this clears it forcing it to be recreated cleanly.
Comment 3 Chris Cormack 2016-03-06 21:31:43 UTC
fatal: sha1 information is lacking or useless (C4/Auth.pm).
error: could not build fake ancestor at ./getter.pl line 196.
Comment 4 Sven 2024-03-09 15:59:50 UTC
It would be really useful to get support for the REMOTE_USER environment variable as a way for authentication. This would at once enable support for many different authentication providers, for example mod_auth_openidc.