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 assumes the use of a WebDAV client that can be configured to send the HTTP credentials without being prompted by the server. If you need to accomodate true basic authentication prompts, the IdP configuration is much more complex and requires that you deploy container-managed authentication, or use Apache in front with the IdP's RemoteUser support.

Preconditions

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

Running Shibboleth Identity Provider.
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):

Identified not working clients (incomplete list):

Mac OS X built-in

Identity Provider

The V3 Identity Provider comes pre-configured with some support for basic authentication if the Password login flow is used. One of the RemoteUser-based flows can also be used, and can be run in first position to handle DAV clients while leaving the form-based option available for browser clients.

The Identity Provider must also support the SAML Artifact binding. It does so by default, but this feature is often disabled or left untested in clustered configurations.

Service Provider Setup

First, a special SessionInitiator for WebDAV is added into the relevant application definition's <Sessions> element, which:

allows only the redirect profile for authentication requests
specifies the artifact endpoint for responses

<SessionInitiator type="SAML2" id="WebDAVLogin" Location="/WebDAVLogin"
	entityID="https://idp.example.org/idp/shibboleth"
	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" />

Second, an example WebDAV resource is configured:

<VirtualHost webdav.example.org:443>
    <Location />
        Options +Indexes +MultiViews
        DAV on
        AuthType shibboleth
        ShibRequestSetting requireSession 1
		ShibRequestSetting requireSessionWith WebDAVLogin
		require valid-user
    </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.

Shibboleth 2 > WebDAV > webdav-login.png

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.

Shibboleth 2 > WebDAV > webdav-discovery.png

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.