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
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.
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@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
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@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Dave Sherohman
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@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.
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
On Tue, Aug 28, 2018 at 12:16:05PM +0200, Matthias Meusburger wrote: 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@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Dave Sherohman _______________________________________________ Koha mailing list http://koha-community.org Koha@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
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 info@ptfs-europe.com On Tue, 28 Aug 2018 at 17:23, Tomas Cohen Arazi <tomascohen@gmail.com> 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 <dave@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.
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
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
On Tue, Aug 28, 2018 at 12:16:05PM +0200, Matthias Meusburger wrote: the 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@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Dave Sherohman _______________________________________________ Koha mailing list http://koha-community.org Koha@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 _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
https://metacpan.org/pod/Mojolicious::Plugin::SAML is another option, but also relies on us switching away from Apache + Plack entirely and rather letting hypnotoad act as the server itself and doing away with the native service provider package entirely too.. but those are real long game goals ;) *Martin Renvoize* Development Team Manager *T:* +44 (0) 1483 378728 *F:* +44 (0) 800 756 6384 *E:* martin.renvoize@ptfs-europe.com www.ptfs-europe.com <https://www.ptfs-europe.com> 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 info@ptfs-europe.com On Mon, 17 Sep 2018 at 16:36, Renvoize, Martin < martin.renvoize@ptfs-europe.com> wrote:
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 info@ptfs-europe.com
On Tue, 28 Aug 2018 at 17:23, Tomas Cohen Arazi <tomascohen@gmail.com> 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 <dave@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.
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
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
On Tue, Aug 28, 2018 at 12:16:05PM +0200, Matthias Meusburger wrote: the 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@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Dave Sherohman _______________________________________________ Koha mailing list http://koha-community.org Koha@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 _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
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 info@ptfs-europe.com
On Tue, 28 Aug 2018 at 17:23, Tomas Cohen Arazi <tomascohen@gmail.com> 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 <dave@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.
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
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
On Tue, Aug 28, 2018 at 12:16:05PM +0200, Matthias Meusburger wrote: the 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@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Dave Sherohman _______________________________________________ Koha mailing list http://koha-community.org Koha@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 _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Ere Maijala Kansalliskirjasto / The National Library of Finland
Yeah, Tomas' suggestion gave me a similar idea, of creating a standalone CGI shim which doesn't load any of the full koha infrastucture (it could probably be self-contained, using no Koha::*/C4::* modules at all) and just receives the shib tokens, then writes them into a database (or memcached), where a plack middleware can retrieve them securely and put them into the backend server's environment, without having to pass them through HTTP headers. Since then, I've also been looking at documentation on running shib authentication for clustered services (we have two koha servers behind a load balancer and, at one point, I thought the lb's sticky sessions had failed) and found that shib itself can be configured to store its state in an ODBC database or a memcached cache, which could potenially open up the possibility of a plack middleware that would pull the auth info directly from shibd's state, leaving mod_shib only responsible for performing the authentication transaction, without also needing to transmit the results of that transaction to the application. Your idea of a CGI endpoint which just creates the koha session, then passes control off to the main application is probably cleaner than either of the possibilities I came up with, though. On Tue, Sep 18, 2018 at 04:48:59AM +0300, Ere Maijala wrote:
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 info@ptfs-europe.com
On Tue, 28 Aug 2018 at 17:23, Tomas Cohen Arazi <tomascohen@gmail.com> 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 <dave@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.
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
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
On Tue, Aug 28, 2018 at 12:16:05PM +0200, Matthias Meusburger wrote: the 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@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Dave Sherohman _______________________________________________ Koha mailing list http://koha-community.org Koha@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 _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Ere Maijala Kansalliskirjasto / The National Library of Finland _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Dave Sherohman
We use the ODBC driver with shibd, but I would advise against using that as the data source. The data is internal to Shibboleth and you'd have to accept the risk accompanied with trying to parse it. And then you'd still have to relay the Shibboleth session identifier somehow. --Ere Dave Sherohman kirjoitti 18.9.2018 klo 12.07:
Yeah, Tomas' suggestion gave me a similar idea, of creating a standalone CGI shim which doesn't load any of the full koha infrastucture (it could probably be self-contained, using no Koha::*/C4::* modules at all) and just receives the shib tokens, then writes them into a database (or memcached), where a plack middleware can retrieve them securely and put them into the backend server's environment, without having to pass them through HTTP headers.
Since then, I've also been looking at documentation on running shib authentication for clustered services (we have two koha servers behind a load balancer and, at one point, I thought the lb's sticky sessions had failed) and found that shib itself can be configured to store its state in an ODBC database or a memcached cache, which could potenially open up the possibility of a plack middleware that would pull the auth info directly from shibd's state, leaving mod_shib only responsible for performing the authentication transaction, without also needing to transmit the results of that transaction to the application.
Your idea of a CGI endpoint which just creates the koha session, then passes control off to the main application is probably cleaner than either of the possibilities I came up with, though.
On Tue, Sep 18, 2018 at 04:48:59AM +0300, Ere Maijala wrote:
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 info@ptfs-europe.com
On Tue, 28 Aug 2018 at 17:23, Tomas Cohen Arazi <tomascohen@gmail.com> 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 <dave@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.
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
> 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
On Tue, Aug 28, 2018 at 12:16:05PM +0200, Matthias Meusburger wrote: the 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@lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Dave Sherohman _______________________________________________ Koha mailing list http://koha-community.org Koha@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 _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Ere Maijala Kansalliskirjasto / The National Library of Finland _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Ere Maijala Kansalliskirjasto / The National Library of Finland
participants (6)
-
Dave Sherohman -
Ere Maijala -
Katrin Fischer -
Matthias Meusburger -
Renvoize, Martin -
Tomas Cohen Arazi