Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

Identified not working clients (incomplete list):

  • Mac OS X built-in

...

Identity Provider

The V3 Identity Provider

...

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

Code Block
titleApache configuration
<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>

...

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 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
  • specifies the artifact profile endpoint for attribute consumption.responses
Code Block
xml
xml
titleshibboleth2.xml
<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:

Code Block
titleApache configuration
<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>

...