Shibboleth (http://shibboleth.internet2.edu) integration enables de-coupling of user authentication and userID/attribute management functions from the Horde application service. As a result, the Horde service portal can be hosted on a site/domain that is separate from the identity and authentication service provider site. Usually, the userID/Authentication/Attribute provider site is the users home organization or a trusted site such as the http://protectnetwork.org site. The advantages of using Shibboleth have led to Shib-enablement of several web applications and creation of large trust federations worldwide.
This setup allows a Horde deployment running behind a Shibboleth SP to use the username set by Shibboleth in the HTTP headers. This is done with a custom authentication class, Auth_shibboleth, which implements transparent authentication and uses a configurable HTTP header as the source for the username.
In order to use the Shibboleth authentication driver, your server must be setup with a Shibboleth SP protecting the Horde application. For instructions on how to do this, please see the documentation at http://shibboleth.internet2.edu. In addition, your SP must be able to communicate with at least one IdP. You can setup your own or use a freely available IdP such as http://www.protectnetwork.org.
To setup the Shibboleth authentication driver, follow these steps:
1) Log in as an administrator and under Administration->Setup->Horde->Authentication, select Shibboleth Authentication
2) Enter the name of the HTTP header the Shibboleth SP uses to convey the username (e.g.: REMOTE_USER)
3) Auth_shibboleth can set a password credential in the session for use with hordeauth. Select the source of the password if you wish to use this functionality. See below for details.
Some Horde applications such as IMP and Gollem can be configured to use hordeauth to avoid duplicate logins, but that requires Horde to set a password credential in the session. However, since the authentication step is done remotely with Shibboleth (at the IdP), the SP may not have access to the user's password.
Several strategies can be implemented to work around this issue:
a) For IMP, you can configure your IMAP server to use one password (or no password) for all accounts and only allow access from certain machines (or local access). IMP can then be deployed in the privileged server and configured with the single IMAP password, thus having access to all mail accounts. Before deploying this solution, you should consider the security risks of running IMAP this way and ensure that your mail server is properly secured.
b) You can also add a new preference in Horde where users can enter their usernames and passwords for IMP and/or Gollem (much like the existing "Remote Servers" preferences) and configure Auth_shib to set a hordeauth password based on the custom preferences. IMP and Gollem can then be configured to use hordeauth for authentication. Some modifications to the redirect.php files may be necessary for smooth operation. You can download sample files with the necessary modifications for IMP at http://www.protectnetwork.org/prefs.tar. These files are for illustration purposes only. They are not guaranteed to work in your deployment without modifications.
c) The password to be used may be sent from the Shibboleth IdP as an attribute which the SP can place in a custom HTTP header. The name of the header that contains the password can be set by an administrator in the Authentication Setup screen.
Setting up Horde this way will not allow users to logout as usual due to the fact that Shibboleth 1.3 does not provide logout functionality. Clicking the logout button in Horde will log the user out of Horde, but the user will be logged in again immediately unless the Shibboleth session has expired. The only way to properly log out of the entire system is to close the browser. Shibboleth 2.0 will provide a single logout mechanism.