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.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

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

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

Setup

Identity Provider

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

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

handler.xml
<LoginHandler xsi:type="RemoteUser">
    <AuthenticationMethod>
        https://example.org/authenticationContext/myclass
    </AuthenticationMethod>
</LoginHandler>

Service Provider

First, a special SessionInitiator for WebDAV is configured, which

  • uses the redirect profile for authentication requests.
  • requires the basic authentication at the IdP.
  • uses the artifact profile for attribute consumption.
shibboleth2.xml
<SessionInitiator type="Chaining" Location="/WebDAVLogin" id="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:

Apache configuration
<VirtualHost webdav.example.org:443>
    <Location />
        Options +Indexes +MultiViews
        DAV on
        AuthType shibboleth
        ShibRequireSession On
        require valid-user
        ShibRequireSessionWith WebDAVLogin
    </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.

  • No labels