Differences between revisions 20 and 21
Revision 20 as of 2013-05-30 09:20:39
Size: 3919
Editor: pmeier
Comment:
Revision 21 as of 2013-06-26 06:56:16
Size: 5799
Editor: mreimers
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
= Security =
Line 7: Line 6:
If you want to publish material over a secure connection (SSL - Secure Sockets Layer), you '''have to''' create a directory within `public_html` called `secure` and place the material in there. This site is then accessible via `https://people.ee.ethz.ch/~username/`. Note though that the SSL protocol needs more resources than the normal HTTP protocol, so only put material in this subdirectory which really has to be transferred encrypted. If you want to publish material over a secure connection (SSL - Secure Sockets Layer), you '''have to''' create a directory within `public_html` called `secure` and place the material in there. This site is then accessible via `https://people.ee.ethz.ch/~username/`. Note though that the SSL protocol needs more resources than the normal HTTP protocol, so only put material in this sub directory which really has to be transferred encrypted.
Line 9: Line 8:
Also note that local users can see what is in your `public_html/secure` directory by walking through the file system. Some hiding is possible through the use of `chmod 711 secure` but it's nothing to be proud of. The only way to get some level of protection locally is to use a cgi in the `public_html/secure` directory which is only readable and executable for you, and then use this cgi as a gateway to publish other documents also stored with permisions 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.

== Protecting your pages with a password ==
It's possible to protect your pages with a password. Follow these steps to configure authentication for a subdirectory within your `public_html ` directory:

1. Create a directory, for example: `mkdir ~/public_html/protected`.

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

{{{
AuthType Basic
AuthName "Protected Area"
AuthUserFile /home/joe/.htpasswd
Require valid-user
}}}
3. Create the password file in your home-dir with the `htpasswd` utility:

{{{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`).

4. Test your page in the browser. If it doesn't work as expected Apache's error log (`/usr/galen/netvar/apache/logs/error_log.people`) might give a clue.

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.

== Restricting access to a directory to defined unix groups ==
The following `.htaccess` file enables all users of group `isgee` to access your website-directory (after authentication): Read more about htaccess-files [[http://httpd.apache.org/docs/2.0/howto/htaccess.html|here]].
Also note that local users can see what is in your `public_html/secure` directory by walking through the file system. Some hiding is possible through the use of `chmod 711 secure` but it's nothing to be proud of. The only way to get some level of protection locally is to use a CGI in the `public_html/secure` 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.
Line 38: Line 11:
{{{
Order deny,allow
Deny from All
== 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.
Line 42: Line 15:
AuthName "Internal Area"
AuthType Basic
AuthBasicProvider ldap
This approach is also implemented by Apache's htaccess configuration directives. E.g.
 * Authentication: AuthBasicProvider directive
 * Authorization: Require directive
Line 46: Line 19:
AuthzLDAPAuthoritative on
AuthLDAPURL "ldaps://ldaps-hit-2.ethz.ch ldaps-rz-2.ethz.ch ldaps-hit-1.ethz.ch ldaps-rz-1.ethz.ch/ou=users3,ou=itet,ou=auth,o=ethz,c=ch?uid?one"
AuthLDAPBindDN "cn=YOUR_PROXY_USER,ou=admins,ou=itet,ou=auth,o=ethz,c=ch"
AuthLDAPBindPassword PROXY_USERs_PASSWORD
== Website Protection ==
=== LOCAL vs. LDAP ===
There are two different "databases" access control can work with:
Line 51: Line 23:
# Access by group membership
AuthLDAPGroupAttribute memberUid
AuthLDAPGroupAttributeIsDN off
Require ldap-group cn=GROUPNAME,ou=groups,ou=itet,ou=auth,o=ethz,c=ch
Satisfy any
}}}
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".
Line 58: Line 25:
To see all defined groups and their members, execute: `getent group` === Local Password File ===
Follow these steps to configure access control for a sub directory within your `public_html/secure` directory:
Line 60: Line 28:
The LDAP-DN of the wanted group then is: `cn=groupname,ou=groups,dc=isg,dc=ee`  1. Create a directory, for example: `mkdir ~/public_html/secure/mySecureWebsite`.
Line 62: Line 30:
For more details on LDAP-Authentication, check this[[http://httpd.apache.org/docs/2.0/mod/mod_auth_ldap.html|documentation]] for mod_auth_ldap.  2. Create a `.htaccess` file in this directory with the following content:
 {{{
 AuthType Basic
 AuthName "Protected Area"
 AuthUserFile /home/<UserName>/.htpasswd
 Require valid-user
 }}}

 3. Create the password file in your home-dir with the `htpasswd` utility:
 {{{
 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`).

 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.

 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.

 6. Read more about htaccess files [[http://httpd.apache.org/docs/2.2/howto/htaccess.html|here]].


=== LDAP Directory Service ===
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.

 1. Header
 {{{
 Order deny,allow
 Deny from All
 }}}

 2. Authentication
 {{{
 AuthType Basic
 AuthName "YOUR LOGIN Text"
 AuthBasicProvider ldap
 AuthzLDAPAuthoritative on
 }}}


 3. 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=users3,ou=itet,ou=auth,o=ethz,c=ch?uid?one"
 }}}

 4. 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).
  a. Primary Group
  {{{
  Require ldap-attribute gidNumber=<GidNumber>
  }}}
 
  b. Secondary Group
  {{{
  AuthLDAPGroupAttribute memberUid
  AuthLDAPGroupAttributeIsDN off
  Require ldap-group cn=<GroupName>,ou=groups,ou=itet,ou=auth,o=ethz,c=ch
  }}}

  c. Valid user (i.e. no further authorization, valid authentication is sufficient)
  {{{
  Require valid-user
  }}}

  d. List of of allowed users
  {{{
  Require ldap-user <user1> <user2>
  }}}

 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]].


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

Secure Webserver

If you want to publish material over a secure connection (SSL - Secure Sockets Layer), you have to create a directory within public_html called secure and place the material in there. This site is then accessible via https://people.ee.ethz.ch/~username/. Note though that the SSL protocol needs more resources than the normal HTTP protocol, so only put material in this sub directory which really has to be transferred encrypted.

Also note that local users can see what is in your public_html/secure directory by walking through the file system. Some hiding is possible through the use of chmod 711 secure but it's nothing to be proud of. The only way to get some level of protection locally is to use a CGI in the public_html/secure 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.

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.

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 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".

Local Password File

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

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

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

     AuthType Basic
     AuthName "Protected Area"
     AuthUserFile /home/<UserName>/.htpasswd
     Require valid-user
  3. Create the password file in your home-dir with the htpasswd utility:

     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).

  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.

  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.

  6. 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 5 different sections. All sections together are setting up the entire htaccess file.

  1. Header
     Order deny,allow
     Deny from All 
  2. Authentication
     AuthType Basic
     AuthName "YOUR LOGIN Text"
     AuthBasicProvider ldap
     AuthzLDAPAuthoritative on
  3. 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=users3,ou=itet,ou=auth,o=ethz,c=ch?uid?one"
  4. 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).
    • Primary Group
        Require ldap-attribute gidNumber=<GidNumber>
      b. Secondary Group
        AuthLDAPGroupAttribute memberUid
        AuthLDAPGroupAttributeIsDN off
        Require ldap-group cn=<GroupName>,ou=groups,ou=itet,ou=auth,o=ethz,c=ch
      c. Valid user (i.e. no further authorization, valid authentication is sufficient)
        Require valid-user
      d. List of of allowed users
        Require ldap-user <user1> <user2> 
  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 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)