Differences between revisions 25 and 39 (spanning 14 versions)
⇤ ← Revision 25 as of 2018-09-25 10:59:49 →
Size: 5567
Editor: pmeier
Comment:
← Revision 39 as of 2023-10-16 13:45:59 → ⇥
Size: 5368
Editor: alders
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
#rev 2020-08-31 alders
Line 9: Line 11:
Also note that local users can see what is in your `public_html` directory by walking through the file system. All files in a normal static html website must be readable by the webserver and so they are readable for every user who has access to the filesystem, where your home is placed. The only way to get some level of protection locally is to use a CGI in the `public_html` directory which is only readable and executable for you, and then use this CGI as a gateway to publish other documents also stored with permissions only readable to you. This again is no real protection for the fact that your material lies on the disk as plain files. So anybody with root access can read the files. To get around this problem the files would have to be encrypted and your CGI would have to decrypt them on the fly when delivering. This is still not really secure, but about as good as it gets with this setup. Also note that local users can see what is in your `public_html` directory by walking through the file system. All files in a normal static html website must be readable by the webserver and so they are readable for every user who has access to the filesystem, where your home is placed. The only way to get some level of protection locally is to use a CGI in the `public_html` directory which is only readable and executable for you, and then use this CGI as a gateway to deliver documents also stored with permissions only readable to you.
Line 17: Line 19:
 * Authentication: AuthBasicProvider directive
 * Authorization: Require directive		  * Authentication: {{{AuthBasicProvider}}} directive
 * Authorization: {{{Require}}} directive
