This page presents an approach how to protect WebDAV resources using Shibboleth.

An example configuration using the Shibboleth Service Provider together with Apache mod_dav is listed below. It is out of date and does not reflect modern approaches to configuring the SP.

Preconditions

Assure that the following requirements are meet if you you wish to setup this example:

• Running Shibboleth Identity Provider.
• Running Apache web server in front of the IdP.
• Running Shibboleth Service Provider.
• Running Apache web server with mod_shib and mod_dav.

Client

The used WebDAV client must support:

• HTTP redirects
• HTTP cookies

Identified working clients (incomplete list):

• Cyberduck
• Mozilla Firefox
• Microsoft Windows Web Folders

Identified not working clients (incomplete list):

• Mac OS X built-in

Setup

Identity Provider

First, Basic Authentication is enabled for the RemoteUser Login Handler:

<Location /idp/Authn/RemoteUser>
    AuthType Basic
    AuthName "Example Identity Provider Login”
    AuthBasicProvider ldap
    AuthLDAP ...
    require valid-user
</Location>

Second, the RemoteUser Login Handler is triggered by a special authentication context class (the class URI shown is an example and not suitable for use).

<LoginHandler xsi:type="RemoteUser">
    <AuthenticationMethod>
        https://example.org/authenticationContext/myclass
    </AuthenticationMethod>
</LoginHandler>

Service Provider

First, a special SessionInitiator for WebDAV is configured, which

• uses the redirect profile for authentication requests.
• requires the basic authentication at the IdP.
• uses the artifact profile for attribute consumption.

<SessionInitiator type="Chaining" Location="/WebDAVLogin" id="WebDAVLogin"
  entityID="https://idp.example.org/idp/shibboleth"
  target="https://webdav.example.org/">
    <SessionInitiator type="SAML2"
      acsIndex="6" <!-- urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact -->
      template="bindingTemplate.html"
      outgoingBindings="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
      authnContextClassRef="https://example.org/authenticationContext/myclass" />
</SessionInitiator>

Second, an example WebDAV resource is configured:

<VirtualHost webdav.example.org:443>
    <Location />
        Options +Indexes +MultiViews
        DAV on
        AuthType shibboleth
        ShibRequireSession On
        require valid-user
        ShibRequireSessionWith WebDAVLogin
    </Location> 
</VirtualHost>

Client

The figure of Cyberduck shows the login to WebDAV resource using the defined default IdP. Note that Cyberduck
displays the hostname as well as the realm of the IdP.

Discovery

An open issue is, how to solve the discovery problem. A possible solution is to work with aliases to retrieve and set the IdP
selection:

Alias /idp.example2.org /
<Location /idp.example2.org>
    ShibRequestSetting entityID https:///idp.example2.org/idp/shibboleth
</Location>

Alias /idp.example3.org /
<Location /idp.example3.org>
    ShibRequestSetting entityID https:///idp.example3.org/idp/shibboleth
</Location>

Note that the path is only used to determine the the IdP, both points to the same resource path.

The figure below shows Cyberduck with some IdPs configured as bookmarks.

Probably there is a more sophisticated solutions using rewrites or other ideas.

The idea is to use a script to read the federation metadata and generate the appropriate Apache conf file automatically.