#user_shibboleth

user_shibboleth is an ownCloud user authentication app relying on the Shibboleth Service Provider.

At the current stage, this project is only intended to serve as a starting point for reimplementation and as an example for federated authentication in a PHP + Apache + mod_shib + Shibboleth2 environment, in general.

###Deployment

If you have downloaded the app folder as a zip file from github, rename the app folder from "user_shibboleth-master" to "user_shibboleth".

Assuming a running configuration of Apache and the Shibboleth SP, some additional changes are required in order to protect the /owncloud location via lazy Shibboleth authentication.

• Configuring Apache:

  The following Location directive must be added to the VirtualHost configuration for HTTPS connections. Usually this would be in /etc/apache2/sites-available/default-ssl.

  <Location /owncloud>
      AuthType shibboleth
      Require shibboleth
      RewriteRule ^apps/user_shibboleth/login.php - [L]
  </Location>

• Configuring Shibboleth:

  Next, add the new path in /etc/shibboleth/shibboleth2.xml like this:

  <RequestMapper type="Native">
      <RequestMap applicationId="default">
          <Host name="example.com">
              <Path name="owncloud" authType="shibboleth" requireSession="false"/>
          </Host>
     </RequestMap>
  </RequestMapper>

  Take care to use the server's actual host name.

  While you have the shibboleth2.xml file open, write down the values of both the handlerURL attribute of the Sessions node and the Location attribute of the SessionInitiator node, as these must be specified on the app's settings menu.

  The app requires two user attributes, auEduSharedPersonToken and mail, so make sure that the nodes with those ids are uncommented in /etc/shibboleth/attribute-map.xml.

The user_shibboleth app itself can be installed and enabled just like any other ownCloud app.

Fill in the two transcribed values from the SP configuration file on the app settings page, save, and you are done.

###Mapping Internal Users to LDAP User Accounts

If your ownCloud installation uses the LDAP User and Group Backend, then chances are, that the connected LDAP server is also used for authenticating users in the SP's Shibboleth federation. A single user could then create two ownCloud user accounts, one via the LDAP backend and one via the Shibboleth backend. We refer to these kinds of users as internal. External users, on the other hand, are those users who are only retrievable from the Shibboleth backend.

To prevent internal users from creating secondary accounts, check the Link to LDAP Backend checkbox. Internal users will then always use their LDAP backend account, irrespective of the way they log into the system.

The user mapping is based on the Shibboleth and LDAP mail attributes. This allows a malicious IdP to hijack mapped user accounts by authenticating users with spoofed email addresses. To prevent this and other kinds of user impersonation, it is strongly recommended to check the Enforce Domain Similarity checkbox. This way users whose email address domain part does not match the domain of their respective IdP are rejected.

At the moment the internal user mapping feature only works with the first configured LDAP server.

###Version History

0.5      - mapping users to LDAP accounts 
0.5.0.1  - improved LDAP user authentication
0.5.0.2  - accomodating PHP/DBS combinations returning SQL COUNT(*) as a string value