Team LiB
Previous Section Next Section

Security and Authorization

The standard HTTP header mechanism also provides the core of the standard HTTP security mechanism. A secure document transaction happens as follows:

1.
The client (browser) requests a document using a standard GET method. At this point the client does not know that the document is protected by security.

2.
Access to the document is denied using a 301 header. Along with the 401 header, the server sends the required authorization method that should be used in the response (the WWW-Authenticate header).

3.
The browser responds to the 301 header by displaying to the user a credentials dialog box for entering a username and password.

4.
The user fills in a username and password (the credentials) and submits them. The browser sends them back to the server with an authorization header.

5.
If the credentials are accepted, the requested document is sent to the browser. If the credentials are denied, the user will be given the credentials dialog box again to retype them.

Although there are multiple authorization schemes in HTTP, the only one in common use is called BASIC authentication. Under this scheme the authorization header takes the following form:

Authorization: SCHEME REALM

The term SCHEME would be replaced by BASIC and the term REALM is replaced by an encoded form of credentials.

This is in the format of username:password encoded using a base64 algorithm. Suppose that your username was sjohnson and your password was duckduckgoose. Applying a base64 encoding algorithm to them would give an Authorization header of

Authorization: Basic c2pvaG5zb246ZHVja2R1Y2tnb29zZQ==

Beyond HTTP Basic authentication, there is also Digest authentication. Even though HTTP basic authentication is "encoded," it's not actually secure, because the realm is transmitted in the clear (the encoding masks but does not really hide the username and password). Although Digest authentication is technically more secure, most Web browsers do not support it, leading most websites to not support it.

Beyond traditional HTTP-based security, which is implemented at the Web server layer, application-level security is implemented by the application developer. These approaches generally tend to use cookies to contain the user credentials. A key benefit to not using HTTP security is that it gives the application developer full control over the look and feel of the login forms.

NOTE

If you need to experiment with Base64 encoding, see http://makcoder.sourceforge.net/demo/base64.php.


    Team LiB
    Previous Section Next Section