Protect single sub directory (Moodle) with SP reverse proxy

352 views
Skip to first unread message

Schnyder Stefan (schf)

unread,
Jul 16, 2011, 1:28:44 PM7/16/11
to us...@shibboleth.net

Hello Shibboleth Users

 

I’m stuck with having Moodle authenticate over Shibboleth and I can’t really pin down the problem.

 

We have a ServiceProvider reverse proxy setup (using ApplicationOverride). The SP is version 2.4.2. Currently there is one service running on it and Moodle shall be the second.

The Apache reverse proxy (Apache is version 2.2.3) listens to service.domain.ch, then sends the user to authenticate over Shibboleth (-> WAYF -> IdP -> SP) and if successful uses ProxyPass to redirect the user to the actual web server (service-intern.domain.ch)

 

To use Shibboleth with Moodle one has to protect only a single directory, which is: /auth/shibboleth/

 

I’ve configured the Moodle virtual host to do that. But I get an error. When I click on the ‘Login’ link (which points to https://elearning.zhaw.ch/moodle/auth/login/index.php) I get redirected to the WAYF service (so far, so good) and I can select my HomeOrganization. When I hit enter, I don’t reach the IdP but instead get the following message: 404 - The requested URL /Shibboleth.sso/DS was not found on this server.

 

I can verify that the IdP as well as the SP reverse proxy work as they should when I protect the whole Moodle domain with Shibboleth or a test page in another folder. Meaning I get through the Shibboleth authentication process (I’m not logged in, in Moodle though).

 

What confuses me is, that somehow the redirection between SP - WAYF - IdP doesn’t work, when only protecting the /auth/shibboleth/ directory, but that does work when protecting the whole domain (which is not the goal). Also I don’t get the error message.

 

Would someone be able to help me understand what’s going on?

Browsing to http://elearning.zhaw.ch/moodle and clicking on the ‘Login’ link in the upper right corner will send you to the WAYF service.  There select ZHAW (or anything else) to see the actual problem. The following will be produced in the log:

 

[Sat Jul 16 19:15:27 2011] [error] [client 160.85.104.32] File does not exist: /var/www/elearning/Shibboleth.sso, referer: https://wayf.switch.ch/SWITCHaai/WAYF?entityID=https%3A%2F%2Felearning.zhaw.ch%2Fshibboleth&return=https%3A%2F%2Felearning.zhaw.ch%2FShibboleth.sso%2FDS%3FSAMLDS%3D1%26target%3Dcookie%253Ae298e589

 

Following are the configuration cut-outs of the different files involved in the process.

 

/etc/shibboleth/shibboleth2.xml

----------------------------------------------------------------------------------------------

<ApplicationOverride id="aaisandbox" entityID="https://aaisandbox.zhaw.ch/shibboleth">

    <CredentialResolver type="File" key="/etc/pki/tls/private/aaisandbox.key" certificate="/etc/pki/tls/certs/aaisandbox.pem"/>

</ApplicationOverride>

 

<ApplicationOverride id="elearning" entityID="https://elearning.zhaw.ch/shibboleth">

    <CredentialResolver type="File" key="/etc/pki/tls/private/elearning.key" certificate="/etc/pki/tls/certs/elearning.crt"/>

</ApplicationOverride>

----------------------------------------------------------------------------------------------

 

 

/etc/apache2/zhaw.d/vhost_elearning.conf

----------------------------------------------------------------------------------------------

Listen 160.85.104.29:80

<VirtualHost 160.85.104.29:80>

 

    ServerName elearning.zhaw.ch

    ServerAdmin servi...@zhaw.ch

 

    <Location />

        Options -Indexes +FollowSymLinks

        Order deny,allow

        Allow from all

    </Location>

 

    ProxyRequests off

    ProxyPass / http://elearning-intern.zhaw.ch/

    ProxyPassReverse / http://elearning-intern.zhaw.ch/

    ProxyPreserveHost On

 

    ErrorLog logs/elearning.error.log

    CustomLog logs/elearning.access.log common

 

</VirtualHost>

 

Listen 160.85.104.29:443

<VirtualHost 160.85.104.29:443>

 

    ServerName elearning.zhaw.ch

    ServerAdmin servi...@zhaw.ch

 

    <Location />

        Options -Indexes +FollowSymLinks

        Order allow,deny

        Allow from all

    </Location>

 

    <Location /moodle/auth/shibboleth/>

        AuthType shibboleth

        ShibRequireSession On

        ShibRequestSetting applicationId elearning

#       ShibUseHeaders On

        Require valid-user

    </Location>

 

    SSLEngine On

    SSLCertificateFile /etc/pki/tls/certs/elearning.crt

    SSLCertificateKeyFile /etc/pki/tls/private/elearning.key

    SSLCertificateChainFile /etc/pki/tls/certs/qvsslica.crt

 

    SSLProxyEngine on

    ProxyRequests off

    ProxyPass / http://elearning-intern.zhaw.ch/

    ProxyPassReverse / http://elearning-intern.zhaw.ch/

    ProxyPreserveHost On

 

    ErrorLog logs/elearning.error.log

    CustomLog logs/elearning.access.log common

 

</VirtualHost>

----------------------------------------------------------------------------------------------

 

Any help would be very much appreciated.

 

Thanks in advance,

Stefan

 

--
To unsubscribe from this group, send email to
users+un...@shibboleth.net

Cantor, Scott E.

unread,
Jul 16, 2011, 1:46:13 PM7/16/11
to us...@shibboleth.net
On 7/16/11 1:28 PM, "Schnyder Stefan (schf)" <sc...@zhaw.ch> wrote:
>To use Shibboleth with Moodle one has to protect only a single directory,
>which is: /auth/shibboleth/
>
>I¹ve configured the Moodle virtual host to do that. But I get an error.
>When I click on the ŒLogin¹ link (which points to
>https://elearning.zhaw.ch/moodle/auth/login/index.php) I get redirected
>to the WAYF service (so far, so good) and I can select my
>HomeOrganization. When I hit enter, I don¹t reach the IdP but
> instead get the following message: 404 - The requested URL
>/Shibboleth.sso/DS was not found on this server.

I don't spend time trying to understand the things people do with proxies,
and I won't here, but basically you need to make sure all the requests are
being handled by the appropriate boxes. It's probably passing, or not
passing, the Shibboleth handler requests along in one case vs. the other.

Just make sure /Shibboleth.sso/Session or /Status or any of the other
handlers are working correctly, and the DS handler should work as well.
You don't have to work out the entire SSO flow head of time to check basic
request handling is in place.

-- Scott

Lukas Hämmerle

unread,
Jul 20, 2011, 4:39:35 AM7/20/11
to us...@shibboleth.net
> I've configured the Moodle virtual host to do that. But I get an
> error. When I click on the 'Login' link (which points to
> https://elearning.zhaw.ch/moodle/auth/login/index.php) I get
> redirected to the WAYF service (so far, so good) and I can select my
> HomeOrganization. When I hit enter, I don't reach the IdP but instead
> get the following message: 404 - The requested URL /Shibboleth.sso/DS
> was not found on this server.

The main problem in this case was that on the proxy host no requests for
/Shibboleth.sso/ were processed by mod_shib for a VirtualHost where only
a particular path (/moodle/auth/shibboleth/) had to require a Shib
session. Therefore, the user got a 404 after returning from the
Discovery Service. So, this problem was not directly related to the
proxy configuration.

The solution was to use a directive that makes mod_shib also handle the
/ location (without requiring a Shib session) and not only
/moodle/auth/shibboleth/

This then looked like:

-----------------------8<-----------------------------
<Location />
AuthType shibboleth
ShibRequestSetting applicationId elearning
require shibboleth

Order allow,deny
Allow from all
</Location>

<Location /moodle/auth/shibboleth/>
AuthType shibboleth
ShibRequireSession On
ShibRequestSetting applicationId elearning
ShibUseHeaders On
require valid-user
</Location>
-----------------------8<-----------------------------

However, what I don't quite understand is that this first of the above
rule is required at all. So far I assumed that mod_shib is handling all
requests to /Shibboleth.sso if this is the handlerURL configured in
shibboleth2.xml. However, in this particular case with a web server
hosting multiple VirtualHosts with different IPs, it really needed the
<Location /> directive to make mod_shib to handle the /Shibboleth.sso
requests.

Kind Regards
Lukas


--
SWITCH
Serving Swiss Universities
--------------------------
Lukas Hämmerle, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 64, fax +41 44 268 15 68
lukas.h...@switch.ch, http://www.switch.ch

Cantor, Scott E.

unread,
Jul 20, 2011, 9:51:18 AM7/20/11
to us...@shibboleth.net
On 7/20/11 4:39 AM, "Lukas Hämmerle" <lukas.h...@switch.ch> wrote:
>
>The main problem in this case was that on the proxy host no requests for
>/Shibboleth.sso/ were processed by mod_shib for a VirtualHost where only
>a particular path (/moodle/auth/shibboleth/) had to require a Shib
>session. Therefore, the user got a 404 after returning from the
>Discovery Service. So, this problem was not directly related to the
>proxy configuration.

I have not seen a case where that was required. The handler in Apache 2
runs on every single request no matter what the URL. In this case,
something else had to be interfering with that.

>However, what I don't quite understand is that this first of the above
>rule is required at all. So far I assumed that mod_shib is handling all
>requests to /Shibboleth.sso if this is the handlerURL configured in
>shibboleth2.xml. However, in this particular case with a web server
>hosting multiple VirtualHosts with different IPs, it really needed the
><Location /> directive to make mod_shib to handle the /Shibboleth.sso
>requests.

shibboleth2.xml has no involvement in whether Apache runs a module or not,
that's up to it. In my experience, all unhandled requests to any URL end
up hitting mod_shib's handler hook if nothing else has handled the
request. Then I do the path check and use handlerURL and logic to
determine if I should actually handle it. In your case, something else was
handling that path.

What you "fix" by doing what you did is shortcut the handler invocation by
getting it to run out of the check_user hook.

-- Scott
Reply all
Reply to author
Forward
0 new messages