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 JNDI
- passwd can use LDAP via 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
You could leave a comment if you were logged in.