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.

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):

• Cyberduck
• Mozilla Firefox
• Microsoft Windows Web Folders

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, but it requires that the client volunteer the username/password. One of the RemoteUser-based flows can also be used to support clients that can't offer credentials without a prompt (with appropriate web server configuration for authentication), 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.

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.