[Koha] Plack plus shibboleth

Discussion:

Dave Sherohman

2018-08-27 08:41:00 UTC

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.

--
Dave Sherohman
_______________________________________________
Koha mailing list http://koha-community.org
***@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/list

Katrin Fischer

2018-08-27 18:12:36 UTC

Permalink

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

Post by Dave Sherohman
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?
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
"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
***@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listi

Matthias Meusburger

2018-08-28 10:16:05 UTC

Permalink

Hi,

Using something like Plack::Auth::SSO::Shibboleth might provide a
solution to this problem.

https://metacpan.org/pod/Plack::Auth::SSO::Shibboleth

Post by Katrin Fischer
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

_______________________________________________
Koha mailing list http://koha-community.org
https://lists.katipo.co.nz/mailman/listinfo/koha

_______________________________________________
Koha mailing list http://koha-community.org
***@lists.katipo.co.nz
https://lists.katipo.co.nz/mailma

Dave Sherohman

2018-08-28 10:38:24 UTC

Permalink

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.

Hi,
Using something like Plack::Auth::SSO::Shibboleth might provide a solution
to this problem.
https://metacpan.org/pod/Plack::Auth::SSO::Shibboleth

Post by Katrin Fischer
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

_______________________________________________
Koha mailing list http://koha-community.org
https://lists.katipo.co.nz/mailman/listinfo/koha

--
Dave Sherohman
_______________________________________________
Koha mailing list http://koha-community.org
***@lists.katipo.co.nz
https://lists.ka

Tomas Cohen Arazi

2018-08-28 16:21:54 UTC

Permalink

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.

Post by Dave Sherohman
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
* 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.

Post by Matthias Meusburger
Hi,
Using something like Plack::Auth::SSO::Shibboleth might provide a

solution

Post by Matthias Meusburger
to this problem.
https://metacpan.org/pod/Plack::Auth::SSO::Shibboleth

Post by Katrin Fischer
Hi Dave,
I am not aware of a way to run Shibboleth with Plack in a safe way at

the