Although closely related, it is important to differentiate between authorization and authentication. Authentication is the process of verifying if someone is the one he pretends to be, while authorization means checking if an identified person or machine is permitted to access a resource. An HTTP server first checks if access to a resource is restricted. If the restriction applies to persons, it requests authentication data from the client to check the user's identity. After that it checks if the authorization rules grant access to the resource for this user.
Access to a resource can be restricted to the domain or network address of the browser machine or to a particular person or group of persons. Apache determines this by parsing the global and local configuration files. If permitted by the administrator, web authors can restrict access to their documents via local configuration files which are usually named .htaccess (hypertext access).
Authorization rules can combine machine and person access. They apply to resources and to HTTP methods (e.g. disallow POST for unknown users). For further information on administration, take a look at the configuration section 3.2.1.
There are many ways of checking the identity of a person who controls the browser sending an HTTP request:
When a request applies to a protected resource, Apache sends a 401 unauthorized response to the client. This is done to inform the client that he has to supply authentication information within his requests. Along with the 401 response the server sends the realm, the corresponding protected area of the website.
A browser then prompts the user for authentication data (username and password). Afterwards, the client repeats the request including the new authentication data. This data is transmitted in HTTP header fields.
Since HTTP is a stateless protocol, authentication data must be retransmitted in every request. The browser normally keeps the authentication information for the duration of the browser session. For every request concerning the same realm, the browser sends the stored authentication information (see Figure 2.8).
Generally, HTTPS should always be used for transmitting authentication data.
Basic authentication is the simplest method of authentication. Although the password may be stored encrypted on the server, the browser transmits user name and password without encryption. This means, anyone listening can get the username and password, especially since they are re-sent with every request. In addition to this, the requested content is sent without encryption as well.
The solution to the problem is to use basic authentication together with encryption on the TCP layer, namely SSL. Together with HTTP, this is called HTTPS and assures that any information sent over the network is encrypted. See below in section 2.4.3.
Digest authentication provides an alternative way of authentication, addressing the problem of transmitting authentication data in clear text.
The browser sends a hash value of the password and other information, an MD5 Digest, to the server. However, this method is still vulnerable to a man-in-the-middle attack.
Concluding, digest authentication is more secure than basic authentication, but not completely secure. Therefore it is rarely used. The consequence is the usage of HTTPS. For additional information on authentication look at http://httpd.apache.org/docs/howto/auth.html.
Browsers usually support basic authentication. Other methods require additional software at the server side. There are several other possibilities to handle authentication data:
There is, for example, the possibility to enter authentication information into HTML forms. This information is afterwards passed to the server with HTTP POST, in the body of the request. This is different to basic authentication where the authentication data is sent in the header of the request. A CGI program can then perform the authentication check.
Another possibility is the usage of Java applets or JavaScript code. The server sends a Java applet or JavaScript code to the client. The browser executes the code which asks for authentication data and sends it to the server in an arbitrary way.
Both methods need additional software at the HTTP server to do authentication. This could for example be a CGI script that handles the content of a POST request. Additionally, as before, HTTPS is needed for a secure transmission of the data.
Security summarizes the problem of people eavesdropping the information sent. As credit card information and passwords have to be sent over the Internet, securing and therefore usually encrypting traffic becomes more important.
Authentication summarizes techniques that make sure the communication partner is who he pretends to be. It therefore helps to prevent man-in-the-middle attacks. A shopping portal or bank web site should be able to clearly identify itself, before it asks for any private information.
For securing connections either symmetric or public/private key algorithms can be used. With symmetric key algorithms both communication partners need the same key to encrypt and decrypt the data. That imposes a problem, as the key has to be transmitted from one partner to the other before secure communication can begin. Secure transfer of the symmetric key has to be accomplished using other security mechanisms.
Public/private key mechanisms are based on two different keys. One communication partner publishes the public key to anyone wishing to communicate. The public key is used to encrypt messages that only the owner of the private key can decrypt. Employing that technique on both sides can secure a two-way connection.
Symmetric key mechanisms usually require a smaller processing overhead than public key mechanisms. Therefore public key securing mechanisms are often used to securely transmit a symmetric key with a short validity. That secures the whole data transmission and minimizes processing overhead.
Authenticity is more complex to accomplish. A certificate authority issues a certificate which can be checked for its validity using the certificate of the Certificate Authority. After being requested to authenticate, the communication partner will supply a certificate which can be verified using the certificate authority. Therefore the communication partner can be sure of the identity of the entity providing the certificate. However the communication partner still needs to be sure of the identity of the Certification Authority. Therefore a few companies are regarded as generally trusted authorities and any client has a list of those trusted authorities. Additional authorities that are not generally trusted have to supply a certificate for themselves that was issued by another authority that is either generally trusted or again has a certificate by a trusted authority. A new authority will therefore only need a certificate from a trusted authority to be able to issue certificates itself. A client might have to check a chain of certificates until it reaches a trusted authority that can issue a certificate for itself.
To make sure the certificate is not stolen, public/private key mechanisms are used together with the certificate. The certificate owner will provide an encrypted text using a private key that only the certificate owner is supposed to have. The certificate authority keeps the certificate including the public key but does not have knowledge about the private key. However the supplied text can be decrypted using the public key of the certificate. Therefore if the partner claiming to own the certificate can encrypt that text he is the owner of the private key and therefore must be the entity he claims to be. Also when authenticating web servers any certificate includes a domain name. A server can only be authenticated if it can be reached via the domain name specified in the certificate.
SSL is a protocol which can be used together with any reliable data transfer protocol like TCP. It employs mechanisms that provide Security and Authentication. SSL employs public key mechanisms to exchange symmetric session keys which are then used to encrypt any transmitted data. Certificates are used to ensure authentication. The combination of HTTP and SSL is generally referred to as secured HTTP or HTTPS. By default it uses port 443 instead of the standard HTTP port 80. Browsers will indicate to the user that a secure connection is in use and will also notify the user in case a certificate has expired or any other situation occurred that made the establishment of a secure connection impossible.
HTTPS uses certificates to publish and verify the public key that is used to exchange the symmetric key. Therefore in an HTTPS handshake, first the client requests the server's certificate, checks that against the Certificate Authority's certificate and uses the contained public key to verify the server's identity. The key is also used to exchange a ``pre master secret'' which is used to create the symmetric key, also referred to as the ``master secret''. At the end of the handshake each communication partner informs the other that future transfer will be encrypted and starts the HTTP session.
SSL-secured HTTP connections can be reused within a certain period of time to reduce the overhead that the identification check and the tunnel creation imposes.
Today SSL is used in almost any Web Application that involves payment or private information. Almost any eCommerce website and any online banking application that is based on HTTP uses SSL to secure the connection.
SSL can be used to secure any protocol using TCP. The SSL handshake requires additional actions from client and server, so establishing an SSL connection can not be transparent to the application. A solution is to replicate server ports by tunneling the TCP connection through a SSL connection.
Even though SSL also supports client authentication which allows the web server to clearly identify the client as a person, it is rarely used, as a client certificate is required. Client certificates require the person wanting to be clearly identified to buy a certificate at a certification authority. As hardly any company wants to force their customers to spend money just to be able to buy their products, usually username and password based methods are used to identify the client. However, the transmission of the user name and password is usually secured using SSL.
 |
Apache Modeling Portal 2004-10-29 |
