Apache/HTTP/Zugriffsrechte/Mehr

Mehr als nur Autorisierung

Die Art und Weise, wie die Autorisierung angewendet werden kann, ist jetzt viel flexibler als nur eine einzelne Prüfung gegen einen einzelnen Datenspeicher.

• Ordnung, Logik und die Wahl, wie die Autorisierung durchgeführt werden soll, sind jetzt möglich.

Anwenden von Logik und Reihenfolge

Die Kontrolle darüber, wie und in welcher Reihenfolge die Autorisierung durchgeführt wird, war in der Vergangenheit ein ziemliches Rätsel.

• In Apache 2.2 wurde ein anbieterbasierter Authentifizierungsmechanismus eingeführt, um den eigentlichen Authentifizierungsprozess von der Autorisierung und den unterstützenden Funktionen zu entkoppeln.
• Einer der Nebeneffekte war, dass die Authentifizierungsanbieter konfiguriert und in einer bestimmten Reihenfolge aufgerufen werden konnten, die nicht von der Ladereihenfolge des Auth-Moduls selbst abhing.
• Derselbe Provider-basierte Mechanismus wurde auch für die Autorisierung übernommen.
• Das bedeutet, dass die Require-Direktive nicht nur angibt, welche Autorisierungsmethoden verwendet werden sollen, sondern auch die Reihenfolge, in der sie aufgerufen werden.
• Mehrere Autorisierungsmethoden werden in der gleichen Reihenfolge aufgerufen, in der die Require-Direktiven in der Konfiguration erscheinen.

Mit der Einführung von Autorisierungs-Container-Direktiven wie <RequireAll> und <RequireAny> hat die Konfiguration auch die Kontrolle darüber, wann die Autorisierungsmethoden aufgerufen werden und welche Kriterien bestimmen, wann der Zugriff gewährt wird.

• Siehe Authorization Containers für ein Beispiel, wie sie verwendet werden können, um komplexe Autorisierungslogik auszudrücken.

Standardmäßig werden alle Require-Direktiven so behandelt, als wären sie in einer <RequireAny>-Container-Direktive enthalten.

• Mit anderen Worten: Wenn eine der angegebenen Autorisierungsmethoden erfolgreich ist, wird die Autorisierung erteilt.

Verwendung von Autorisierungsanbietern für die Zugriffskontrolle

Die Authentifizierung mit Benutzername und Passwort ist nur ein Teil der Geschichte.

• Häufig möchte man Personen auf der Grundlage anderer Kriterien als ihrer Identität Zugang gewähren.
• Zum Beispiel, woher sie kommen.

Mit den Berechtigungsanbietern all, env, host und ip können Sie den Zugriff auf der Grundlage anderer hostbasierter Kriterien wie dem Hostnamen oder der IP-Adresse des Rechners, der ein Dokument anfordert, erlauben oder verweigern.

Die Verwendung dieser Provider wird durch die Direktive Require festgelegt.

• Diese Direktive registriert die Autorisierungsanbieter, die während der Autorisierungsphase der Anfrageverarbeitung aufgerufen werden.

Zum Beispiel:

 Require ip <var>address</var>

wobei Adresse eine IP-Adresse (oder eine Teil-IP-Adresse) oder ist:

 Require host <var>domain_name</var>

wobei domain_name ein voll qualifizierter Domänenname (oder ein teilweiser Domänenname) ist; Sie können mehrere Adressen oder Domänennamen angeben, falls gewünscht.

Wenn Sie zum Beispiel jemanden haben, der Ihr Forum spammt, und Sie ihn davon abhalten wollen, könnten Sie Folgendes tun:

<RequireAll>
 Require all granted
 Require not ip 10.252.46.165
</RequireAll>

Besucher, die von dieser Adresse kommen, können den von dieser Richtlinie abgedeckten Inhalt nicht sehen.

• Wenn Sie stattdessen einen Rechnernamen statt einer IP-Adresse haben, können Sie diesen verwenden.

<RequireAll>
 Require all granted
 Require not host host.example.com
</RequireAll>

Und wenn Sie den Zugriff von einer ganzen Domäne aus blockieren möchten, können Sie auch nur einen Teil einer Adresse oder eines Domänennamens angeben:

<RequireAll>
 Require all granted
 Require not ip 192.168.205
 Require not host phishers.example.com moreidiots.example
 Require not host ke
</RequireAll>

Die Verwendung von <RequireAll> mit mehreren <Require>-Direktiven, die jeweils mit not negiert werden, erlaubt den Zugriff nur, wenn alle negierten Bedingungen wahr sind.

• Mit anderen Worten, der Zugriff wird blockiert, wenn eine der verneinten Bedingungen nicht erfüllt ist.

Zugriffskontrolle Rückwärtskompatibilität

Einer der Nebeneffekte der Einführung eines providerbasierten Mechanismus für die Authentifizierung ist, dass die früheren Zugriffskontrolldirektiven Order, Allow, Deny und Satisfy nicht mehr benötigt werden.

• Um jedoch Abwärtskompatibilität für ältere Konfigurationen zu gewährleisten, wurden diese Direktiven in das Modul mod_access_compat verschoben.

Hinweis

Die Direktiven von mod_access_compat sind durch mod_authz_host veraltet.

• Das Mischen von alten Direktiven wie Order, Allow oder Deny mit neuen wie Require ist technisch möglich, aber nicht empfehlenswert.
• Das Modul mod_access_compat wurde erstellt, um Konfigurationen zu unterstützen, die nur alte Direktiven enthalten, um das 2.4 Upgrade zu erleichtern.
• Für weitere Informationen lesen Sie bitte die Upgrade-Anleitung.

Authentifizierungs-Caching

Es kann vorkommen, dass die Authentifizierung eine inakzeptable Belastung für einen Anbieter oder Ihr Netzwerk darstellt.

• Dies betrifft am ehesten Benutzer von mod_authn_dbd (oder von Drittanbietern/angepassten Providern).
• Um dieses Problem zu lösen, führt HTTPD 2.3/2.4 einen neuen Caching-Provider mod_authn_socache ein, der die Anmeldedaten zwischenspeichert und die Belastung des/der Ursprungsprovider(s) reduziert.

Dies kann für einige Benutzer eine erhebliche Leistungssteigerung bedeuten.

Weitere Informationen

Sie sollten auch die Dokumentation für mod_auth_basic und mod_authz_host lesen, die weitere Informationen darüber enthalten, wie das Ganze funktioniert.

• Die Direktive <AuthnProviderAlias> kann auch helfen, bestimmte Authentifizierungskonfigurationen zu vereinfachen.

Die verschiedenen Chiffren, die der Apache für Authentifizierungsdaten unterstützt, werden in Passwortverschlüsselungen erläutert.

Sie können auch einen Blick in die Anleitung zur Zugriffskontrolle werfen, in der eine Reihe verwandter Themen behandelt wird.