WWW-Zugriffsrechte

Stand: 14.01.2022

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 https://www.uni-muenster.de/NNN/ wird nur die Datei .htsslaccess beachtet. Falls diese Datei nicht existiert, wird ersatzweise die Datei .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 nicht existiert, wird ersatzweise die Datei .htsslaccess beachtet. Falls diese auch nicht existiert, wird .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 sowie 2001:4cf0:2:20::80b0:6fa den Zugriff zu erlauben, schreiben Sie in die Datei .htaccess bitte als eine Zeile (zwischen den beiden Schrägstrichen darf weder ein Leerzeichen noch ein Zeilenumbruch vorkommen):

Require expr %{HTTP:X-Forwarded-For} =~ /(?i)
^128\.176\.123\.45$|
^128\.176\.67\.89$|
^0*2001:0*4cf0:0*2:0*20:[:0]*:0*80b0:0*6fa$/

Der komplexe reguläre Ausdruck mit (?i) und 0* und [:0]* ist notwendig, da nicht festgelegt ist, in welcher der vielen möglichen Schreibweisen (kompakt oder lang, führende Nullen oder nicht, Groß- oder Kleinbuchstaben usw.) eine IPv6-Adresse übergeben wird und die Schreibweise sich jederzeit ändern kann.

Zugriffskontrolle anhand von Kennung 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 Kennung und Passwort verlangen.

(CGI-Programme in den so geschützten Bereichen können über die Umgebungsvariable REMOTE_USER auf die eingetippte Kennung 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@domain“ bezeichnen verschiedene Nutzer.)

In die Datei .htaccess oder .htsslaccess (es ist egal, welche dieser beiden Dateinamen Sie verwenden) für den Nicht-Single-Sign-On-Zugang und in die Datei .htssoaccess für den Single-Sign-On-Zugang 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

  Require group eigengruppe1 eigengruppe2 eigennutzer1 eigennutzer2
  Require dbm-group zivgruppe1 zivgruppe2 zivnutzer1 zivnutzer2

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, Formular, 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 Kennung 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 WWU-Kennungen und den WWU-Passwörtern arbeiten möchten. Falls Sie ausschließlich eigene Kennungen und Passwörter verwenden möchten, lassen Sie diese Zeile bitte weg.

AuthUserFile /www/data/NNN/EigenePasswortdatei

Diese Zeile muss angegeben werden, falls Sie bei der Zugangskontrolle mit eigenen Kennungen und Passwörtern arbeiten möchten. Falls Sie ausschließlich mit den WWU-Kennungen und den WWU-Passwörtern arbeiten möchten, lassen Sie diese Zeile bitte weg.

Die eigenen Kennungen und 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 Kennung das Kommando:

/www/bin/htpasswd -s -c /www/data/NNN/EigenePasswortdatei thomas-mueller

