I'm not claiming that I understand the workflow, but just chiming in
hoping that this may be useful. One approach with Shibboleth is to have
a separate endpoint/path that handles the authentication after returning
from the Shibboleth handler. In other words, if normal login is at
/cgi-bin/koha/opac-user.pl, there could be something like
/cgi-bin/koha/opac-login-shibboleth.pl where the user is redirected when
coming back from Shibboleth. There's no need for the Shibboleth session
information to be available outside of this single path, since it
establishes the normal session. Then that script would be the only one
that needs to run outside Plack and even require Shibboleth in Apache
config, which improves performance [1].
--Ere
[1] Especially on a busy site using "require shibboleth" in the general
Apache config means that mod_shib connects to shibd on every request,
and you may notice shibd using quite a few CPU cycles.
Renvoize, Martin kirjoitti 17.9.2018 klo 18.36:
Sorry I've not got to this earlier,
I'm languishing on that bug due to lack of funding/interest.
You are entirely correct that there is no way to use environment variables
when using apache merely as a proxy to plack, and that any middlewares etc
just obfuscate this further moving it up the chain rather than actually
resolving the problem.
Tomas's suggestion of running just the authentication piece under CGI mode
may work, although as this is called inside get_template_and_user on every
request I'm not sure how it could happen short of basically turning off
plack on everything.
The final direction I was going to take was to add some sort of shared
signature to the headers which I believe is recommended by the shibboleth
folks themselves. This signature would need to be verified within Koha
before accepting that the header has come from the Shibboleth service
provider package and not through the client.
Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30
The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at [email protected]
On Tue, 28 Aug 2018 at 17:23, Tomas Cohen Arazi <[email protected]>
wrote:
I'm not familiar with the protocol workflow, but can't we just run some
bits in CGI mode to avoid this? (I imagine this is about the callback PL).
We already do this for other stuffs.
El mar., 28 de ago. de 2018 07:39, Dave Sherohman <[email protected]>
escribió:
Plack::Auth::SSO::Shibboleth appears to fall into the "just pushes the
issue back a level... without actually solving the core issue" from my
original post. Quoting the P::A::S::S docs,
---
The real authenticating module lives inside the Apache web server, and
is called "mod_shib".
<snip>
There are two ways to transfer the attributes from mod_shib to the
application:
* the application lives inside Apache (CGI, FCGI). The attributes are
sent as environment variables. This is the default situation, and the
most secure.
* the application is a separate server, and Apache merely a proxy
server. The attributes are sent as headers. This is less secure.
This module merely convert these attributes.
---
Also, in the example "setup behind proxy" config, you can see that the
apache configuration includes "ShibUseHeaders On".
So it would appear that the module might be useful for receiving the
http headers from mod_shib and converting them to environment variables,
thus allowing koha to use them without needing to modify the koha code,
but it does not appear to eliminate the need to use http headers in the
first place.
Of course, if anyone has actually used P::A::S::S and knows otherwise,
I'm happy to be corrected on that point.
On Tue, Aug 28, 2018 at 12:16:05PM +0200, Matthias Meusburger wrote:
Hi,
Using something like Plack::Auth::SSO::Shibboleth might provide a
solution
to this problem.
https://metacpan.org/pod/Plack::Auth::SSO::Shibboleth
Le 27/08/2018 à 20:12, Katrin Fischer a écrit :
Hi Dave,
I am not aware of a way to run Shibboleth with Plack in a safe way at
the
moment, but would also be very interested in seeing this resolved.
It's
a
rather big issue for academic libraries here.
Katrin
On 27.08.2018 10:41, Dave Sherohman wrote:
Hey, all!
tl;dr: When running koha under plack and using shibboleth
authentication, what is the currently-recommended way to communicate
auth details from mod_shib to koha?
Long version:
I'm in the process of converting our Koha installation from running
under vanilla CGI to using plack/starman. This was simple enough
from
the perspsctive of straight-up library functionality, but we're using
shibboleth to authenticate against the campus IDP, and that has
raised
a
few issues.
We've already found
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17776 in
the
bug tracker and I have successfully adapted the patch tou our
customized
C4::Auth/C4::Auth_with_shibboleth and logged in via shibboleth, but
(as
noted in the bug tracker discussion) this uses HTTP headers to
communicate the authentication details to the back-end application.
In order to avoid possible vulnerabilities resulting from the use of
HTTP headers, I went to the shibboleth documentation at
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSpoofChecking
[1] and, in the section for Apache, found the assertion that:
"Under no circumstances should you rely on the request header option
other than as a temporary measure while adjusting applications to use
the environment option. There are no known scenarios in which
environment variables can't be used"
Is there a way to use environment variables in a plack+shibboleth
installation? The docs assert that it should be possible (as there
are
"no known scenarios" where it isn't), but that would imply that one
process (apache) is able to modify the environment of another,
already-
running, independent non-child process (starman) running under a
different uid/gid, which should not generally be possible - and, even
if
it is possible, it would require apache to run as root, which would
create major security risks of its own.
The bug tracker discussion includes a brief mention of possibly
using a
plack middleware to change the worker process envoronment, but that
seems like it would just push the issue back a level from "how do I
talk
to starman without using http headers" to "how do I talk to the
middleware without using http headers" without actually solving the
core
issue.
Is it actually possible to use environment variables in this
scenario?
If not, what's the best practice to secure it against http header
spoofing?
[1] The SHIB2 documentation states that it's no longer supported, but
we're using an sp2 shibd and, in any case, the same text appears
verbatim on the equivalent SP3 page.
_______________________________________________
Koha mailing list http://koha-community.org
[email protected]
https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________
Koha mailing list http://koha-community.org
[email protected]
https://lists.katipo.co.nz/mailman/listinfo/koha
--
Dave Sherohman
_______________________________________________
Koha mailing list http://koha-community.org
[email protected]
https://lists.katipo.co.nz/mailman/listinfo/koha
--
Tomás Cohen Arazi
Theke Solutions (https://theke.io <http://theke.io/>)
✆ +54 9351 3513384
GPG: B2F3C15F
_______________________________________________
Koha mailing list http://koha-community.org
[email protected]
https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________
Koha mailing list http://koha-community.org
[email protected]
https://lists.katipo.co.nz/mailman/listinfo/koha
--
Ere Maijala
Kansalliskirjasto / The National Library of Finland
_______________________________________________
Koha mailing list http://koha-community.org
[email protected]
https://lists.katipo.co.nz/mailman/listinfo/koha
