WWW-Zugriffsrechte

Stand: 29.11.2016

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

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
Require 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
<RequireAny>
  Require group eigengruppe1 eigengruppe2 eigennutzer1 eigennutzer2
  Require dbm-group zivgruppe1 zivgruppe2 zivnutzer1 zivnutzer2
</RequireAny>

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:

  1. Authentifizierung / Identitätskontrolle: Es wird kontrolliert, ob der Nutzer sein Passwort korrekt eingegeben hat und damit seine Identität nachgewiesen hat.
  2. 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.

<RequireAny> ... </RequireAny>

Wenn mehrere Require-Zeilen innerhalb eines solchen RequireAny-Blocks angegeben werden, reicht es aus, wenn eine der Require-Bedingungen erfüllt ist, um Zugang zu gewähren. Das Gegenteil wäre <RequireAll> ... </RequireAll>. Die Blöcke können verschachtelt werden.

Require user nutzer1 nutzer2 nutzer3

Wenn Sie Require user verwenden, müssen Sie oben AuthDBMUserFile und/oder AuthUserFile angegeben haben, brauchen Sie aber 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.

Require group filegruppe1 filegruppe2

Wenn Sie Require group verwenden, müssen Sie oben AuthGroupFile angegeben haben. Nur die Mitglieder der hier angegebenen Gruppen erhalten Zugang.

Require dbm-group dbmgruppe1 dbmgruppe2

Wenn Sie Require dbm-group verwenden, müssen Sie oben AuthDBMGroupFile angegeben haben. Nur die Mitglieder der hier angegebenen Gruppen erhalten Zugang.

Verwendung mehrerer Require-Angaben

Wenn Sie mehrere Require-Angaben verwenden, sollten Sie diese in RequireAny- oder RequireAll-Blöcke einschließen, die auch verschachtelt werden dürfen, um zu verdeutlichen, wie diese Angaben kombiniert werden sollen.

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 dbm-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 dbm-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 und außerdem der Nutzer mueller der Fachhochschule Münster (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 dbm-group @member@uni-mainz.de @member@uni-koeln.de mueller@fh-muenster.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 dbm-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.)

Anmeldung nur mit Zertifikat erlauben

Bei gewissen hochsensitiven Angeboten möchten Sie vielleicht überhaupt keinen Zugang mit Nutzerkennung und Passwort mehr erlauben. Dann können Sie erzwingen, das nur eine Anmeldung mit einem X.509-Zertifikat akzeptiert wird. Hier ein Beispiel für eine entsprechende Datei .htssoaccess:

AuthType Basic
AuthName "Nur fuer Administratoren"
AuthDBMUserFile /www/data/usersso
AuthDBMGroupFile /www/data/groups
AuthBasicProvider dbm
<RequireAll>
  Require dbm-group gruppe1 gruppe2 gruppe3 nutzer1 nutzer2
  Require expr %{HTTP:X-Trusted-Remote-Auth} =~ /^X509:/
</RequireAll>

Wenn man den Ausdruck /^X509:/ durch folgenden komplexen regulären Ausdruck ersetzt, dann werden sogar nur Zertifikate von der Zertifizierungsstelle der Universität Münster akzeptiert:

/^X509:(emailAddress=ca@uni-muenster.de,CN=Zertifizierungsstelle Universitaet Muenster - G02,O=Universitaet Muenster,C=DE;|CN=DFN-Verein Global Issuing CA,OU=DFN-PKI,O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.,C=DE;[^;]*,O=(Westfaelische Wilhelms-Universitaet Muenster|Universitaetsklinikum Muenster|Kunstakademie Muenster - Hochschule fuer Bildende Kuenste),L=Muenster,ST=Nordrhein-Westfalen,C=DE;)/

Wenn Sie dann noch von Ihren Nutzern verlangen, die Zertifikate nicht im Browser, sondern auf Smartcard oder eToken zu speichern, haben Sie Ihren Webspace – zumindest was die Zugangskontrolle betrifft – so gut abgesichert wie es nur geht.

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.