und für jede weitere Kennung (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 Kennung Ihrer Wahl ein; anschließend werden Sie nach einem Passwort Ihrer Wahl gefragt. Diese Kennungen und Passwörter geben Sie dann bitte an die jeweiligen Personen weiter.

Um Namensgleichheiten mit WWU-Kennungen zu vermeiden, sollten Ihre eigenen Kennungen 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 Kennungen, 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 WWU-Kennungen als auch eigene Kennungen 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.

...

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 ... . 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 Kennungen erhalten Zugang. Falls Sie mehr Kennungen 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 Mitarbeiter der WWU IT (*):

AuthType Basic
AuthName "Nur fuer WWU-IT-Mitarbeiter"
AuthDBMUserFile /www/data/users
AuthDBMGroupFile /www/data/groups
AuthBasicProvider dbm
Require dbm-group u0rz

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 WWU-Kennungen 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, afleu_01, drudo_01 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 afleu_01 drudo_01 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 (*):

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

In den mit (*) markierten Beispielen wäre es aber besser, wie unten beschrieben eine Anmeldung nur über das Single Sign-On anzubieten.

 

Zugriffskontrolle anhand von Kennung 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 den Dateien .htaccess und/oder .htsslaccess folgende Zeile stehen:

    RedirectPermanent / https://sso.uni-muenster.de/
    
  • 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 Kennung 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 Kennungen 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 Kennungen aus der DFN-AAI zur Verfügung, genauer der eduPersonPrincipalName oder die Subject-ID oder eine Pairwise-ID (diese haben die Form identifikator@domain) oder eine eduPersonUniqueId oder eine eduPersonTargetId (diese haben die Form identifikator@).

    Auf https://ssso.uni-muenster.de/who-am-i kann ein beliebiger Nutzer jederzeit nachschauen, welche Kennung von seinem Login-Server an unseren Single-Sign-On-Zugang übermittelt wird.

Bei der X.509-Zertifikatkontrolle wird die Kennung aus den im Zertifikat angegebenen E-Mail-Adressen entnommen. Dabei wird das Zertifikat nur dann akzeptiert, falls es im Rahmen der DFN-PKI-Hierarchien Global oder TCS ausgestellt wurde und die Kennung eindeutig aus den im Zertifikat enthaltenen E-Mail-Adressen der Form kennung@uni-muenster.de und/oder kennung@wwu.de ermittelt werden kann. (E-Mail-Adressen mit Aliasnamen oder aus anderen Domains werden ignoriert. Falls das Zertifikat über das IT-Portal beantragt wurde, wird die Kennung immer in geeigneter Form eingetragen.)

Anmeldung nur mit Zertifikat erlauben

Bei gewissen hochsensitiven Angeboten möchten Sie vielleicht überhaupt keinen Zugang mit Kennung 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

  Require dbm-group gruppe1 gruppe2 gruppe3 nutzer1 nutzer2
  Require expr %{HTTP:X-Trusted-Remote-Auth} =~ /^X509:/

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:(CN=GEANT Personal CA 4,O=GEANT Vereniging,C=NL|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),/

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 persönlichen WWU-Kennungen von Studierenden der WWU, soweit dies gemäß Verlässlichkeitsklasse Advanced der DFN-AAI festgestellt werden kann. Dazu gehören die dem Studierendensekretariat bekannten WWU-Kennungen aller ordentlichen Studierenden, Zweit- und Gasthörer und Teilnehmer am Studium im Alter (also nicht die WWU-Kennungen der Studierenden einiger externer Einrichtungen der WWU, denn diese sind formell nur Angehörige, aber keine Studierende der Universität).

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

  • 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 studentischen Hilfskräfte mit oder ohne Bachelor 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 Hochschullehrer im Ruhestand nach aktuellem Hochschulrecht (Nutzergruppe y0hslir)
  • die wissenschaftlichen Beschäftigten der Medizinischen Fakultät der WWU laut Personalverwaltung des Universitätsklinikums

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

  • die Beschäftigten in Technik und Verwaltung der WWU laut Personalverwaltung der Universität (ohne Medizinische Fakultät)

@employee@uni-muenster.de - Alle WWU-Kennungen, 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 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 persönlichen Kennungen 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, aber unter anderem auch:

  • Studierenden einiger externer Einrichtungen der WWU (WWU-Weiterbildung gGmbH, JurGrad gGmbH usw.)

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 WWU-Kennungen, 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 Kennungen in @member@uni-muenster.de und die WWU-Kennungen in einigen wenigen Nutzergruppen. 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 WWU-Kennungen, deren Inhaber sicher oder zumindest wahrscheinlich Mitglieder oder Angehörige der Universität sind. Dazu gehören alle Kennungen in an=uni=sicher und alle Kennungen 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.) Die WWU IT bemüht sich, den Unterschied zwischen an=uni=sicher und an=uni=unsicher so klein wie möglich zu halten, aber es gibt ca. 3000 WWU-Kennungen, die nur in an=uni=unsicher aufgenommen werden können.

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

an=ka=unsicher - Alle WWU-Kennungen, deren Inhaber sicher oder zumindest wahrscheinlich Mitglieder oder Angehörige der Kunstakademie Münster sind.

an=uni=arbeit=unsicher - Alle WWU-K ennungen, deren Inhaber sicher oder zumindest wahrscheinlich Mitarbeiter der Universität sind. Dazu gehören alle Kennungen in @employee@uni-muenster.de, die WWU-Kennungen in den oben angedeuteten Nutzergruppen u0mitwwu und e0mitwwu, die WWU-Kennungen in den Verwaltungs- und 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.)

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 WWU-Kennung gibt es eine gleichnamige Pseudogruppe, die nur diese WWU-Kennung enthält. (Das ermöglicht obige Angabe der Form Require dbm-group gruppe1 gruppe2 nutzer1 nutzer2.) Ebenso gibt es auch für jede Kennung einer anderen Einrichtung eine entsprechende Pseudogruppe mit nur dieser Kennung, ergänzt um die jeweilige Domain. (Das ermöglicht obige Angabe Require dbm-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 Kennungen 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 ... oder ... in .htaccess, .htsslaccess und .htssoaccess können Sie diese Einstellung anpassen.