Sie sind hier:  Projekte  >  CampusConnect-ECS  >  ECS-Proxy

ECS Proxy

Ecs-proxy

Der Proxy übernimmt für den ECS zum einen die Authentifikation der CampusConnect Teilnehmer (Participanten) und zum anderen beschränkt und autorisiert er den Zugriff auf bestimmte Ressourcen.

CampusConnect unterstützt derzeit entweder "HTTP Basic Auth" oder ein zertifikatsbasiertes (X.509 Client-/Server Certificates) Authentifikationsverfahren. Egal welches der beiden Verfahren benutzt wird, teilt der Proxy dem ECS eine erfolgreiche Authentifikation durch eine zusätzliche Übermittlung einer Authentifizierungs-ID, zugewiesen an die HTTP-Headervariable "X-EcsAuthId" über ein sogenanntes "Header Injection", mit.

Autorisation für den Zugriff auf einzelne ECS-Ressourcen werden z.B. durch entsprechende "Allow" bzw. "Deny" Direktiven bei der Proxykonfiguration erreicht. Konkrete Beispiele dazu folgen in den Kapiteln für die Konfiguration der beiden Proxy-/Webserver Nginx und Apache.

Die Auslagerung der Authentifizierung und der Autorisation an den Proxy (also z.b. den Apache-Webserver, der als (Reverse-)Proxy betrieben werden kann), stellt eine bewußte Desigentscheidung dar, die entsprechende Vorteile mit sich bringt:

  • Maximale Sicherheit
    Authentifikationsmodule im Proxy haben eine jahrelange Entwicklung und Betriebspraxis hinter sich. Fehlfunktionen sind somit auf ein Minimum reduziert.
  • Hohe Performance

    Alle unberechtigten Verbindungsversuche werden vorab durch den Proxy abgewiesen und belasten somit den ECS selbst nicht. Bei entsprechender Ausgestaltung des Proxies können so selbst "Denial of Service" Angriffe abgewehrt werden.

    Effizientes SSL/TLS Verbindungshandling (Verbindungsauf-/Abbau).

Apache

Es existieren viele Konfigurationsbeispiele ([1], [2]) für eine Reverse-Proxy-Konfiguration des Apache-Webservers, die prinzipiell alle verwendet werden können, sofern sie die notwendige Authentifikations-ID (X-EcsAuthId) an den ECS mittels "HTTP Header Injection" durchreichen. Bei einer Authentifikation via "Basic Auth" und der Rückgabe des Benutzernamens als Authentifikations-ID sieht das so aus:

  RequestHeader unset X-EcsAuthId
  RewriteCond %{LA-U:REMOTE_USER} (.+)
  RewriteRule .* - [E=RU:%1]
  RequestHeader set X-EcsAuthId %{RU}e env=RU

Bei einer Authentifikation mittels X.509 Zertifikaten und der Rückgabe einer Authentifikations-ID die sich zusammensetzt aus Seriennummer und der Emailsadresse des Clientzertifikats:

  RequestHeader unset X-EcsAuthId
  RequestHeader set X-EcsAuthId %{SSL_CLIENT_M_SERIAL}e_%{SSL_CLIENT_S_DN_Email}e

Weiterhin müssen die einzelnen Ressourcen des ECS, welche sich unter /sys, /admin und /campusconnect befinden vor allgemeinem Zugriff geschützt werden. so daß nur autorisierte und authentisierte Nutzer auf diese zugreifen können. Dies erfolgt durch entsprechende "Location" Deklarationen:

<Location />
  AuthType Basic
  AuthName "CampusConnect-ECS"
  AuthBasicProvider file
  AuthUserFile /etc/apache2/ecs/pwds
  Require valid-user
</Location>

<Location /admin>
  AuthType Basic
  AuthName "ECS admin area"
  AuthBasicProvider file
  AuthUserFile /etc/apache2/ecs/pwds
  Require user admin
</Location>

Installation/Konfiguration

Nachfolgende Konfiguration setzt eine Debian 9 (alias Stretch) Betriebssysteminstallation voraus. Alle Installationsanweisungen müssen in einer Root-Shell ausgeführt werden. Zunächst geben wir folgende Kommandos ein:

  apt-get install apache2
  a2enmod ssl headers rewrite proxy_balancer proxy_http lbmethod_byrequests
  a2dissite 000-default

