Apache with mod_shib and mod_proxy
Greg Haverkamp
gahaverkamp at lbl.gov
Wed May 16 15:46:05 EDT 2018
On Wed, May 16, 2018 at 10:32 AM, Jack Hill <jackhill at duke.edu> wrote:
> I'm interested in using mod_shib with Apache to serve applications via
> reverse proxy. I would like the shib SP to be able to pass along attributes
> to the application. The obvious (at last to me) way to do this is to pass
> the attributes via request headers. However, I've read the big warnings on
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSpoofChecking
> am reluctant to take that approach, and am interested in doing the work to
> avoid using request headers. Unfortunately, I'm not sure what that work is.
> Is it possible to to use shib in this way with a reverse proxy? If so, how?
> (In particular, I'm interested in reverse proxying Ruby's Puma webserver
> and also Tomcat via ajp://)
>
For AJP, you can use mod_proxy_ajp.
There was some considerable discussion on this recently in a tangentially
related thread:
http://shibboleth.1660669.n2.nabble.com/TIP-Apache-module-to-authenticate-a-NativeSPApacheConfig-to-the-backend-app-and-sign-attributes-tp7638629p7638654.html
If you're set on Puma vs uWSGI (Peter's recommendation in that post) with
mod_proxy_uwsgi, then my quick googling suggests no alternative to headers
for Puma, or something like the JWT approach that started the thread.
(There are other ways to add more assurance to the communications with
those headers, which Peter also suggests in there.)
(I don't have any personal recommendations for Ruby, but I did run a
production Python application on uWSGI for several years, and it never gave
me any problems.)
> Also, I don't think I fully understand the risk of using request headers.
> I understand that these can be set by an untrusted client, but I don't know
> why it is error-prone and risky to scrub the known headers that shib sets.
> Enlightenment on this topic would be appreciated.
>
As is so often the case with this sort of problem, can you think of
everything a wily attacker might come up with to fool the system?
Greg
>
> Best,
> Jack
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180516/276e0356/attachment.html>
More information about the users
mailing list