metamod:security_plans

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
metamod:security_plans [2008-11-27 09:49:43]
heikok
metamod:security_plans [2022-05-31 09:29:32] (current)
Line 7: Line 7:
 | Administration of Tomcat | http://server:XXXX/manager | BasicAuth-tomcat | tomcat-users-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 |http://server/upl | metamod | metamod-file |
-| Access to upload-environment |ftp://server | passwd | /etc/shadow +| Access to upload-environment |ftp://server | passwd | PAM-configured 
-| Administration of Metamod-server | ssh:server | passwd | /etc/shadow |+| Administration of Metamod-server | ssh:server | passwd | PAM-configured |
  
 ===== Wishlist ===== ===== Wishlist =====
Line 26: Line 26:
   * //BasicAuth-apache// can be connected to LDAP via http://httpd.apache.org/docs/2.0/mod/mod_auth_ldap.html   * //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]]   * //BasicAuth-tomcat// can be connected to LDAP via [[http://java.sun.com/products/jndi/|JNDI]]
-  * //passwd// can be replaced with LDAP via [[http://www.saas.nsw.edu.au/solutions/ldap-auth-pam.html|PAM]]+  * //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//.   * //metamod-file// needs some development. Simplest to switch to //BasicAuth-apache//.
  
Line 43: Line 43:
   * 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 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 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 =====
  
-==== Changes needed ==== +==== BasicAuth for /upl ====
- +
-=== BasicAuth for /upl ===+
  
   * .htaccess protection for all /upl/* pages   * .htaccess protection for all /upl/* pages
Line 53: Line 53:
   * Only username known to metamod $_SERVER{REMOTE_USER} after login, not institution/working directory. This information should be stored in another place.   * 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 ===+==== (Optional) upload-area per user ====
  
   * each user should have a user-directory, where he can upload files via ftp   * each user should have a user-directory, where he can upload files via ftp
  • metamod/security_plans.1227779383.txt.gz
  • Last modified: 2022-05-31 09:23:19
  • (external edit)