Im Rahmen der DFN-AAI werden die sog. Affiliations als Pseudogruppen zur Verfügung gestellt:

@student@uni-muenster.de - Alle ca. 46300 persönlichen Nutzerkennungen von Studierenden der WWU, soweit dies gemäß Verlässlichkeitsklasse Advanced der DFN-AAI festgestellt werden kann. Dazu gehören die dem Studierendensekretariat bekannten Nutzerkennungen aller ordentlichen Studierenden, Zweit- und Gasthörer und Teilnehmer am Studium im Alter (also nicht die Nutzerkennungen der Studierenden einiger externer Einrichtungen der WWU).

@faculty@uni-muenster.de - Alle primären persönlichen Nutzerkennungen von wissenschaftlichen Mitarbeitern der WWU, soweit dies gemäß Verlässlichkeitsklasse Advanced der DFN-AAI festgestellt werden kann. Dazu gehören:

  • die wissenschaftlichen Beschäftigten der WWU laut Personalverwaltung der Universität (ohne Medizinische Fakultät)
  • die wissenschaftlichen Hilfskräfte der WWU laut Personalverwaltung der Universität (ohne Medizinische Fakultät)
  • die Lehrbeauftragten während der jeweiligen Vertragslaufzeiten laut Personalverwaltung der Universität (ohne Medizinische Fakultät)
  • die Emeriti nach altem Hochschulrecht laut Personalverwaltung der Universität (ohne Medizinische Fakultät)
  • die wissenschaftlichen Beschäftigten der Medizinischen Fakultät der WWU laut Personalverwaltung des Universitätsklinikums

@staff@uni-muenster.de - Alle primären persönlichen Nutzerkennungen von nichtwissenschaftlichen Mitarbeitern der WWU, soweit dies gemäß Verlässlichkeitsklasse Advanced der DFN-AAI festgestellt werden kann. Dazu gehören:

  • die nichtwissenschaftlichen Beschäftigten der WWU laut Personalverwaltung der Universität (ohne Medizinische Fakultät)
  • die studentischen Hilfskräfte der WWU laut Personalverwaltung der Universität (ohne Medizinische Fakultät)

@employee@uni-muenster.de - Alle Nutzerkennung, die @faculty@uni-muenster.de oder @staff@uni-muenster.de haben.

Dazu gehören jedoch nicht (weil es für diese Personenkreise keine ausreichend verlässlichen Datenquellen gibt):

  • die Beschäftigten des Universitätsklinikums Münster, die nur aufgrund ihrer Tätigkeit auch der Medizinischen Fakultät angehören (für diese gibt es die manuell gepflegte Nutzergruppe e0mitwwu)
  • die Beschäftigten einiger ausgegliedeter Einrichtungen der WWU (Nutzergruppe u0mitwwu)
  • die Hochschullehrer im Ruhestand nach aktuellem Hochschulrecht (Nutzergruppe y0hslir)
  • die Emeriti nach altem Hochschulrecht der Medizinischen Fakultät (Nutzergruppe y0emerit)
  • die Lehrbeauftragten außerhalb der jeweiligen Vertragslaufzeiten (die jeweilige Institutsnutzergruppe)
  • Praktikanten, Doktoranden, Honorarkräfte, freie Mitarbeiter, Leiharbeiter usw. (die jeweilige Institutsnutzergruppe)

@member@uni-muenster.de - Alle ca. 54100 persönlichen Nutzerkennungen von Mitgliedern und Angehörigen der WWU, soweit dies gemäß Verlässlichkeitsklasse Advanced der DFN-AAI festgestellt werden kann. Dazu gehören alle Mitglieder von @student@uni-muenster.de und von @employee@uni-muenster.de sowie weitere persönliche Nutzerkennungen, die den gleichen Personen zugeordnet sind.

