...

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 SPassumes 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 Apache web server in front of the IdP.Running Shibboleth Service Provider.
• Running Apache web server with mod_shib and mod_dav.

...

Identified not working clients (incomplete list):

• Mac OS X built-in

...

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>

...

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 configuredadded into the relevant application definition's <Sessions> element, which:

• uses allows only the redirect profile for authentication requests.
• requires the basic authentication at the IdP.
• uses the artifact profile for attribute consumption.specifies the artifact endpoint for responses

<SessionInitiator type="ChainingSAML2" Locationid="/WebDAVLogin" idLocation="/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
        ShibRequireSessionShibRequestSetting OnrequireSession 1
		ShibRequestSetting requireSessionWith      WebDAVLogin
		require valid-user
        ShibRequireSessionWith WebDAVLogin
    </Location> 
</VirtualHost>

...