WWW-Zugriffsrechte
Stand: 01.08.2012
Diese Zugriffsrechte werden wie die anderen eigenen Einstellungen mit den Dateien .htaccess und .htsslaccess sowie .htssoaccess (jeweils mit Punkt am Anfang) im obersten Verzeichnis des jeweiligen Verzeichnisbaumes gesteuert.
- Beim Zugang über http://www.uni-muenster.de/NNN/ wird nur die Datei .htaccess beachtet.
- Beim Zugang über https://www.uni-muenster.de/NNN/ wird nur die Datei .htsslaccess beachtet. (Falls diese Datei überhaupt nicht existiert, wird doch .htaccess beachtet.)
- Beim Zugang über https://sso.uni-muenster.de/NNN/ oder https://xsso.uni-muenster.de/NNN/ oder https://ssso.uni-muenster.de/NNN/ wird nur die Datei .htssoaccess beachtet. (Falls diese Datei überhaupt nicht existiert, wird doch .htsslaccess beachtet, falls beide nicht existieren, wird doch .htaccess beachtet.)
Windows-Nutzer beachten bitte, dass alle Zeilen in den Dateien .htaccess und .htsslaccess sowie .htssoaccess nicht mit den Windows-Zeilenende-Zeichen CRLF, sondern nur mit dem Unix-Zeilenende-Zeichen LF abgeschlossen werden dürfen, andernfalls erscheint bei jedem WWW-Zugriff auf den Verzeichnisbaum ein „Internal Server Error“.
- Zugriffskontrolle anhand von IP-Adressen
- Zugriffskontrolle anhand von Nutzerkennung und Gruppenzugehörigkeit (herkömmlich)
- Zugriffskontrolle anhand von Nutzerkennung und Gruppenzugehörigkeit (Single Sign-On)
- Pseudogruppen bei Verwendung von AuthDBMGroupFile /www/data/groups
- Anonymer Passwortschutz
- Zugriffsrechte für bestimmte Dateitypen
- Weitere Informationen
Zugriffskontrolle anhand von IP-Adressen
Von der Verwendung dieses Mechanismus, um den Zugriff auf bestimmte Personenkreise einzuschränken, wird abgeraten. Denn jeder Einwohner Westfalens und viele weitere Menschen haben rechtmäßig Zugang zu einigen Rechnern, die am lokalen Netz der Universität angeschlossen sind (Landesbibliothek, Kliniken usw.).
Falls Sie trotzdem Unterverzeichnisse nur für einzelne IP-Adressen freigeben möchten, müssen Sie beachten, dass alle Zugriffe über die als Reverse-Proxy-Server fungierenden Frontend-Server des Webserverparks laufen und die IP-Adressen daher der HTTP-Kopfzeile X-Forwarded-For entnommen werden müssen. Um beispielsweise nur den IP-Adressen 128.176.123.45 und 128.176.67.89 den Zugriff zu erlauben, schreiben Sie in die Datei .htaccess:
SetEnvIf X-Forwarded-For "^128\.176\.123\.45$" DarfZugreifen SetEnvIf X-Forwarded-For "^128\.176\.67\.89$" DarfZugreifen Order Deny,Allow Deny from all Allow from env=DarfZugreifen
Zugriffskontrolle anhand von Nutzerkennung und Gruppenzugehörigkeit (herkömmlich)
Um den Zugriff über das WWW auf einen bestimmten (möglicherweise auch sehr großen) Personenkreis einzuschränken, können Sie vom Leser die Angabe von Nutzerkennung und Passwort verlangen.
(CGI-Programme in den so geschützten Bereichen können über die Umgebungsvariable REMOTE_USER auf die eingetippte Nutzerkennung zugreifen, PHP-Skripte benutzen die Variable $_SERVER['REDIRECT_REMOTE_USER'] bzw. bei einigen Spezialwebspaces $_SERVER['REMOTE_USER']. Achtung: Diese Variablen können zusätzlich auch eine Domainangabe enthalten: „username“ und „username@uni-muenster.de“ bezeichnen den gleichen Nutzer, „username@anderedomain“ einen anderen Nutzer aus einer anderen Domain.)
Damit niemand Passwörter im Klartext über das Netz schickt, verwenden Sie natürlich eine HTTPS-Adresse und sorgen Sie dafür, dass HTTP-Zugriffe automatisch auf die HTTPS-Adresse umgeleitet werden. Schreiben Sie dazu die folgende Zeile in die Datei .htaccess:
RedirectPermanent / https://www.uni-muenster.de/
In die Dateien .htsslaccess und .htssoaccess schreiben Sie die genauen Zulassungsregeln. Im umfassendsten Fall sehen diese Regeln so aus:
AuthType Basic AuthName "Restricted Area" AuthDBMUserFile /www/data/users AuthUserFile /www/data/NNN/EigenePasswortdatei AuthDBMGroupFile /www/data/groups AuthGroupFile /www/data/NNN/EigeneGruppendatei AuthBasicProvider file dbm AuthzGroupFileAuthoritative Off Require group gruppe1 gruppe2 gruppe3 nutzer1 nutzer2
Normalerweise werden nur einige dieser Zeilen benötigt. Der Rest dieses Abschnitts beschreibt die Bedeutung der Zeilen, welche der Zeilen Sie angeben müssen und welche Angaben in den Zeilen Sie einfügen müssen.
Zum Verständnis ist wichtig, dass die Zugangskontrolle aus zwei Teilen besteht:
- Authentifizierung / Identitätskontrolle: Es wird kontrolliert, ob der Nutzer sein Passwort korrekt eingegeben hat und damit seine Identität nachgewiesen hat.
- Autorisierung: Es wird kontrolliert, ob der Nutzer Mitglied einer berechtigten Nutzergruppe ist und damit zum berechtigten Personenkreis gehört.
AuthType Basic
Diese Zeile muss immer genau so angegeben werden und aktiviert überhaupt erst die Zugangskontrolle. (Hier muss immer Basic stehen, selbst wenn die tatsächliche Authentifizierung per Digest, Shibboleth oder Zertifikat erfolgt.)
AuthName "Restricted Area"
Diese Zeile muss immer angegeben werden und gibt den Text an, der dem Nutzer angezeigt wird, wenn er von seinem WWW-Programm nach Nutzerkennung und Passwort gefragt wird. Statt Restricted Area sollten Sie einen sinnvollen Text wählen, der den zugelassenen Nutzerkreis beschreibt, dabei aber Umlaute als ae oe ue ss schreiben, damit alle WWW-Programme den Text lesbar anzeigen.
AuthDBMUserFile /www/data/users
Diese Zeile muss genau so angegeben werden, falls Sie bei der Zugangskontrolle mit den zentralen Nutzerkennungen und den zentralen Passwörtern der Universität arbeiten möchten. Falls Sie ausschließlich eigene Nutzerkennungen und Passwörter verwenden möchten, lassen Sie diese Zeile bitte weg.
Achtung: Der WWW-Server kennt nur Passwörter, die nach dem 19.09.2007 geändert wurden
AuthUserFile /www/data/NNN/EigenePasswortdatei
Diese Zeile muss angegeben werden, falls Sie bei der Zugangskontrolle mit eigenen Nutzerkennungen und eigenen Passwörtern arbeiten möchten. Falls Sie ausschließlich mit den zentralen Nutzerkennungen und den zentralen Passwörtern der Universität arbeiten möchten, lassen Sie diese Zeile bitte weg.
Die eigenen Nutzerkennungen und eigenen Passwörter müssen Sie in der Datei /www/data/NNN/EigenePasswortdatei ablegen, einen geeigneten Namen suchen Sie sich bitte selbst aus. Dazu benutzen Sie bitte in einer SSH-Dialogsitzung für die erste Nutzerkennung das Kommando:
/www/bin/htpasswd -s -c /www/data/NNN/EigenePasswortdatei thomas-mueller
und für jede weitere Nutzerkennung (oder später zum Ändern eines Passworts) das Kommando:
/www/bin/htpasswd -s /www/data/NNN/EigenePasswortdatei lars-meier
Für thomas-mueller und lars-meier setzen Sie jeweils eine Nutzerkennung Ihrer Wahl ein; anschließend werden Sie nach einem Passwort Ihrer Wahl gefragt. Diese Nutzerkennungen und Passwörter geben Sie dann bitte an die jeweiligen Personen weiter.
Um Namensgleichheiten mit zentralen Nutzerkennungen zu vermeiden, sollten Ihre eigenen Nutzerkennungen einen Bindestrich, aber keinen Punkt und kein @-Zeichen enthalten.
AuthDBMGroupFile /www/data/groups
Diese Zeile muss genau so angegeben werden, falls Sie bei der Zugangskontrolle mit den zentralen Nutzergruppen der Universität arbeiten möchten. Falls Sie ausschließlich eigene oder gar keine Nutzergruppen verwenden möchten, lassen Sie diese Zeile bitte weg.
Es stehen nicht nur die normalen Nutzergruppen zur Verfügung, sondern auch etliche Pseudogruppen, siehe unten unter Pseudogruppen bei Verwendung von AuthDBMGroupFile /www/data/groups.
AuthGroupFile /www/data/NNN/EigeneGruppendatei
Diese Zeile muss angegeben werden, falls Sie bei der Zugangskontrolle mit eigenen Nutzergruppen arbeiten möchten. Falls Sie ausschließlich zentralen Nutzergruppen der Universität oder gar keine Nutzergruppen verwenden möchten, lassen Sie diese Zeile bitte weg.
Die eigenen Nutzergruppen müssen Sie in der Datei /www/data/NNN/EigeneGruppendatei ablegen, einen geeigneten Namen suchen Sie sich bitte selbst aus. Schreiben Sie dazu in die Datei in jede Zeile einen Gruppennamen, dahinter einen Doppelpunkt und dahinter, durch Leerzeichen voneinander getrennt, die Nutzerkennungen, die Mitglied der Gruppe sein sollen. Dazu können Sie folgendes Kommando verwenden (als eine einzige Zeile eintippen):
echo >>/www/data/NNN/EigeneGruppendatei meine-gruppe: thomas-mueller lars-meier a_bcde01 fghij_02
Sie können sowohl zentrale als auch eigene Nutzerkennungen in Ihre eigenen Nutzergruppen aufnehmen.
Um Namensgleichheiten mit zentralen Nutzergruppen zu vermeiden, sollten Ihre eigenen Nutzergruppen einen Bindestrich, aber keinen Punkt und kein @-Zeichen enthalten.
AuthBasicProvider file dbm
Diese Zeile muss immer angegeben werden. Mindestens eines der Wörter file und dbm muss angegeben werden.
Das Wort file muss genau dann angegeben werden, wenn Sie oben die Zeile AuthUserFile angegeben haben. Das Wort dbm muss genau dann angegeben werden, wenn Sie oben die Zeile AuthDBMUserFile angegeben haben. Wenn Sie beide Wörter angeben, sollten Sie sie in der Reihenfolge file dbm angeben.
AuthzGroupFileAuthoritative Off
Diese Zeile muss genau dann angegeben werden, wenn Sie oben sowohl die Zeile AuthDBMGroupFile als auch die Zeile AuthGroupFile angegeben haben. In diesem Fall git: Wenn eine Gruppe in der Datei /www/data/NNN/EigeneGruppendatei steht, zählt die Mitgliederliste aus dieser Datei, ansonsten zählen die Gruppenzugehörigkeiten aus der zentralen Nutzerverwaltung. (Genau für dieses „ansonsten“ sorgt die Zeile AuthzGroupFileAuthoritative Off.)
Require user nutzer1 nutzer2 nutzer3
Entweder diese Zeile oder die nachfolgend beschriebene Require-group-Zeile muss angegeben werden. Wenn Sie Require user verwenden, brauchen Sie oben weder AuthDBMGroupFile noch AuthGroupFile anzugeben.
Nur die hier angegebenen Nutzerkennungen erhalten Zugang. Falls Sie mehr Nutzerkennungen angeben möchten, als in eine Zeile passen, können Sie auch mehrere Require-user-Zeilen hintereinander schreiben.
Es macht keinen Sinn, Require user und Require group beide zu verwenden, weil ein Nutzer dann nur dann Zugang erhält, wenn sowohl die Require-user-Bedingung als auch die Require-group-Bedingung erfüllt sind.
Require group gruppe1 gruppe2 gruppe3
Entweder diese Zeile oder die oben beschriebene Require-user-Zeile muss angeben werden. Wenn Sie Require group verwenden, müssen Sie oben AuthDBMGroupFile und/oder AuthGroupFile angegeben haben.
Nur die Mitglieder der hier angegebenen Gruppen erhalten Zugang. Falls Sie mehr Gruppen angeben möchten, als in eine Zeile passen, können Sie auch mehrere Require-group-Zeilen hintereinander schreiben.
Es macht keinen Sinn, Require user und Require group beide zu verwenden, weil ein Nutzer dann nur dann Zugang erhält, wenn sowohl die Require-user-Bedingung als auch die Require-group-Bedingung erfüllt sind.
Beispiele:
Nur ZIV-Mitarbeiter und -Auszubildende:
AuthType Basic AuthName "Nur fuer ZIV-Mitarbeiter und -Auszubildende" AuthDBMUserFile /www/data/users AuthDBMGroupFile /www/data/groups AuthBasicProvider dbm Require group u0zivmit u0zivazb
Alle (vermutlich) Universitätsangehörigen:
AuthType Basic AuthName "Nur fuer WWU-Angehoerige" AuthDBMUserFile /www/data/users AuthDBMGroupFile /www/data/groups AuthBasicProvider dbm Require group an=uni=unsicher
Nur die Nutzer bucher, perske und schild aus der zentralen Nutzerverwaltung:
AuthType Basic AuthName "Nur fuer die Gruppe Dienste und Projekte" AuthDBMUserFile /www/data/users AuthBasicProvider dbm Require user bucher perske schild
Nur die Nutzer rvogl und ost aus der zentralen Nutzerverwaltung und dazu die Nutzer thomas-mueller und lars-meier aus einer eigenen Passwortdatei /www/data/ZIV/htusers:
AuthType Basic AuthName "Nur fuer bestimmte Personen" AuthDBMUserFile /www/data/users AuthUserFile /www/data/ZIV/htusers AuthBasicProvider dbm file Require user rvogl ost thomas-mueller lars-meier
Alle Studierenden und Mitarbeiter der Universitäten Mainz und Köln (nur Single Sign-On über https://ssso.uni-muenster.de):
AuthType Basic AuthName "Nur fuer Angehoerige Uni Mainz und Uni Koeln" AuthDBMUserFile /www/data/users AuthDBMGroupFile /www/data/groups AuthBasicProvider dbm Require group @member@uni-mainz.de @member@uni-koeln.de
Zugriffskontrolle anhand von Nutzerkennung und Gruppenzugehörigkeit (Single Sign-On)
Die Einbindung ins Single Sign-On erfolgt nahezu identisch wie die herkömmliche Zugriffskontrolle; Single Sign-On und herkömmliche Zugangskontrolle können sogar parallel verwendet werden. Daher gilt die obige Anleitung nahezu unverändert mit nur folgenden Unterschieden:
-
Der herkömmliche Zugang erfolgt über https://www.uni-muenster.de/NNN/, der Single-Sign-On-Zugang mit Passwortkontrolle über https://sso.uni-muenster.de/NNN/, der Single-Sign-On-Zugang mit X.509-Zertifikatkontrolle über https://xsso.uni-muenster.de/NNN/, der Single-Sign-On-Zugang mit Einbindung der DFN-AAI über https://ssso.uni-muenster.de/NNN/. Im Regelfall wird der Single-Sign-On-Zugang mit Passwortkontrolle der wünschenswerte Weg sein. Dann sollte in der Datei .htaccess folgende Zeile stehen:
RedirectPermanent / https://sso.uni-muenster.de/
Die gleiche Zeile sollte auch in der Datei .htsslaccess stehen, falls Sie nicht herkömmlichen und Single-Sign-On-Zugang parallel anbieten möchten.
-
Alle Zeilen, die beim herkömmlichen Zugang in der Datei .htsslaccess stehen, müssen beim Single-Sign-On-Zugang in der Datei .htssoaccess stehen.
Da sichergestellt ist, dass die in .htssoaccess angegebenen Regeln nur dann zum Tragen kommen, wenn der Nutzer sich bereits erfolgreich ausgewiesen hat (es kann aber eine abgelaufene oder gesperrte Nutzerkennung oder ein Nutzer einer anderen Hochschule oder Großforschungseinrichtung sein!), lohnt es sich, den Text in AuthName durch eine Fehlermeldung zu ersetzen. Da auch keine Kontrolle der Nutzerpasswörter mehr zu erfolgen braucht, kann außerdem eine spezielle kleine Passwortdatei verwendet werden:
AuthName "Sie duerfen diese Infos leider nicht abrufen." AuthType Basic AuthBasicProvider dbm AuthDBMUserFile /www/data/usersso AuthDBMGroupFile /www/data/groups Require group gruppe1 gruppe2 gruppe3 nutzer1 nutzer2
-
Es ist nicht möglich, eigene Nutzerkennungen mit eigenen Passwörtern hinzuzufügen. Die Zeile AuthUserFile ... und die Angabe file in der Zeile AuthBasicProvider ... können zwar weiterhin angegeben werden, haben jedoch beim Single-Sign-On-Zugang nicht den erwünschten Effekt.
Wohl aber stehen Nutzerkennungen aus der DFN-AAI zur Verfügung, genauer der eduPersonPrincipalName eines Nutzers, der meistens die Form nutzerkennung@domain hat.
Bei der X.509-Zertifikatkontrolle wird die Nutzerkennung aus den im Zertifikat angegebenen E-Mail-Adressen entnommen. Dabei wird das Zertifikat nur dann akzeptiert, falls es im Rahmen der DFN-PKI-Hierarchie der Sicherheitsstufe Global ausgestellt wurde und die Nutzerkennung eindeutig aus den im Zertifikat enthaltenen E-Mail-Adressen der Form nutzerkennung@uni-muenster.de und/oder nutzerkennung@wwu.de ermittelt werden kann. (E-Mail-Adressen mit Aliasnamen oder aus anderen Domains werden ignoriert.)
Pseudogruppen bei Verwendung von AuthDBMGroupFile /www/data/groups
Der WWW-Server kennt nicht nur die normalen zentralen Nutzergruppen wie u0dawin, u0rz, v0dv usw., sondern auch noch etliche Pseudogruppen, die insbesondere für WWW-Seiten-Anbieter interessant sein könnten:
an=uni=sicher - Alle ca. 46900 Nutzerkennungen, deren Inhaber laut dem ZIV vorliegenden Quellen sicher Angehörige der Universität Münster im Sinne der Universitätsverfassung sind. (Falls Sie aus rechtlichen Gründen Informationen nur an Universitätsangehörige weitergeben dürfen, wählen Sie bitte diese Nutzergruppe.)
an=uni=unsicher - Obige ca. 46900 Nutzerkennungen und dazu ca. 2700 weitere Nutzerkennungen, deren Inhabern zum größten Teil ebenfalls Angehörige der Universität sind. (Falls Sie Informationen nur an Universitätsangehörige weitergeben möchten, es aber wichtiger ist, alle Universitätsangehörigen zu erreichen als Außenstehende auszuschließen, wählen Sie bitte diese Nutzergruppe.) Das ZIV bemüht sich, den Unterschied zwischen diesen beiden Pseudogruppen so klein wie möglich zu halten.
an=uni=stud - Alle Studierenden
an=uni=mitarb - Alle wiss. und nichtwiss. Mitarbeiter (soweit der Universitätsverwaltung bekannt)
an=uni=whk - Alle wissenschaftlichen Hilfskräfte (soweit der Universitätsverwaltung bekannt)
an=uni=shk - Alle studentischen Hilfskräfte (soweit der Universitätsverwaltung bekannt)
an=uni=lehr - Alle Lehrbeauftragten (soweit der Universitätsverwaltung bekannt)
an=uni=emerit - Alle Emeriti (soweit der Universitätsverwaltung bekannt)
sys=aix-urz - Alle Nutzer mit einem normalen E-Mail-Postfach (der Name aix-urz hat historische Gründe)
sys=xxxxx - Alle Nutzer mit Zugang zum System xxxxx (z. B. sys=cms-imperia, sys=ras-wwu, sys=prplot-ziv usw.)
Zu jeder einzelnen zentralen Nutzerkennung gibt es eine gleichnamige Pseudogruppe, die nur diese Nutzerkennung enthält. (Das ermöglicht obige Angabe der Form Require group gruppe1 gruppe2 nutzer1 nutzer2.)
Im Rahmen der DFN-AAI können auch Angaben über auswärtige Nutzer als Pseudogruppen zur Verfügung gestellt werden, bitte wenden Sie sich bei Bedarf an wwwadmin@uni-muenster.de. (Testweise werden derzeit die Affiliations mit einem @-Zeichen als Präfix angeboten, beispielsweise @member@uni-mainz.de für alle Angehörigen der Uni Mainz.)
Anonymer Passwortschutz
Häufig wünschen Sie keinen wirklichen Schutz, sondern möchten Sie nur eine Hürde aufbauen. Beispielsweise möchten Sie die Unterlagen einer Vorlesung schützen, aber jeder, der ein von Ihnen in der Vorlesung genanntes Passwort kennt, soll zugreifen dürfen, ohne dass Sie die Nutzerkennungen aller Teilnehmer erfassen möchten. Dann können Sie folgende Datei .htsslaccess verwenden:
AuthType Basic AuthName "Vorlesung Prof. Mueller" AuthUserFile /www/data/NNN/AnonymesPasswort AuthBasicProvider file Require user anonym
Die Datei /www/data/NNN/AnonymesPasswort (einen geeigneten Namen suchen Sie sich bitte selbst aus) erzeugen Sie in einer SSH-Dialogsitzung mit folgendem Kommando:
/www/data/sys/htpasswd -s -c /www/data/NNN/AnonymesPasswort anonym
Die Nutzerkennung anonym und das nach Aufforderung durch dieses Kommando eingetippte Passwort geben Sie in Ihrer Vorlesung bekannt.
Zugriffsrechte für bestimmte Dateitypen
Die Serverkonfiguration verhindert, dass Dateien ausgeliefert werden, die mit einem Punkt „.“ beginnen oder die auf eine Tilde „~“ oder auf ein Doppelkreuz „#“ enden. Ebenso werden Dateien namens „DEADJOE“ nicht ausgeliefert.
(Viele Editoren legen beim Bearbeiten von Dateien Backupkopien mit solchen Dateinamen an; diese Einstellung soll unter Anderem verhindern, dass Sie versehentlich über solche Backupkopien Skriptquelltexte veröffentlichen.)
Durch entsprechende Blöcke <Files ...> ... </Files> oder <FilesMatch...> ... </FilesMatch> in .htaccess und .htsslaccess können Sie diese Einstellung anpassen.
Weitere Informationen
Für weitere Einzelheiten beachten Sie bitte die Apache-Dokumentation.
