The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

WebDAV

Owned by Former user (Deleted)
Last updated: Jun 01, 2016 by Scott Cantor
3 min read

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

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
shibboleth2.xml
<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:

Apache configuration
<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:

Apache configuration
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.