Line 24: Line 26:
You should use LDAP if access control should be based on registered D-ITET user and groups. On the other hand, an independent access control based on self defined users (e.g. for non D-ITET user) is archived best using a LOCAL "database". You should use LDAP if access control should be based on registered D-ITET users and groups. On the other hand, an independent access control based on self defined users (e.g. for non D-ITET users) is achieved best using a LOCAL "database".
Line 27: Line 29:
Follow these steps to configure access control for a sub directory within your `public_html/secure` directory: Follow these steps to configure access control for a sub directory within your `public_html` directory:

 1. {{{htpasswd}}} can only be found on {{{people}}} hence you need to login there first ({{{ssh people}}}). As an alternative solution you could use a [[http://aspirine.org/htpasswd_en.html|web-based variant]] which implemented the htpasswd command in javascript (make sure to generate an '''SHA-1''' Hash!)
Line 31: Line 35:
 2. Create a `.htaccess` file in this directory with the following content:  1. Create a `.htaccess` file in this directory with the following content:
Line 39: Line 43:
 3. Create the password file in your home-dir with the `htpasswd` utility:  1. Create the password file in your home-directory with the `htpasswd` utility (installed on the webservers):
Line 46: Line 50:
 4. Test your page in the browser. If it doesn't work as expected Apache's error log (`/var/log/apache2/error_log.people_ee_ssl @ people.ee.ethz.ch`) might give a clue.  1. Test your page in the browser. If it doesn't work as expected Apache's error log (`/var/log/apache2/error_log.people_ee_ssl @ people.ee.ethz.ch`) might give a clue.
Line 48: Line 52:
 5. Additional users/passwords can be added with `htpasswd -s ~/.htpasswd anotheruser`. Additionally, it's possible to use different password files for different subdirectories or files, for example `~/.htpasswd01` for directory `~/public_html/bla01` and `~/.htpasswd02` for directory `~/public_html/bla02` - it all depends on your needs.  1. Additional users/passwords can be added with `htpasswd -s ~/.htpasswd anotheruser`. Additionally, it's possible to use different password files for different subdirectories or files, for example `~/.htpasswd01` for directory `~/public_html/bla01` and `~/.htpasswd02` for directory `~/public_html/bla02` - it all depends on your needs.
Line 50: Line 54:
 6. Read more about htaccess files [[http://httpd.apache.org/docs/2.2/howto/htaccess.html|here]].  1. Read more about htaccess files [[https://httpd.apache.org/docs/2.4/howto/htaccess.html|here]].
Line 54: Line 58:
For access control against registered D-ITET users and groups a more complex htaccess file is needed based on 5 different sections. All sections together are setting up the entire htaccess file. For access control against registered D-ITET users and groups a more complex htaccess file is needed based on three different sections. All sections together are setting up the entire htaccess file.
Line 56: Line 60:
 1. Header
 {{{
 Order deny,allow
 Deny from All
 }}}

 2. Authentication		  1. Authentication
Line 69: Line 67:

3. Anonymous LDAP Binding		  1. Anonymous LDAP Binding
Line 76: Line 73:
 4. Authorization  1. Authorization
Line 78: Line 75:
  a. Primary Group
  {{{
  Require ldap-attribute gidNumber=<GidNumber>
  }}}
Line 83: Line 76:
  b. Secondary Group   a. By group:
Line 90: Line 83:
  c. Valid user (i.e. no further authorization, valid authentication is sufficient)   b. By user:
  {{{
  Require ldap-user <user1> <user2>
  }}}

 c. Valid user (i.e. no further authorization, valid authentication against the LDAP server is sufficient)
Line 95: Line 93:
  d. List of of allowed users
  {{{
  Require ldap-user <user1> <user2>
  }}}		 Necessary group information, i.e. the group name can be retrieved by executing 'getent group' on an ISG D-ITET manged Linux client.
Line 100: Line 95:
 5. Footer
 {{{
 Satisfy any
 }}}

Necessary group information, i.e. group name (GID) and its corresponding number (gidNumber) can be retrieved by executing 'getent group' on an ISG.EE manged Linux client.

Read more about LDAP authentication and authorization [[http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html|here]].		 Read more about LDAP authentication and authorization [[https://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html|here]].

Contents

  1. Secure Webserver
  2. Authentication and Authorization
  3. Website Protection
    1. LOCAL vs. LDAP
    2. Local Password File
    3. LDAP Directory Service
  4. File Permissions

Secure Webserver

You can access your personal homepage over http or https. Both protocols have the webbroot in the public_html subdirectory of your home.

Also note that local users can see what is in your public_html directory by walking through the file system. All files in a normal static html website must be readable by the webserver and so they are readable for every user who has access to the filesystem, where your home is placed. The only way to get some level of protection locally is to use a CGI in the public_html directory which is only readable and executable for you, and then use this CGI as a gateway to deliver documents also stored with permissions only readable to you.

Authentication and Authorization

While speaking about access control one must distinguish between authentication and authorization. Authentication is the process of verifying that "you are who you say you are", authorization is the process of verifying that "you are permitted to do what you are trying to do". Authorization thus requires authentication.

This approach is also implemented by Apache's htaccess configuration directives. E.g.

  • Authentication: AuthBasicProvider directive

  • Authorization: Require directive

Website Protection

LOCAL vs. LDAP

There are two different "databases" access control can work with:

You should use LDAP if access control should be based on registered D-ITET users and groups. On the other hand, an independent access control based on self defined users (e.g. for non D-ITET users) is achieved best using a LOCAL "database".

Local Password File

Follow these steps to configure access control for a sub directory within your public_html directory:

  1. htpasswd can only be found on people hence you need to login there first (ssh people). As an alternative solution you could use a web-based variant which implemented the htpasswd command in javascript (make sure to generate an SHA-1 Hash!)

  2. Create a directory, for example: mkdir ~/public_html/mySecureWebsite.

  3. Create a .htaccess file in this directory with the following content: 

     AuthType Basic
 AuthName "Protected Area"
 AuthUserFile /home/<UserName>/.htpasswd
 Require valid-user

  4. Create the password file in your home-directory with the htpasswd utility (installed on the webservers): 

     touch ~/.htpasswd && htpasswd -s ~/.htpasswd anyuser

    htpasswd will prompt for the new password (yes, htpasswd has a -c switch for creating a new file, but since it's pretty easy to inadvertently erase an existing file this way I recommend using the approach with touch).

  5. Test your page in the browser. If it doesn't work as expected Apache's error log (/var/log/apache2/error_log.people_ee_ssl @ people.ee.ethz.ch) might give a clue.

  6. Additional users/passwords can be added with htpasswd -s ~/.htpasswd anotheruser. Additionally, it's possible to use different password files for different subdirectories or files, for example ~/.htpasswd01 for directory ~/public_html/bla01 and ~/.htpasswd02 for directory ~/public_html/bla02 - it all depends on your needs.

  7. Read more about htaccess files here.

LDAP Directory Service

For access control against registered D-ITET users and groups a more complex htaccess file is needed based on three different sections. All sections together are setting up the entire htaccess file.

  1. Authentication 
     AuthType Basic
 AuthName "YOUR LOGIN Text"
 AuthBasicProvider ldap
  2. Anonymous LDAP Binding

    Anonymous access to the LDAP server is allowed on ITET's managed offline replica (i.e update once per day) only. Direct access to ID's LDAP Service is restricted to special proxy users. A personal proxy user for staff and proj accounts can be requested (support@ee.ethz.ch) for some special cases if anonymous access is not sufficient. 

     AuthLDAPURL "ldaps://ldap02.ee.ethz.ch ldap01.ee.ethz.ch/ou=users,ou=itet,ou=auth,o=ethz,c=ch?uid?one"
  3. Authorization
    • The authorization depends on your needs. Here are some examples for common setups. Combination of authorization methods is also possible (defaults to a logical OR).
    • By group: 
        AuthLDAPGroupAttribute memberUid
  AuthLDAPGroupAttributeIsDN off
  Require ldap-group cn=<GroupName>,ou=custom,ou=groups,ou=nethz,ou=id,ou=auth,o=ethz,c=ch
      b. By user: 
        Require ldap-user <user1> <user2>
      c. Valid user (i.e. no further authorization, valid authentication against the LDAP server is sufficient) 
        Require valid-user

Necessary group information, i.e. the group name can be retrieved by executing 'getent group' on an ISG D-ITET manged Linux client.

Read more about LDAP authentication and authorization here.

File Permissions

While using anonymous LDAP binding no special file permissions are needed A simple chmod 644 .htaccess should be fine.

CategoryWEBS

Web/Homepage/Security (last edited 2023-10-16 13:45:59 by alders)