Weiterhin sollte die "Listen 80" Zeile in der Datei "/etc/apache2/ports.conf" auskommentiert werden, sodaß der Apache Proxy lediglich auf den Port 443 hört.

Danach laden wir das TAR-Archiv ecs_apache.tar herunter und entpacken es:

  tar xCf / ecs_apache.tar

In diesem Archiv stecken die vier Dateien:

  etc/apache2/sites-available/000-ecs4.conf
  etc/apache2/ecs/admin.conf
  etc/apache2/ecs/global.conf
  var/www/html/maintenance.html.off

Die Datei "000-ecs4.conf" konfiguriert einen virtuellen ECS Host. In dieser Datei müssen natürlich noch einige Anweisungen den lokalen Gegebenheiten angepaßt werden, wie z.B. ServerName, ServerAdmin, SSLCertificateFile, SSLCertificateKeyFile. Aber auch die restlichen Anweisungen sollten angeschaut und verstanden werden (Apache Doku)

Die Dateien "admin.conf" und "global.conf" dienen alle der Ressourcenzugriffskontrolle. Bleibt noch die letzte Datei "maintenance.html.off". Benennt man diese Datei in "maintenance.html" um, liefert der Apache-Proxy eine Maintenance Seite mit dem Returncode "503" (Service Unavailable) aus, was der übliche Returncode für einen Dienst in Wartung darstellt.

Da wir jetzt einen ECS virtuellen Host konfiguriert/installiert haben, müssen wir diesen noch aktivieren:

  a2ensite 000-ecs4

In "000-ecs4.conf" ist standardmäßig eine "Basic Auth" Authentisierung konfiguriert, weshalb wir jetzt noch eine entsprechende Paßwortdatei erzeugen müssen und gleichzeitig den Nutzer "admin" eintragen, wobei wir um die Eingabe eines Paßwortes für den neuen Nutzer "admin" nachgefragt werden:

  htpasswd -mc /etc/apache2/ecs/pwds admin

Alle weiter hinzukommenden Participanten (Ilias, Moodle, StudIP Installationen) müssen hier ebenso einen Accounteintrag erhalten, dessen Ingredienzen den Administratoren der Participanten zu dessen ECS Konfiguration übermittelt werden müssen. Ein solcher Particpanten-Account würde sich folgendermaßen erzeugen lassen:

  htpasswd -m /etc/apache2/ecs/pwds Ilias_Uni_XYZ

Auch bei der Einrichtung eines neuen Participanten beim ECS muß der Username, also in unserem Beispiel "Ilias_Uni_XYZ", als "Authentication-ID" eingetragen werden, denn dieser Username wird bei erfolgreicher Authentifikation durch den Proxy anhand der schon weiter oben genannten "X-EcsAuthId" HTTP-Header-Variablen via "HTTP Header Injection" an den ECS übertragen, wodurch dieser den Participanten eindeutig zuordnen kann (Autorisation).

Die Proxy-Konfiguration ist nun abgeschlossen und der ECS Admin-Bereich kann über den konfigurierten Servernamen angesprochen werden, also z.B:

  https://deb-stretch-rails-server.example.com

Bei der erscheinenden Login-Box müssen jetzt die Ingredienzen für den Admin Account, den wir vorhin mit dem Benutzernamen "admin" angelegt hatten, eingegeben werden.

CampusConnect Participanten, also z.B. Ilias Lernsysteme, müssen natürlich zuerst am ECS (Participants -> New Participant) eingetragen werden, damit sie einem CampusConnect-Netzwerk angehören und innerhalb einer Community mit anderen CampusConnect-Teilnehmern (Participanten) interagieren und kommunizieren können.

Tickets eröffnen

Auf GitHub.com können für den CampusConnect-ECS Tickets erstellt werden. Tickets erlauben es dem Nutzer einfache Fragen, vermeintliche Fehler sowie Infos und Tips zum CampusConnect-ECS einzureichen.

Bitte beachten Sie, daß die Bearbeitung dieser Tickets eine niedere Priorität eingeräumt wird und grundsätzlich kein Anspruch auf Bearbeitung besteht. Für eine umfassende Betreuung Ihrer Anliegen steht es Ihnen frei, einen Supportvertrag mit FreeIT abzuschließen.

Um mit dem nachfolgenden Formular ein Ticket erstellen zu können, benötigen Sie ein Konto auf GitHub.com.

ProjektTicket Typ
CampusConnect-ECS

Liste aller offenen CampusConnect-ECS Tickets.