Gleichartige Affiliations (z. B. @student@fh-koeln.de usw.) werden auch für alle anderen an der DFN-AAI teilnehmenden Einrichtungen zur Verfügung gestellt. (Da zusätzlich zur Mitgliedschaft in der DFN-AAI auch eine bilaterale Absprache erforderlich ist, wenden Sie sich bitte an wwwadmin@uni-muenster.de, wenn Sie Angehörigen entsprechender Gruppen den Zugang gewähren möchten.)

In den meisten Fällen werden für lokale Nutzer statt der Affiliations @...@uni-muenster.de aber folgende, umfassendere Pseudogruppen zur Anwendung kommen:

an=uni=sicher - Alle ca. 54400 Nutzerkennungen, deren Inhaber laut dem ZIV vorliegenden Quellen sicher Mitglieder oder Angehörige der Universität Münster im Sinne der Universitätsverfassung sind (mit einem Restrisiko, dass ein Ausscheiden erst verzögert erkannt wird). Dazu gehören alle Nutzerkennungen in @member@uni-muenster.de, die Nutzerkennungen in den oben angedeuteten Nutzergruppen u0mitwwu, e0mitwwu, y0emerit und y0hslir, die vdv-Nutzerkennungen der Universitätsverwaltung und einige weitere Nutzerkennungen. Falls Sie aus rechtlichen Gründen Informationen nur an Universitätsmitglieder und -angehörige weitergeben dürfen, wählen Sie bitte diese Nutzergruppe.

an=uni=unsicher - Alle ca. 57000 Nutzerkennungen, deren Inhaber sicher oder zumindest wahrscheinlich Mitglieder oder Angehörige der Universität sind. Dazu gehören alle Nutzerkennungen in an=uni=sicher und alle Nutzerkennungen in an=uni=arbeit=unsicher. (Falls Sie Informationen nur an Universitätsmitglieder und -angehörige weitergeben möchten, es aber wichtiger ist, alle Mitglieder und Angehörigen zu erreichen als Außenstehende auszuschließen, wählen Sie bitte diese Nutzergruppe.) Das ZIV bemüht sich, den Unterschied zwischen an=uni=sicher und an=uni=unsicher so klein wie möglich zu halten.

an=uni=ukm=unsicher - Alle ca. 58250 Nutzerkennungen, deren Inhaber sicher oder zumindest sehr wahrscheinlich Mitglieder oder Angehörige der Universität oder des Universitätsklinikums sind. Dazu gehören alle Nutzerkennungen in an=uni=unsicher.

an=ka=sicher - Alle ca. 450 Nutzerkennungen, deren Inhaber sicher Mitglieder oder Angehörige der Kunstakademie Münster sind.

an=uni=arbeit=unsicher - Alle ca. 15100 Nutzerkennungen, deren Inhaber sicher oder zumindest wahrscheinlich Mitarbeiter der Universität sind. Dazu gehören alle Nutzerkennungen in @employee@uni-muenster.de, die Nutzerkennungen in den oben angedeuteten Nutzergruppen u0mitwwu, e0mitwwu, y0emerit und y0hslir, die vdv-Nutzerkennungen der Universitätsverwaltung, die Nutzerkennungen in den nichtmedizinischen Institutsnutzergruppen und in weiteren Nutzergruppen. (Es gibt keine Pseudogruppe an=uni=arbeit=sicher, siehe die Erläuterung zu @employee@uni-muenster.de.)

an=uni=ukm=arbeit=unsicher - Alle ca. 16400 Nutzerkennungen, deren Inhaber sicher oder zumindest wahrscheinlich Mitarbeiter der Universität oder des Universitätsklinikums sind. Dazu gehören alle Nutzerkennungen in an=uni=arbeit=unsicher und Mitglieder vieler Nutzergruppen medizinischer Institute und Kliniken.

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.) Ebenso gibt es auch für jede Nutzerkennung einer anderen Einrichtung eine entsprechende Pseudogruppe mit nur dieser Nutzerkennung, ergänzt um die jeweilige Domain. (Das ermöglicht obige Angabe Require group @member@uni-mainz.de @member@uni-koeln.de mueller@fh-muenster.de.)

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.