[Koha] Plack plus shibboleth

Tomas Cohen Arazi tomascohen at gmail.com
Wed Aug 29 04:21:54 NZST 2018


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 <dave at sherohman.org>
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
> > >Koha at lists.katipo.co.nz
> > >https://lists.katipo.co.nz/mailman/listinfo/koha
> > _______________________________________________
> > Koha mailing list  http://koha-community.org
> > Koha at lists.katipo.co.nz
> > https://lists.katipo.co.nz/mailman/listinfo/koha
>
>
> --
> Dave Sherohman
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> 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


More information about the Koha mailing list