When a remote user comes knocking at Apache's door to request a document, Apache acts like the bouncer standing at the entrance to a bar. It asks three questions:
Is the bar open for business?
If the bar's closed, no one can come in. The patron is brusquely turned away, regardless of who he or she may be.
Is the patron who he or she claims to be?
The bouncer demands to see some identification and scrutinizes it for authenticity. If the ID is forged, the bouncer hustles the patron away.
Is this patron authorized to enter?
Based on the patron's confirmed identity, the bouncer decides whether this person is allowed in. The patron must be of legal drinking age and, in the case of a private club, must be listed in the membership roster. Or there may be arbitrary restrictions, such as "Ladies' Night."
In the context of the HTTP protocol, the first decision is known as "access control," the second as "authentication," and the third as "authorization." Each is the responsibility of a separate Apache handler which decides who can access the site and what they are allowed to see when they enter. Unlike the case of the bouncer at the bar, Apache access control and authentication can be as fine-grained as you need it to be. In addition to controlling who is allowed to enter the bar (web site), you can control what parts of the bar (partial URI paths) they're allowed to sit in, and even what drinks (individual URIs) they can order. You can ...