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