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.
Assure that the following requirements are meet if you you wish to setup this example:
The used WebDAV client must support:
Identified working clients (incomplete list):
Identified not working clients (incomplete list):
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> |
First, a special SessionInitiator
for WebDAV is configured, which
<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> |
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.
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.