====== Change of Authentication in Metamod 2.X ======

===== Overview of Metamod authorization and authentication  before 2.1 =====

^ Type ^ Access ^ Authentication ^ Password-store ^
| Administration of Metamod | http://server/adm | BasicAuth-apache | .htaccess-file |
| Administration of Tomcat | http://server:XXXX/manager | BasicAuth-tomcat | tomcat-users-file |
| Access to upload-environment |http://server/upl | metamod | metamod-file |
| Access to upload-environment |ftp://server | passwd | PAM-configured |
| Administration of Metamod-server | ssh:server | passwd | PAM-configured |

===== Wishlist =====

The current implementation has some drawback, which are addressed by the following wishlist:

  - one password store should be enough
  - authentication methods security-level should be industry standard compliant
  - single sign on

===== Idea =====

==== Password storage ====

Using a directory server for authentication. The directory server needs to support user, passwords and groups. This can be i.e. any LDAP server. 

  * //BasicAuth-apache// can be connected to LDAP via http://httpd.apache.org/docs/2.0/mod/mod_auth_ldap.html
  * //BasicAuth-tomcat// can be connected to LDAP via [[http://java.sun.com/products/jndi/|JNDI]]
  * //passwd// can use LDAP via [[http://www.saas.nsw.edu.au/solutions/ldap-auth-pam.html|ldap_pam]]
  * //metamod-file// needs some development. Simplest to switch to //BasicAuth-apache//.

==== Industry Standard compliance ====

  * //BasicAuth// is industry standard, with moderate to low security (depending on https).
  * ftp is industry standard, with low security.
  * ssh is industry standard, with moderate security.
  * //metamod// security is not tested. Metamod-application authentication will require lots of testing to become comparable to industry-standard. Simplest to switch to //BasicAuth-apache//.


==== Single Sign On ====

** No solution! ** Evaluated:

  * Using Kerberos, requires kerberos-support from client-side, i.e. http://negotiateauth.mozdev.org/ . Since client-side support usually does not exist, supporting it on the server is useless.
  * Using SAML, that is SSO on application-level. This will be hard to impossible to implement since we don't have control of Thredds, ssh and ftp.
  * Using tomcat within apache (mod_jk, mod_proxy), having same security realm. This would be a good solution for SSO on the http-side (simply having one application), but might require extra care when setting up protection for one data-catalog, which can be seen from apache as up to 3 (eventually more) http-pathes (opendap, http, WCS).

===== Changes needed =====

==== BasicAuth for /upl ====

  * .htaccess protection for all /upl/* pages
  * Registration and password changes outside /upl
  * Only username known to metamod $_SERVER{REMOTE_USER} after login, not institution/working directory. This information should be stored in another place.

==== (Optional) upload-area per user ====

  * each user should have a user-directory, where he can upload files via ftp


~~DISCUSSION~~