April 23, 2019

Security and Apache: An Essential Primer - page 3

Maxwell's Demon and Hat Colour

  • February 21, 2000
  • By Ken Coar
In terms of discretionary control mechanisms on the Web, each protected area, whether it be a single document or an entire server, is called a realm. When a server challenges a client for credentials, it provides the name of the realm so the client can figure out which credentials to send.

The name of a realm is specified in the Apache configuration files with the AuthName directive, which takes a single argument: the name of the realm.

Note: In older versions of Apache, the entire remainder of the line following the "AuthName" keyword was taken to be the realm name. This caused problems when someone embedded a quotation mark (") in the string, since in the actual HTTP protocol the realm name is quoted. So more recent versions of Apache accept only a single argument to the directive; if you want to use multiple words, like "This is my realm", you need to enclose the entire string within quotation marks so that it will look like a single 'word.'

Realm names are implicitly qualified by the URL to which they apply, and subordinate URLs are implicitly part of the same realm. This means that if <URL:http://foo.com/a/> is in realm "Augh", then <URL:http://foo.com/a/b/c/foo.html> is also in realm "Augh" unless it's been overridden.

The implicit qualification also means that even if <URL:http://foo.com/a/foo.html> and <URL:http://foo.com/b/foo.html> are declared in two separate statements as being in realm "Foo", they're actually two different realms named "Foo". The only way they'd both be in the same "Foo" realm is if they had a common ancestor that was (such as <URL:http://foo.com/>).

The qualification rules will cause the client to prompt for credentials whenever it requests a document in a realm it hasn't visited before -- even if it's visited a different realm with the same name.

There is no default for the AuthName directive, except what might be inherited from an upper-level directory.

The Client/Server Authentication Handshake
When a client first attempts to access a document that's under some sort of discretionary access control, a lot goes on behind the scenes that the end-user probably never sees. Since on the first attempt the client won't know that the resource is protected, it won't include any credentials. When the server receives the request, it will go through all the authorized phases of access checking; when the credentials (none) don't match any that are valid for the resource, the server will return a "not authorized" status.

In almost all cases, a client that receives a "not authorized" response will realize that it didn't send any credentials and will pop up a dialogue box for the end-user to complete. This box will display the name of the realm in which the document resides, and ask the user for a username and password. Once obtained, the client will make the same request again, only this time it will include the credentials. But as far as the end user is aware, that first request was completely invisible and never happened.

If the client gets a "not authorized" status in response to a request that included credentials, it typically responds a little differently: it will probably tell the user, "those credentials weren't accepted, want to try again?" It didn't say that the first time because it hadn't sent any.

In either case, if the end user opts to not fill in the dialogue and presses cancel, the client typically just displays the error page that the server sent along with the "not authorized" status and goes back to waiting for instructions.

Most Popular LinuxPlanet Stories