SVN Authentifizierung und Autorisierung

Bachelor Thesis
SVN Authentifizierung und
Autorisierung
Authentifizierung und Autorisierung von SVN-Benutzern
via Active Directory und OpenLDAP
Gérard Bieli, Christian Haller
Dozent:
Prof. Dr. Peter Gysel
Betreuer:
Matthias Krebs, Beat Walti
Windisch, 13. August 2009
Inhaltsverzeichnis
1. Ausgangslage und Problemstellung
1.1. IST-Zustand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
1
2. Konzept
2.1. Anforderungen . . . . . . . . . . .
2.2. Lösungsvarianten . . . . . . . . . .
2.2.1. Variante 1: Shibboleth . . .
2.2.2. Variante 2: Direkte Abfrage
2.3. Entscheid . . . . . . . . . . . . . .
.
.
.
.
.
2
2
3
3
7
9
3. Abweichung vom Konzept
3.1. Modul mod authn alias anstelle von Penrose . . . . . . . . . . . . . . . . . . . . . . .
10
10
4. Implementation
4.1. Funktionsweise . . . . . . . . . . . . . .
4.2. Konfiguration . . . . . . . . . . . . . . .
4.2.1. Verwendete Hard- und Software .
4.2.2. SVN . . . . . . . . . . . . . . . .
4.2.3. Apache . . . . . . . . . . . . . .
4.2.4. Datenbank . . . . . . . . . . . .
4.3. Ablauf und Zusammenspiel im Detail . .
4.3.1. Client-Anfrage . . . . . . . . . .
4.3.2. Authentifizierung . . . . . . . . .
4.3.3. Autorisierung . . . . . . . . . . .
4.3.4. Server-Antwort . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
11
11
12
12
12
13
16
19
19
20
25
25
. .
. .
. .
der
. .
. . . .
. . . .
. . . .
LDAP
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . .
. . . . . . . .
. . . . . . . .
Verzeichnisse
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5. Probleme
5.1. Penrose . . . . . . . . . . . . . . . . . . . . . .
5.1.1. Probleme mit Umlauten . . . . . . . . .
5.2. Apache . . . . . . . . . . . . . . . . . . . . . .
5.2.1. Kompilieren des Moduls mod authz svn
5.2.2. SSL Verbindung zum FHNW AD . . . .
. .
. .
. .
db
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
27
31
31
31
6. Tests
6.1. Testumgebung .
6.2. Allgemeines . . .
6.3. Authentifizierung
6.4. Autorisierung . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
34
35
35
35
7. Ausblick
7.1. SVN Verwaltungsapplikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.1. Use Case Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
36
36
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
I
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
Inhaltsverzeichnis
7.1.2. GUI Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A. Anhang: Scripts und Konfigurationen
A.1. SQL: Erstellung der Datenbank .
A.2. SQL: Beispieldaten . . . . . . . .
A.3. SQL: Datenbankabfrage . . . . .
A.4. Bash: Buildscript Apache Modul
A.5. Konfigurationsdatei: Apache . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
40
41
42
45
46
46
B. Anhang: Pflichtenheft
49
Literaturverzeichnis
50
Bachelor Thesis
II
SVN Authentifizierung und Autorisierung
Abbildungsverzeichnis
2.1.
2.2.
2.3.
2.4.
Ablauf
Ablauf
Ablauf
Ablauf
der
der
der
der
Shibboleth Authentifizierung . . . . . . . . . . . . . . . . . .
Shibboleth DAV Basic Authentifizierung . . . . . . . . . . .
Shibboleth DAV Basic Authentifizierung mit Zwischenschicht
LDAP SVN Authentifizierung und Autorisierung . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
4
5
7
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
Ablauf der Authentifizierung und
ERD . . . . . . . . . . . . . . . .
Tabellen der Datenbank . . . . .
Client Request . . . . . . . . . .
EDU-Abfrage . . . . . . . . . . .
ADM-Abfrage . . . . . . . . . . .
OpenLDAP-Abfrage . . . . . . .
Server Response . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
16
16
19
20
22
23
25
5.1. Penrose Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2. Capture 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3. Capture 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
29
30
6.1. Verwendete Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
7.1. Use Case Diagramm der Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2. Repositoryverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3. Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
38
39
Autorisierung
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
III
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Zusammenfassung
Das Ziel dieser Bachelor Arbeit war es, eine Lösung zu finden, so dass sich Benutzer der SVNRepositories des Departements IMVS mit dem Benutzernamen und Passwort ihres Active Directory
Kontos anmelden können. Zudem sollte eine vernünftige Zugriffsregelung für die einzelnen Benutzer
gefunden und implementiert werden. In diesem Dokument wird die Ausgangslage im Detail analysiert
und verschiedene Lösungswege evaluiert. Die gewählte Lösung wird genauer betrachtet und beschrieben, wobei die Abweichungen vom Konzept ebenfalls erklärt und begründet werden.
1. Ausgangslage und Problemstellung
1.1. IST-Zustand
Die SVN-Repositories des Departements IMVS können zur Zeit nur auf sehr umständliche Art verwaltet werden. Um Benutzer authentifizieren zu können – also um sicherzustellen, dass ein Benutzer
derjenige ist, der er angibt zu sein – müssen die Benutzerdaten in einen eigens dafür eingerichteten
OpenLDAP-Server eingetragen werden. Es müssen also sämtliche Benutzer, auch die im Active Directory der FHNW erfassten, manuell in das OpenLDAP Directory eingetragen werden. Eine Autorisierung
im eigentlichen Sinn wird gar nicht durchgeführt. Es wird lediglich überprüft, ob der angemeldete
Benutzer in der LDAP Gruppe für das entsprechende Repository ist. D.h. die LDAP Struktur ist so
aufgebaut, dass einzelne Benutzer in Gruppen, passend zu den jeweiligen Repositories, erfasst sind.
In der Apache Konfiguration wird dann für jedes Repository eine Location angelegt. Innerhalb dieser
Location wird mittels der Require ldap-group Direktive spezifiziert, in welcher LDAP Gruppe der
Benutzer sein muss, um sich erfolgreich authentifizieren zu können. Um die Apache Konfigurationsdateien synchron zur LDAP Struktur zu halten, läuft regelmässig ein relativ komplexes, schwer zu
wartendes Bash Script ab. Dieses erstellt anhand der LDAP Struktur die einzelnen Locations für die
Repositories. Der Nachteil hier ist, dass jedesmal der Apache Server neugestartet werden muss, sobald
das Script durchgelaufen ist, um die neue Konfiguration zu übernehmen.
1.2. Problemstellung
Dieser Aufbau ist für die Verwalter der Repositories nicht zufrieden stellend, da sämtliche Benutzer manuell in den OpenLDAP-Server eingetragen werden müssen, obwohl sämtliche schulinternen
Benutzer bereits im Active Directory der FHNW vorhanden wären.
Deshalb soll eine Gesamtlösung gefunden werden, welche die Benutzerdaten für schulinterne Benutzer
aus dem Active Directory der FHNW ausliest (damit die Benutzer sich mit dem üblichen Benutzernamen und Passwort anmelden können) und die Berechtigungen in einer Datenbank speichert. Zusätzlich
sollen externe Benutzer – welche nicht im Active Directory der FHNW vorhanden sind – erfasst und
gespeichert werden können.
1
2. Konzept
Dieses Kapitel beinhaltet die möglichen Lösungsvarianten zur Authentifizierung und Autorisierung
von SVN Repository Benutzern.
Zusammengefasst enthält dieses Kapitel die folgenden zwei Lösungsvarianten:
• Authentifizierung und Autorisierung via Shibboleth und die Verwaltung von Gastbenutzern über
den Virtual Home Organization Service von Switch.
• Authentifizierung der Benutzer auf Basis von drei LDAP Servern (EDU, ADM und OpenLDAP
Verzeichnisserver) zusammengefasst in einem virtuellen Directory Server und die Autorisierung
über eine separate SQL Datenbank.
2.1. Anforderungen
Die Lösung soll folgende Anforderungen abdecken:
• Im Active Directory erfasste Benutzer sollen sich via SVN Client authentifizieren können.
• Gastbenutzer, welche nicht im Active Directory sondern separat erfasst sind, sollen sich ebenfalls
via SVN Client authentifizieren können.
• Autorisierung der Benutzer, d.h. Vergabe von Berechtigungen auf Repository Ebene, allenfalls
auch auf Unterordern.
• Auf das Active Directory darf nur lesend zugegriffen werden.
Für detailliertere Informationen bezüglich den Anforderungen wird auf das Pflichtenheft verwiesen.
2
Kapitel 2. Konzept
2.2. Lösungsvarianten
2.2. Lösungsvarianten
Dieser Abschnitt soll die verschiedenen Lösungsvarianten konzeptionell erläutern und die Vor- und
Nachteile aufzeigen.
2.2.1. Variante 1: Shibboleth
Die Variante Shibboleth wird in diesem Kapitel aufgrund der ursprünglichen Aufgabenstellung erläutert. Es geht in diesem Abschnitt darum, aufzuzeigen, was die Umsetzung dieser Variante für das
Projekt bedeutet.
Was ist Shibboleth?
Shibboleth ist ein vom Internet2/MACE entwickeltes Verfahren zur verteilten Authentifizierung und
Autorisierung für Webanwendungen und Webservices. Das Konzept von Shibboleth sieht vor, dass der
Benutzer sich nur einmal bei seiner Heimateinrichtung authentisieren muss, um ortsunabhängig auf
Dienste oder lizenzierte Inhalte verschiedener Anbieter zugreifen zu können (engl. Single Sign-On).
Shibboleth basiert auf einer Erweiterung des Standards SAML.1
Allgemeines zu Shibboleth
Abbildung 2.1.: Ablauf der Shibboleth Authentifizierung
1
http://de.wikipedia.org/wiki/Shibboleth (Internet)
Bachelor Thesis
3
SVN Authentifizierung und Autorisierung
Kapitel 2. Konzept
2.2. Lösungsvarianten
In Abbilung 2.1 ist grob der Ablauf der Shibboleth Authentifizierung dargestellt und zwar mit vollem
Funktionsumfang. Dazu gehört die Auswahl der Home Organization über den Where Are You From
”
Service“(1), die anschliessende Weiterleitung an den Identity Provider der Organisation (2) und nach
erfolgter Eingabe der Benutzerdaten und der erfolgreichen Authentifizierung die Weiterleitung auf die
effektive Ressource (3). Man sieht hier schon das primäre Einsatzgebiet der Shibboleth Authentifizierung, nämlich Single Sign On für Web Applikationen.
Authentifizierung interner Benutzer
Da nun aber der SVN Client (z.B. das Subversive SVN Plugin für Eclipse) weder die ”Where Are You
From” noch die Login Eingabemaske darstellen kann, ist hier eine abgespeckte Variante der Shibboleth
Authentifizierung gefragt. Switch.ch hat eine solche Lösung implementiert, welche gemäss Abbildung
2.2 funktioniert. Diese Art der Shibboleth Authentifizierung nimmt die Benutzerdaten über die HTTP
Basic Authentifizierung an und leitet den Benutzer anhand dieser Daten entweder auf die gewünschte
Webseite um (in diesem Fall eine WebDAV Seite wie sie auch für SVN verwendet wird) oder verweigert
den Zugriff.
DAV Client mit
Basic Auth
2
4
Login Daten
HTTPS
Datenaustausch (SSL)
1
HTTP Redirect (SSL)
3
User's Home
Org (IdP)
Resource
(DAV SVN)
Abbildung 2.2.: Ablauf der Shibboleth DAV Basic Authentifizierung
Kernstück der Shibboleth Authentifizierungsmethode ist die Umleitung des Benutzers nach Eingabe
der Login Daten und die Abspeicherung der Zugriffsberechtigung in Session Cookies. Genau diese Umleitung und die Speicherung der Cookies stellen das Hauptproblem im Zusammenhang mit den SVN
Clients dar. Die meisten SVN Clients, darunter auch das äusserst umfangreiche Eclipse Subversive
SVN Plugin, unterstützen weder HTTP Redirects noch Session Cookies.
Bachelor Thesis
4
SVN Authentifizierung und Autorisierung
Kapitel 2. Konzept
2.2. Lösungsvarianten
Um die HTTP Redirects abzufangen und die Session Cookies abzuspeichern, sind zwei Lösungsmöglichkeiten denkbar. Entweder wird das bestehende Shibboleth Apache Modul so angepasst, dass die
HTTP Redirects abgefangen werden oder es wird eine Zwischenschicht in Form eines transparenten
Shibboleth Proxy Servers oder eines eigenen Apache Moduls entwickelt, welche die HTTP Redirects
abfängt und die Session Cookies abspeichert. Abbildung 2.3 zeigt diese Variante grafisch.
SVN Client mit
Basic Auth
Login Daten
1
4
Login Daten
Datenaustausch
1
Zwischenschicht
(Proxy oder Apache Modul)
Session Cookie
Store
2
4
HTTPS
Datenaustausch (SSL)
HTTP Redirect (SSL)
3
User's Home
Org (IdP)
Resource
(DAV SVN)
Abbildung 2.3.: Ablauf der Shibboleth DAV Basic Authentifizierung mit Zwischenschicht
Bachelor Thesis
5
SVN Authentifizierung und Autorisierung
Kapitel 2. Konzept
2.2. Lösungsvarianten
Authentifizierung externer Benutzer
Für Benutzer, die nicht im Active Directory der FHNW erfasst sind, aber dennoch auf ein SVN
Repository zugreifen können sollen, gibt es zwei Möglichkeiten für die Authentifizierung.
Eine Variante sieht vor, die externen Benutzer in der sog. Virtual Home Organization zu erfassen. Dabei
werden die Benutzer unabhängig vom Active Directory der FHNW erfasst, sind aber dennoch in der
Lage sich via Shibboleth zu authentifizieren. Nähere Details dazu unter [1]. Eine andere Möglichkeit ist
die Bereitstellung einer anderen URL für die externen Benutzer, sprich die Konfiguration einer weiteren
Apache Location mit einer LDAP Authentifizierung gegen den schon bestehenden OpenLDAP Server.
Autorisierung
Gemäss Recherchen und Tests lässt sich die Autorisierung über die Shibboleth XML Konfigurationsdateien auf dem Apache DAV SVN Server realisieren. Dabei wird angegeben, welcher Benutzer auf
welchen URL Teil Zugriff hat. Hier ist zu erwähnen, dass die bestehenden Apache Autorisierungsmodule nicht auf den Benutzernamen zugreifen können, da dieser nicht mitgeliefert wird. Das DAV SVN
Autorisierungsmodul kann somit nicht verwendet werden.
Listing 2.1 zeigt zur Autorisierung einen Codeausschnitt aus der Shibboleth XML Konfigurationsdatei.
Listing 2.1: Shibboleth XML Autorisierung
<RequestMapper type =”N a t i v e ”>
<RequestMap a p p l i c a t i o n I d =”d e f a u l t ”>
<Host name = ”1 4 7 . 8 6 . 9 . 1 3 4 ”>
<Path name=”/ s h i b b o l e t h / gruppe1 ” authType=”s h i b b o l e t h ”
r e q u i r e S e s s i o n =”t r u e ”>
<A c c e s s C o n t r o l >
<Rule r e q u i r e =”u i d ”>demouser </Rule>
</A c c e s s C o n t r o l >
</Path>
</Host>
</RequestMap>
</RequestMapper>
Bachelor Thesis
6
SVN Authentifizierung und Autorisierung
Kapitel 2. Konzept
2.2. Lösungsvarianten
2.2.2. Variante 2: Direkte Abfrage der LDAP Verzeichnisse
Ziel dieser Lösung ist die Nutzung der LDAP Funktionalität des Apache Servers. Der Apache Server
soll direkt über das LDAP Protokoll mit einem Directory Server kommunizieren, um den Benutzer
zu authentifizieren. Als solcher kommt hier ein virtueller Directory Server zum Einsatz, welcher die
Inhalte der verschiedenen LDAP Server (OpenLDAP, EDU Domain Controller und ADM Domain
Controller) zu einem gemeinsamen Directory zusammenfasst. Abbildung 2.4 zeigt den Ablauf der
Authentifizierung und Autorisierung, welche in den folgenden Kapiteln erläutert wird.
SVN
Repositories
Apache
hole Daten
aus Repo
DAV SVN
Modul
5
liefere Daten
6
Authz DB
SVN Modul
SVN Client
4
autorisiere
Benutzer
2
HTTP Basic Auth (SSL)
LDAP
Modul
Login Daten
Authorization
DB
3
authentifiziere
Benutzer
1
Active
Directory
Legende:
Virtual LDAP
Directory
(Proxy)
existierende Module
zu erstellendes bzw. anzupassendes Modul
OpenLDAP
Abbildung 2.4.: Ablauf der LDAP SVN Authentifizierung und Autorisierung
Authentifizierung interner und externer Benutzer
Mit den internen Benutzern sind diejenigen Benutzer gemeint, welche über einen FHNW Active Directory Account verfügen. Externe Benutzer sind Benutzer, welche nicht im Active Directory der Schule
erfasst sind, jedoch trotzdem auf die SVN Repositories zugreifen können sollen. Diese externen Benutzer sind in einem separaten, schon bestehenden OpenLDAP Server erfasst.
Der Benutzer gibt seine E-Mail Adresse und sein Passwort in die Eingabemaske des SVN Clients ein.
Diese Login Daten werden an den Apache Server, genauer an das LDAP Modul gesendet, und der
Benutzer wird über den virtuellen LDAP Server authentifiziert. Der virtuelle LDAP Server kombiniert
die beiden Benutzerverzeichnisse (Active Directory und OpenLDAP) zu einem virtuellen Directory. Es
wird nicht effektiv ein kombiniertes Directory erstellt. Die Abfragen werden vom virtuellen Directory
Server immer noch direkt an den entsprechenden Directory Server geschickt. Das Apache LDAP Modul kommuniziert also lediglich mit dem virtuellen Directory Server und dieser schickt die Anfrage an
die beiden Server (siehe Grafik 2.4 Schritt 3). Als virtueller Directory Server (Virtual LDAP Directory
Bachelor Thesis
7
SVN Authentifizierung und Autorisierung
Kapitel 2. Konzept
2.2. Lösungsvarianten
in der Grafik 2.4) wird der Penrose Server 1.2.4 eingesetzt (siehe [2]). Dies ist nicht die neuste Version von Penrose. Aktuell existiert die Version 2.0 als neuster Release. Tests mit dieser Version haben
jedoch gezeigt, dass diese weit entfernt von Stabilität und Zuverlässigkeit operiert. Bestenfalls kann
diese als Beta Version angesehen werden. Daher haben wir uns für die stabile Version 1.2.4 entschieden.
Listing 2.2 zeigt die DAV SVN Authentifizierungskonfiguration. Der Penrose Server läuft in dieser
Konfigurationsumgebung auf dem gleichen Server wie der Apache2 Webserver.
Listing 2.2: Apache SVN LDAP Authentifizierung
<L o c a t i o n / p e n r o s e >
DAV svn
SVNParentPath / data / t e s t R e p o s
# connection to penrose s e r v e r
AuthBasicProvider ldap
AuthType B a s i c
AuthzLDAPAuthoritative o f f
AuthName ”S V N P e n r o s e A u t h e n t i c a t i o n ”
AuthLDAPURL ”l d a p : / / l o c a l h o s t : 1 0 3 8 9 / ou=prod ,DC=edu ,DC=ds ,DC=fhnw ,
DC=ch ? m a i l ? sub ? ( o b j e c t C l a s s=u s e r ) ” NONE
AuthLDAPBindDN ”u i d=admin , ou=system ”
AuthLDAPBindPassword s e c r e t
r e q u i r e v a l i d −u s e r
</L o c a tio n >
Autorisierung
Nachdem der Benutzer erfolgreich authentifiziert wurde, erfolgt die Autorisierung. Als Grundlage für
die Autorisierung dient der vom SVN Client übermittelte Benutzername, was der angegebene E-Mail
Adresse entspricht. Schritt 4 in der Grafik 2.4 zeigt den Ablauf der Autorisierung. Es wird eine Anfrage
an die Authorization DB gestartet, wobei überprüft wird, ob der Benutzer auf den gewünschten SVN
Pfad Zugriff hat. Ist die Autorisierung erfolgreich, werden die angeforderten SVN Daten im Schritt 6
an den SVN Client gesendet.
Für die Kommunikation mit der Autorisierungs DB existiert das Modul mod authz svn db. Dieses
Modul ist jedoch noch nicht zu 100% fertiggestellt und wurde erst unter Free BSD erfolgreich getestet.
Hier muss evtl. noch etwas Aufwand betrieben werden, damit dieses auch unter Linux einwandfrei
läuft. Details zu diesem Modul sind unter [3] zu finden.
Bachelor Thesis
8
SVN Authentifizierung und Autorisierung
Kapitel 2. Konzept
2.3. Entscheid
2.3. Entscheid
Bevor der Entscheid zugunsten einer Lösung fiel, wurden die Kernkomponenten der beiden Varianten getestet. Bei der Variante Shibboleth gibt es technische Probleme. Es ist nicht möglich, ohne
HTTP Redirects und Session Cookies auszukommen. Beides wird von den meisten SVN Clients nicht
unterstützt. So müsste ein Shibboleth Proxy für die Authentifizierung programmiert werden. Die Programmierung dieses Proxies würde voraussichtlich aber alleine schon die ganze zur Verfügung stehende
Zeit für die Bachelor Thesis in Anspruch nehmen. Daher käme hier die Autorisierung zu kurz.
Der Entscheid fiel daher zugunsten der LDAP Variante. Diese Variante deckt die Authentifizierung
und die Autorisierung ab und ist im verfügbaren Zeitfenster realisierbar.
Bachelor Thesis
9
SVN Authentifizierung und Autorisierung
3. Abweichung vom Konzept
Dieses Kapitel geht auf die Änderungen gegenüber dem Konzept sowie deren Begründung ein.
3.1. Modul mod authn alias anstelle von Penrose
Penrose [2] ist ein Java basierter virtual directory server. Er erlaubt es mehrere verschiedene Quellen
von Daten (in unserem Fall Benutzer-Zugangsdaten) wie LDAP-Strukturen, Datenbanken, einfache
Textdateien und Webservices zusammenzufassen und diese als einzelne LDAP-Struktur wiederzugeben.
Eine Demonstration der kompletten Funktionalität ist unter [4] zu finden.
Für den Zweck dieser Arbeit wurde eine Zusammenfassung von zwei verschiedenen LDAP-Strukturen
(OpenLDAP und Active Directory) genutzt. Da Penrose aber einen sehr grossen Funktionsumfang
besitzt, ist die Übersichtlichkeit eher mässig und die Erstellung einer relativ simplen, virtuellen LDAPStruktur kompliziert.
Hinzu kommt, dass scheinbar das Penrose Studio nicht sehr sauber programmiert wurde, was dazu
führte, dass die Applikation des öfteren abstürzte, ohne die gemachten Änderungen zu speichern.
Aus diesen Gründen wurde das Apache-Modul mod authn alias [5] verwendet, auf welches uns Matthias Krebs aufmerksam gemacht hatte. Das Alias-Modul erlaubt die Authentifizierung gegen mehrere
Quellen (in unserem Fall LDAP-Strukturen) mit sogenannten Aliasen. Diese Aliase können dann mit
den Apache-Direktiven AuthBasicProvider oder AuthDigestProvider verwendet werden. Die Aliase
werden in der angegebenen Reihenfolge abgearbeitet.
10
4. Implementation
Dieses Kapitel beschreibt die einzelnen Komponenten der Gesamtlösung, sowie deren Zusammenspiel
als Ganzes.
4.1. Funktionsweise
Nachfolgend wird die ganze Implementation mit Hilfe der Grafik 4.1 zusammenfassend erklärt. Der
Benutzer gibt seine Login Daten beim SVN Client ein (1). Anschliessend sendet der Client eine verschlüsselte HTTP WebDAV Anfrage mit Basic Authentifizierung an den Apache Server (2). Dieser
bearbeitet die Anfrage anschliessend mit den einzelnen Modulen. Nach der HTTP Verarbeitung sendet das LDAP Modul mit Hilfe der über das Alias Modul definierten LDAP Server Verbindungen
Bind Requests an die einzelnen LDAP Server (3). Die Server werden in der angegebenen Reihenfolge
abgearbeitet. Sobald ein Server einen erfolgreichen Bind durchführen kann, werden die anderen Server
nicht mehr abgefragt. Das bedeutet, dass der erste Server, welcher den Benutzer authentifizieren kann,
gewinnt. Daraus lässt sich ableiten, dass es wohl sinnvoll ist, denjenigen Server als erstes anzugeben,
welcher die am häufigsten verwendeten Benutzernamen enthält. Sobald der Benutzer authentifiziert
ist, wird mittels der Autorisierung überprüft, ob der Benutzer Rechte auf dem gewünschten Repository
hat (4). Die Berechtigungen sind in der MySQL Datenbank definiert. Wenn bis hierhin alles geklappt
hat, werden die Daten aus dem SVN Repository an den Client geliefert (5 und 6).
SVN
Repositories
Apache
5
DAV SVN
Modul
6
hole Daten
aus Repo
liefere Daten
Authz SVN
DB Modul
SVN Client
4
2
HTTP Basic Auth (SSL)
autorisiere
Benutzer
3
LDAP
Modul
Login Daten
Alias Modul
authentifiziere
Benutzer
1
3
OpenLDAP
3
Active
Directory
EDU
3
Active
Directory
ADM
Abbildung 4.1.: Ablauf der Authentifizierung und Autorisierung
11
Authorization
DB
Kapitel 4. Implementation
4.2. Konfiguration
4.2. Konfiguration
Dieser Abschnitt zeigt auf, wie die Gesamtlösung aufgebaut ist und dient als Leitfaden, um diese zu
implementieren.
4.2.1. Verwendete Hard- und Software
Verwendete Systeme
System
Rechner 1:
Intel Pentium 4, 3.0 GHz
1 GB RAM
Rechner 2:
Intel Core 2 Duo 2.4 GHz
4 GB RAM
Virtuelle Maschine 1:
2x 2.4 GHz Prozessor zugewiesen
1 GB RAM
Virtuelle Maschine 2:
1x 2.4 GHz Prozessor zugewiesen
1 GB RAM
Zweck
Server für Apache, MySQL und OpenLDAP
Server für virtuelle Maschinen
Windows Domain Controller für Testdomäne
Entwicklungs- und Testsystem für Apache Module
Verwendete Betriebssyteme
Betriebssystem
Debian 5 32bit Linux mit Kernel 2.6.26-1-686
Debian 5 64bit Linux mit Kernel 2.6.26-1-amd64
Windows 2003 Server R2 Service Pack 2
Einsatz
Rechner 1, Virtuelle Maschine 2
Rechner 2
Virtuelle Machine 1
Verwendete Software
Softwarepaket
Apache 2.2.9 aus dem Debian Lenny Paket Repository
SVN 1.5.1 aus dem Debian Lenny Paket Repository
Apache SVN Module Version 1.5.1 aus dem Debian Lenny Paket Repository
OpenLDAP Server Version 2.4.11-1 aus dem Debian Lenny Paket Repository
MySQL Server Version 5.0.51a aus dem Debian Lenny Paket Repository
Eclipse 3.4.1 C/C++ Edition
VMware Server 2.0.1
Einsatzort
Rechner 1
Rechner 1
Rechner 1
Rechner 1
Rechner 1
Rechner 1
Rechner 2
4.2.2. SVN
Die SVN Repositories – welche die zu schützenden Ressourcen darstellen – wurden mit dem Tool
svnadmin erstellt. Dieses erstellt mit der Option svnadmin create <repo Name> das gewünschte Repository. Das ist alles, was von der SVN Seite her erledigt werden muss. Die restlichen Einstellungen
Bachelor Thesis
12
SVN Authentifizierung und Autorisierung
Kapitel 4. Implementation
4.2. Konfiguration
werden mittels der Konfiguration des Apache Servers vorgenommen. Details zur Konfiguration von
SVN können unter [6] gefunden werden.
4.2.3. Apache
Als Grundstein dieser Lösung fungiert eine Standardinstallation von Apache mit den zuvor erwähnten
SVN Modulen.
Verwendete Module
Folgende Module wurden, abgesehen von den Apache Core Modulen, für die Gesamtlösung verwendet.
Bis auf das Modul mod authz svn db werden alle Module mit der Standardinstallation von Apache
mitgeliefert. Es werden jeweils die wichtigsten Funktionen und deren Konfiguration erklärt.
• mod ssl
Das Modul mod ssl [7] erweitert den Apache Webserver um die Möglichkeit, SSL bzw. TLS
geschützte Verbindungen aufzubauen. Das Modul wird mit der Grundinstallation von Apache
mitgeliefert. Es muss lediglich konfiguriert und aktiviert werden.
Folgende Zeilen in der Datei /etc/apache2/sites-enabled/default-ssl mussten angepasst
werden:
– SSLCACertificateFile /etc/ssl/imvs.technik.fhnw.ch/ca.crt
– SSLCertificateFile /etc/ssl/imvs.technik.fhnw.ch/server.crt
– SSLCertificateKeyFile /etc/ssl/imvs.technik.fhnw.ch/server.key
• mod auth basic
Das Modul mod auth basic [8] erlaubt die HTTP Basic Authentifizierung indem es die angegebenen Benutzerdaten gegen einen sogenannten Provider abgleicht. Durch die Kombination
mit mod ssl werden die Authentifizierungsdaten zwischen dem SVN Client und dem Apache
Webserver verschlüsselt übertragen.
• mod ldap
Das Modul mod ldap [9] erweitert die Apache Standard Libraries für LDAP, indem es einen
Connection-Pool sowie einen shared memory cache verwendet. Dadurch wird die Performance
der LDAP Authentifizierung gesteigert.
• mod authnz ldap
Das Modul mod authnz ldap [10] erweitert Apache – genauer das Modul mod auth basic – um die
Funktionalität der Anbindung von LDAP-Servern zur Authentifizierung von Benutzern. Zudem
erlaubt es die Verbindung zu den LDAP-Servern mit SSL/TLS zu verschlüsseln. Dies war mit
dem Active Directory der FHNW jedoch nicht möglich (siehe: 5.2.2), da das Zertifikat abgelaufen
war.
Bachelor Thesis
13
SVN Authentifizierung und Autorisierung
Kapitel 4. Implementation
4.2. Konfiguration
Damit eine LDAP-Struktur überhaupt durchsucht werden kann, muss bei gewissen LDAP Servern (dazu gehört unter anderem Active Directory) zuerst ein LDAP-Bind durchgeführt werden.
Dies muss mit einem Benutzer, welcher in der jeweiligen LDAP-Struktur vorhanden ist, durchgeführt werden.
Listing 4.1: OpenLDAP-Bind
AuthLDAPBindDN ”CN=admin , dc=imvs , dc=t e c h n i k , dc=fhnw , dc=ch ”
AuthLDAPBindPassword 1234
AuthLDAPURL l d a p : / / l o c a l h o s t : 3 8 9 /DC=imvs ,DC=t e c h n i k ,DC=fhnw ,DC=ch ? cn ?
sub ? ( o b j e c t C l a s s=p e r s o n ) NONE
Listing 4.1 zeigt die Bind Konfiguration für den OpenLDAP Server. Der AuthLDAPBindDN ist
der Distinguished Name des Benutzers, mit dem der Bind durchgeführt werden soll, wobei der
DN in typischer LDAP-Syntax angegeben werden muss.
Das AuthLDAPBindPassword ist selbstredend das Passwort des Benutzers von AuthLDAPBindDN.
Die AuthLDAPURL ist die LDAP-Adresse des Suchbaumes. In diesem Beispiel wird mit ?sub definiert, dass unterhalb des Baumes imvs.technik.fhnw.ch nach dem Common Name, definiert
durch ?cn, gesucht werden soll. Das Schlüsselwort objectClass=person sagt aus, dass die zu suchenden Objekte vom Typ person sein sollen. Mit Hilfe von AuthLDAPURL können auch mehrere,
redundante Server angegeben werden. Ein Beispiel dazu ist unter A.5 zu finden.
Damit nicht bei jeder Anfrage des gleichen Benutzers die ganze LDAP-Struktur durchsucht
werden muss, speichert das mod ldap Modul von Apache die bereits gemachten Abfragen in einem
Cache. Dies verbessert die Performance deutlich, da der Cache sehr viel schneller durchsucht
werden kann.
• mod authn alias
Wie bereits in 3.1 erklärt, wurde anstelle von Penrose das Modul mod authn alias [5] benutzt,
um gegen mehrere Provider zu authentifizieren.
In einem ersten Schritt werden in der Konfiguration die Aliase definiert:
Listing 4.2: Definition eines Aliases
<A u t h n P r o v i d e r A l i a s l d a p openldap>
AuthLDAPBindDN ”CN=admin , dc=imvs , dc=t e c h n i k , dc=fhnw , dc=ch ”
AuthLDAPBindPassword 1234
AuthLDAPURL l d a p : / / l o c a l h o s t : 3 8 9 /DC=imvs ,DC=t e c h n i k ,DC=fhnw ,
DC=ch ? cn ? sub ? ( o b j e c t C l a s s=p e r s o n ) NONE
</A u t h n P r o v i d e r A l i a s >
Details zur Konfiguration der Aliase sind im Anhang unter A.5 zu finden.
Danach kann mittels AuthBasicProvider angegeben werden, welche dieser - mittels Aliasen
definierten Provider - verwendet werden sollen. Wie schon in 4.1 erwähnt, werden die Aliase in
der definierten Reihenfolge abgearbeitet.
Listing 4.3: Referenzierung der Aliase
<L o c a t i o n / a l i a s >
...
#A u t h e n t i c a t i o n s e c t i o n
Bachelor Thesis
14
SVN Authentifizierung und Autorisierung
Kapitel 4. Implementation
4.2. Konfiguration
A u t h B a s i c P r o v i d e r openldap ad−s t u d ad−adm
AuthType B a s i c
AuthName ”SVN Anmeldung ”
r e q u i r e v a l i d −u s e r
...
</L o c a t i o n >
Mehr dazu im Anhang unter A.5
• mod dav
Das Modul mod dav [11] erweitert Apache um die Funktionalität von WebDAV (,Web-based
Distributed Authoring and Versioning‘).
• mod dav svn
Das Modul mod dav svn von Tigris.org [12] ermöglicht, dass SVN-Clients per HTTP(S) – anstelle des SVN eigenen Protokolls svnserve – auf die Repositories zugreifen können.
• mod authz svn db
Das Modul mod authz svn db von Christopher Wojno [3] ist eine Erweiterung des Moduls
mod authz svn [12], welches als Datenquelle für die Autorisierung der SVN Benutzer eine Textdatei verwendet.
Anstatt einer solchen Textdatei verwendet das Modul mod authz svn db eine Datenbank, was die
Änderung von Berechtigungen wesentlich komfortabler und einfacher macht. Details zu diesem
Modul sind unter 4.3.3 zu finden.
Bachelor Thesis
15
SVN Authentifizierung und Autorisierung
Kapitel 4. Implementation
4.2. Konfiguration
4.2.4. Datenbank
Nachfolgend sollen zwei Entity-Relationship-Diagramme (ERD) den Aufbau der MySQL-Datenbank
veranschaulichen und die Erklärung unterstützen.
ERD (Überblick)
In Abbildung 4.2 ist der Zusammenhang der wichtigsten Datenbank-Tabellen ersichtlich. Daraus abzulesen ist, dass ein User in beliebig vielen Groups sein kann und umgekehrt. Des weiteren ist es
möglich, die Berechtigungen pro Repository-Pfad direkt auf einem Benutzer zu setzten oder auf der
Gruppe, der er angehört. Zudem können zu einem Repository mehrere Unterpfade definiert werden.
Diese Unterpfade ermöglichen es, Benutzern feingranular unterschiedliche Berechtigungen auf einem
Repository zu erteilen.
User
Repository
n
n
1
m
n
m
Group
Repository Path
n
m
Abbildung 4.2.: ERD
ERD (Detailliert)
In Abbildung 4.3 ist der Zusammenhang aller Tabellen und deren Felder ersichtlich.
authz_svn_userpermission
authz_svn_user
user_id INT(11)
N P F
id INT(11)
repository_path_id INT(11)
N P F
name VARCHAR(255)
read TINYINT(1)
N
write TINYINT(1)
N
recursive TINYINT(1)
N
authz_svn_grouppermission
id INT(11)
A N P
group_id INT(11)
U N F
repository_path_id INT(11)
U N F
authz_svn_groupmembership
A N P
U N
Index user_name_idx(name)
authz_svn_repopath
id INT(11)
A N P
user_id INT(11)
U N F
group_id INT(11)
U N F
authz_svn_repository
id INT(11)
A N P
id INT(11)
repository_id INT(11)
U N F
name VARCHAR(255)
path VARCHAR(255)
U N
A N P
U N
Index repo_name_idx(name)
Legende
authz_svn_group
read TINYINT(1)
N
id INT(11)
write TINYINT(1)
N
name VARCHAR(255)
recursive TINYINT(1)
N
Index group_name_idx(name)
A N P
U N
A: Auto Increment
N: Not Null
P: Primary Key
F: Foreign Key
U: Unique
Abbildung 4.3.: Tabellen der Datenbank
Bachelor Thesis
16
SVN Authentifizierung und Autorisierung
Kapitel 4. Implementation
4.2. Konfiguration
Beim Erstellen des Datenbanklayouts wurde Wert darauf gelegt, für die Datenverwaltung möglichst
viele Funktionen des DBMS von MySQL zu nutzen. Dazu gehört, dass in einer Tabelle keine doppelten
Einträge existieren sollen, referentielle Integrität mit Löschweitergabe und Indizes für die schnelle
Suche von Daten.
Nachfolgend werden die einzelnen Tabellen und Felder der Datenbank erklärt.
authz svn user
Enthält die Benutzer, welchen Berechtigungen für Repositories erteilt werden sollen.
Feld
id
name
Erklärung
Benutzer ID
Benutzername wie er beim SVN Client oder im Browser mitgegeben wird
authz svn repository
Enthält die Repositories.
Feld
id
name
Erklärung
Repository ID
Name des Repositories, so wie er beim Zugriff im SVN
Client oder Browser angegeben wird. Wird z.B. über https://<server>/<repo name> darauf zugegriffen, wird <repo name> in dieses Feld eingetragen.
authz svn repopath
Enthält die Pfade der Repositories. Es können pro Repository beliebig viele Pfade erfasst werden.
Diese dienen dazu, Benutzern feingranulare Berechtigungen auf einzelnen Unterordnern oder Dateien
zu geben.
Feld
id
repository id
path
Erklärung
ID des Pfades
ID des Repositories (Fremdschlüssel)
Ein bestimmter Pfad im Repository. Z.B. </> für den Root
Pfad oder </Dokumente> für einen Unterordner
authz svn userpermission
Dient dem Zuweisen von Berechtigungen auf die Repository Pfade an einzelne Benutzer.
Feld
user id
repository path id
read
write
Bachelor Thesis
Erklärung
Benutzer ID (Fremdschlüssel)
ID des Repository (Fremdschlüssel)
1: Benutzer hat Leseberechtigung
0: Benutzer hat keine Berechtigungen auf dem Repository
Pfad
1: Benutzer hat Schreibberechtigung
0: Benutzer hat keine Schreibberechtigung
17
SVN Authentifizierung und Autorisierung
Kapitel 4. Implementation
recursive
4.2. Konfiguration
1: Benutzer hat unterhalb des zugeordneten Repository Pfades rekursive Berechtigung
0: Benutzer hat nur auf der Ebene des zugeordneten Repository Pfades Berechtigung, nicht aber darunter
authz svn group
Dient dazu, einer Gruppe einen aussagekräftigen Namen zu geben. Diese Tabelle ist optional und
wird für das Prüfen der Berechtigungen vom Modul mod authz svn db nicht benötigt. Wird diese
Tabelle weggelassen, entfällt jedoch auch die Möglichkeit, Gruppen und deren Berechtigungen durch
automatische Löschweitergabe in der gesamten Datenbank automatisch zu entfernen.
Feld
id
name
Erklärung
Gruppen ID
Aussagekräftiger Name der Gruppe
authz svn groupmembership
Ermöglicht das Zuordnen von Benutzern zu Gruppen.
Feld
id
user id
group id
Erklärung
Datensatz ID
ID des Benutzers (Fremdschlüssel)
ID der Gruppe (Fremdschlüssel)
authz svn grouppermission
Dient dem Zuweisen von Berechtigungen auf die Repository Pfade an einzelne Gruppen.
Feld
id
group id
repository path id
read
write
recursive
Erklärung
Datensatz ID
Gruppen ID (Fremdschlüssel)
ID des Repository (Fremdschlüssel)
1: Gruppe hat Leseberechtigung
0: Gruppe hat keine Berechtigungen auf dem Repository Pfad
1: Gruppe hat Schreibberechtigung
0: Gruppe keine Schreibberechtigung
1: Gruppe hat unterhalb des zugeordneten Repository Pfades
rekursive Berechtigung
0: Gruppe hat nur auf der Ebene des zugeordneten Repository Pfades Berechtigung, nicht aber darunter
Einschränkungen
Das Modul mod authz svn db unterstützt keine SSL Verbindung zur Datenbank. Dies ist nicht weiter
tragisch, da keine sensitiven Daten zum und vom MySQL Server übetragen werden, man muss sich
dessen einfach bewusst sein.
Bachelor Thesis
18
SVN Authentifizierung und Autorisierung
Kapitel 4. Implementation
4.3. Ablauf und Zusammenspiel im Detail
4.3. Ablauf und Zusammenspiel im Detail
Dieser Abschnitt soll den Ablauf einer Authentifizierung/Autorisierung im Detail beleuchten und somit
auch den Zusammenhang der einzelnen Komponenten erklären.
In diesem Beispiel will der Benutzer gery“ Zugriff auf ein Repository erhalten. Nachfolgend ist der
”
Ablauf beschrieben.
Es ist hier zu vermerken, dass sämtlicher Datenverkehr nur zu Zwecken der Anschauung nicht verschlüsselt abläuft – siehe Wireshark-Auszüge. In der effektiven Implementation ist dieser Verkehr per
SSL verschlüsselt und somit nicht abhörbar. Ausserdem wird anstelle des SVN Clients der Einfachheit
halber ein Browser verwendet, weil der DAV Datenaustausch einiges umfangreicher ist als der von
einfachem HTTP.
4.3.1. Client-Anfrage
Der SVN-Client – in Abbildung 4.4 vereinfacht dargestellt durch den Browser – schickt einen Request
an den Apache Server, um die Daten des Repository abzuholen. Damit der Request via HTTP – anstelle des SVN eigenen Protokolls – versendet werden kann, wird das Modul mod dav svn verwendet,
welche SVN-Repositories per WebDAV zur Verfügung stellt. Da die Repositories aber durch Authentifizierung/Autorisierung geschützt sind, wird die Anfrage bzw. werden die Benutzerdaten, welche dem
Client mitgegeben wurden, an die LDAP Provider (Authentifizierungs-Datenquellen) weitergeleitet.
Apache
Browser
HTTP GET /projectSVN/
DAV SVN
Modul
Abbildung 4.4.: Client Request
In Listing 4.4 ist eine per Wireshark abgefangene Anfrage vom Client dargestellt. Bei allen nachfolgenden Captures wurde Unnötiges (gekenntzeichnet durch ..“) weggelassen.
”
Listing 4.4: HTTP Capturing Details
GET / projectSVN / HTTP/ 1 . 1 \ r \n
Request Method : GET
Request URI : / projectSVN /
Request V e r s i o n : HTTP/ 1 . 1
Host : ad\ r \n
User−Agent : M o z i l l a / 5 . 0 ( Macintosh ; U; I n t e l Mac OS X 1 0 . 5 ; en−US ; rv
: 1 . 9 . 1 . 1 ) Gecko /20090715 F i r e f o x / 3 . 5 . 1 \ r \n
...
Bachelor Thesis
19
SVN Authentifizierung und Autorisierung
Kapitel 4. Implementation
4.3. Ablauf und Zusammenspiel im Detail
A u t h o r i z a t i o n : B a s i c Z2VyeTpnZXJ5MDk=\r \n
C r e d e n t i a l s : gery : gery09
Cache−C o n t r o l : max−age=0\ r \n
4.3.2. Authentifizierung
Die Benutzerdaten, welche vom Client erhalten wurden, werden nun auf ihre Gültigkeit überprüft. Dazu werden sie an die LDAP Provider weitergeleitet. In diesem Fall sind dies die drei LDAP-Strukturen:
Die schulinternen Active Directory Domänen EDU und ADM sowie der OpenLDAP-Server für externe
Benutzer.
Active Directory - EDU Da im Active Directory der FHNW der Common Name (bestehend aus Vorund Nachname eines Benutzers) nicht zwingend eindeutig sein muss, ist die Suche nach dem Attribut
mail sinnvoller, da die Mail-Addresse garantiert einzigartig ist unter allen Angehörigen der FHNW.
Da der Benutzer gery“ nicht in der EDU-Domäne des Active Directory vorhanden ist, werden 0
”
Resultate zurück geliefert. Siehe Abbildung 4.5.
Listing 4.5 zeigt die einzelnen, ausgetauschten LDAP Abfragen detailliert.
Apache
bindRequest "[email protected]"
bindResponse [success]
Alias Modul
LDAP Alias
edu
searchRequest "mail=gery"
Active Directory
EDU
searchResDone [0 results]
Abbildung 4.5.: EDU-Abfrage
Listing 4.5: LDAP Capture Details
LDAPMessage bindRequest ( 1 ) ” g e r a r d . b i e l i @ e d u . ds . fhnw . ch ” s i m p l e
messageID : 1
p ro t o c o l O p : bindRequest ( 0 )
bindRequest
version : 3
name : g e r a r d . b i e l i @ e d u . ds . fhnw . ch
authentication : simple (0)
s i m p l e : 2 B65757230737461722B
[ Response In : 6 8 ]
LDAPMessage bindResponse ( 1 ) s u c c e s s
messageID : 1
p ro t o c o l O p : bindResponse ( 1 )
bindResponse
resultCode : success (0)
Bachelor Thesis
20
SVN Authentifizierung und Autorisierung
Kapitel 4. Implementation
4.3. Ablauf und Zusammenspiel im Detail
matchedDN :
errorMessage :
[ Response To : 6 7 ]
[ Time : 0 . 0 0 9 1 2 6 0 0 0 s e c o n d s ]
LDAPMessage s e a r c h R e q u e s t ( 2 ) ”ou=edu , ou=prod ,DC=edu ,DC=ds ,DC=fhnw ,DC=ch ”
wholeSubtree
messageID : 2
p ro t o c o l O p : s e a r c h R e q u e s t ( 3 )
searchRequest
b a s e O b j e c t : ou=edu , ou=prod ,DC=edu ,DC=ds ,DC=fhnw ,DC=ch
scope : wholeSubtree (2)
d e r e f A l i a s e s : derefAlways (3)
sizeLimit : 0
timeLimit : 0
typesOnly : F a l s e
F i l t e r : (&( o b j e c t C l a s s=p e r s o n ) ( m a i l=g e r y ) )
f i l t e r : and ( 0 )
and : (&( o b j e c t C l a s s=p e r s o n ) ( m a i l=g e r y ) )
and : 2 i t e m s
F i l t e r : ( o b j e c t C l a s s=p e r s o n )
Item : e q u a l i t y M a t c h ( 3 )
equalityMatch
attributeDesc : objectClass
assertionValue : person
F i l t e r : ( m a i l=g e r y )
Item : e q u a l i t y M a t c h ( 3 )
equalityMatch
a t t ri b u t e De s c : mail
assertionValue : gery
a t t r i b u t e s : 1 item
Item : m a i l
[ Response In : 7 2 ]
LDAPMessage searchResDone ( 2 ) s u c c e s s [ 0 r e s u l t s ]
messageID : 2
p ro t o c o l O p : searchResDone ( 5 )
searchResDone
resultCode : success (0)
matchedDN :
errorMessage :
[ Response To : 7 0 ]
[ Time : 0 . 0 2 2 2 6 2 0 0 0 s e c o n d s ]
Bachelor Thesis
21
SVN Authentifizierung und Autorisierung
Kapitel 4. Implementation
4.3. Ablauf und Zusammenspiel im Detail
Active Directory - ADM Wie für die Domäne EDU gilt das oben Genannte auch für die Domäne
ADM. Da der Benutzer gery“ auch nicht in der ADM-Domäne des Active Directory vorhanden ist,
”
werden auch hier 0 Resultate zurück geliefert. Siehe Abbildung 4.6.
Listing 4.6 zeigt die einzelnen, ausgetauschten LDAP Abfragen detailliert. Da es sich hier prinzipiell
um das gleiche Vorgehen wie bei Listing 4.5 handelt, wird Unnötiges weggelassen.
Apache
bindRequest "[email protected]"
bindResponse [success]
Alias Modul
LDAP Alias
adm
searchRequest "mail=gery"
Active Directory
ADM
searchResDone [0 results]
Abbildung 4.6.: ADM-Abfrage
Listing 4.6: LDAP Capture Details
LDAPMessage bindRequest ( 1 ) ” g e r a r d . b i e l i @ e d u . ds . fhnw . ch ” s i m p l e
...
LDAPMessage s e a r c h R e q u e s t ( 2 ) ”OU=adm ,OU=Prod ,DC=adm ,DC=ds ,DC=fhnw ,DC=ch ”
wholeSubtree
...
LDAPMessage searchResDone ( 2 ) s u c c e s s [ 0 r e s u l t s ]
messageID : 2
p ro t o c o l O p : searchResDone ( 5 )
searchResDone
resultCode : success (0)
matchedDN :
errorMessage :
[ Response To : 8 5 ]
[ Time : 0 . 0 0 1 3 1 7 0 0 0 s e c o n d s ]
Bachelor Thesis
22
SVN Authentifizierung und Autorisierung
Kapitel 4. Implementation
4.3. Ablauf und Zusammenspiel im Detail
OpenLDAP Wie zu Beginn des Abschnitts schon gezeigt, wird auf dem OpenLDAP-Server nach dem
Attribut cn gesucht. Da der Benutzer gery“ auf diesem Server zu finden ist, wird als Resultat eben
”
dieser Benutzer geliefert. Danach folgt ein zweiter Bind, um das vom Client gelieferte Passwort zu
verifizieren. Da dies übereinstimmt, wird eine Erfolgsmeldung zurückgeliefert und der Benutzer gery“
”
ist somit authentifiziert. Siehe Abbildung 4.7.
Listing 4.7 zeigt die einzelnen, ausgetauschten LDAP Abfragen detailliert.
bindRequest "cn=admin"
Apache
bindResponse [success]
searchRequest "cn=gery"
Alias Modul
searchResEntry [1 entry]
LDAP Alias
openLDAP
searchResDone [1 result]
OpenLDAP
Directory
bindRequest "cn=gery"
bindResponse [success]
Abbildung 4.7.: OpenLDAP-Abfrage
Listing 4.7: LDAP Capture Details
LDAPMessage bindRequest ( 1 ) ”CN=admin , dc=imvs , dc=t e c h n i k , dc=fhnw , dc=ch ”
simple
messageID : 1
p ro t o c o l O p : bindRequest ( 0 )
bindRequest
version : 3
name : CN=admin , dc=imvs , dc=t e c h n i k , dc=fhnw , dc=ch
authentication : simple (0)
s i m p l e : 31323334
[ Response In : 9 4 ]
LDAPMessage bindResponse ( 1 ) s u c c e s s
messageID : 1
p ro t o c o l O p : bindResponse ( 1 )
bindResponse
resultCode : success (0)
matchedDN :
errorMessage :
[ Response To : 9 2 ]
[ Time : 0 . 0 0 0 4 8 9 0 0 0 s e c o n d s ]
LDAPMessage s e a r c h R e q u e s t ( 2 ) ”DC=imvs ,DC=t e c h n i k ,DC=fhnw ,DC=ch ”
wholeSubtree
messageID : 2
p ro t o c o l O p : s e a r c h R e q u e s t ( 3 )
searchRequest
b a s e O b j e c t : DC=imvs ,DC=t e c h n i k ,DC=fhnw ,DC=ch
Bachelor Thesis
23
SVN Authentifizierung und Autorisierung
Kapitel 4. Implementation
4.3. Ablauf und Zusammenspiel im Detail
scope : wholeSubtree (2)
d e r e f A l i a s e s : derefAlways (3)
sizeLimit : 0
timeLimit : 0
typesOnly : F a l s e
F i l t e r : (&( o b j e c t C l a s s=p e r s o n ) ( cn=g e r y ) )
f i l t e r : and ( 0 )
and : (&( o b j e c t C l a s s=p e r s o n ) ( cn=g e r y ) )
and : 2 i t e m s
F i l t e r : ( o b j e c t C l a s s=p e r s o n )
Item : e q u a l i t y M a t c h ( 3 )
equalityMatch
attributeDesc : objectClass
assertionValue : person
F i l t e r : ( cn=g e r y )
Item : e q u a l i t y M a t c h ( 3 )
equalityMatch
a t t r i b u t e D e s c : cn
assertionValue : gery
a t t r i b u t e s : 1 item
Item : cn
[ Response In : 9 7 ]
LDAPMessage s e a r c h R e s E n t r y ( 2 ) ”cn=gery , dc=imvs , dc=t e c h n i k , dc=fhnw , dc=ch ”
[1 result ]
messageID : 2
p ro t o c o l O p : s e a r c h R e s E n t r y ( 4 )
searchResEntry
objectName : cn=gery , dc=imvs , dc=t e c h n i k , dc=fhnw , dc=ch
a t t r i b u t e s : 1 item
Item cn
type : cn
v a l s : 1 item
gery
[ Response To : 9 6 ]
[ Time : 0 . 0 0 0 5 3 9 0 0 0 s e c o n d s ]
LDAPMessage searchResDone ( 2 ) s u c c e s s [ 1 r e s u l t ]
messageID : 2
p ro t o c o l O p : searchResDone ( 5 )
searchResDone
resultCode : success (0)
matchedDN :
errorMessage :
[ Response To : 9 6 ]
[ Time : 0 . 0 0 0 6 0 1 0 0 0 s e c o n d s ]
LDAPMessage bindRequest ( 3 ) ”cn=gery , dc=imvs , dc=t e c h n i k , dc=fhnw , dc=ch ”
simple
Bachelor Thesis
24
SVN Authentifizierung und Autorisierung
Kapitel 4. Implementation
4.3. Ablauf und Zusammenspiel im Detail
messageID : 3
p ro t o c o l O p : bindRequest ( 0 )
bindRequest
version : 3
name : cn=gery , dc=imvs , dc=t e c h n i k , dc=fhnw , dc=ch
authentication : simple (0)
s i m p l e : 676572793039
[ Response In : 1 0 1 ]
LDAPMessage bindResponse ( 3 ) s u c c e s s
messageID : 3
p ro t o c o l O p : bindResponse ( 1 )
bindResponse
resultCode : success (0)
matchedDN :
errorMessage :
[ Response To : 1 0 0 ]
[ Time : 0 . 0 0 0 2 3 2 0 0 0 s e c o n d s ]
4.3.3. Autorisierung
Nachdem der Benutzer gery“ nun authentifiziert ist, muss im nächsten Schritt geprüft werden, ob er
”
auf dem gewünschten Repository die benötigten Zugriffsberechtigungen hat (lesend/schreibend). Das
Modul mod authz svn db schaut dazu in der für die Autorisierung erstellten MySQL-Datenbank nach,
ob die Berechtigungen stimmen. Dazu wird ein SELECT-Statement abgesetzt und das Ergebnis auf die
gewünschten Attribute und Werte überprüft. Für Details zum SELECT Statement siehe A.3
4.3.4. Server-Antwort
Nachdem der Benutzer auch autorisiert ist – wenn er also mindestens Leseberechtigungen auf dem
gewünschten Repository hat – so werden die Daten per HTTP-Response vom Apache an den Client
zurückgeschickt, wie in Abbildung 4.8 ersichtlich ist. Falls der Benutzer auch Schreibrechte auf dem
Repository besitzt, kann er die Daten zusätzlich bearbeiten.
Listing 4.8 zeigt den Wireshark Auszug zur Serverantwort.
Apache
DAV SVN
Modul
HTTP 200 OK (text/html)
Browser
Abbildung 4.8.: Server Response
Bachelor Thesis
25
SVN Authentifizierung und Autorisierung
Kapitel 4. Implementation
4.3. Ablauf und Zusammenspiel im Detail
Listing 4.8: HTTP Capture Details
HTTP/ 1 . 1 200 OK\ r \n
Request V e r s i o n : HTTP/ 1 . 1
Response Code : 200
...
Line−based t e x t data : t e x t / html
<html><head><t i t l e >projectSVN − R e v i s i o n 1 0 9 : /</ t i t l e ></head>\n
<body>\n
<h2>projectSVN − R e v i s i o n 1 0 9 : /</h2>\n
<ul >\n
< l i ><a h r e f =”. p r o j e c t ”>. p r o j e c t </a></ l i >\n
< l i ><a h r e f =”Dokumente/”>Dokumente/</a></ l i >\n
< l i ><a h r e f =”mod authz svn db /”> mod authz svn db/</a></ l i >\n
< l i ><a h r e f =”p e n r o s e −s e r v e r /”> p e n r o s e −s e r v e r /</a></ l i >\n
</ul >\n
<hr noshade><em>Powered by <a h r e f =”h t t p : / / s u b v e r s i o n . t i g r i s . o r g
/”> S u b v e r s i o n </a> v e r s i o n 1 . 5 . 1 ( r 3 2 2 8 9 ) .</em>\n
</body></html>
Dies bezeichnet den kompletten Ablauf einer typischen Repository-Abfrage.
Bachelor Thesis
26
SVN Authentifizierung und Autorisierung
5. Probleme
Dieses Kapitel soll auf grössere, zeitintensive Probleme eingehen, welche während der Arbeit aufgetreten sind.
5.1. Penrose
5.1.1. Probleme mit Umlauten
Beschreibung
Nach dem Einrichten des Penrose Servers und der Kombination der zwei LDAP Verzeichnisse (Active
Directory und OpenLDAP), funktionierte die Authentifizierung zunächst einwandfrei. Als jedoch versucht wurde, die Authentifizierung mit Benutzern durchzführen, welche Umlaute im Namen haben,
wurde die Anmeldung verweigert. Wie sich herausstellte, lag das Problem einerseits am Aufbau des
Active Directory Verzeichnisses und andererseits an einem Fehler im Penrose Server. Im Active Directory sind die CNs (Common Name, bestehend aus Vor- und Nachname) und infolge dessen auch
die DNs (Distinguished Name, der eindeutige Bezeichner für den Eintrag) mit enthaltenen Umlauten
abgespeichert. Nachfolgend ein Beispiel eines DNs.
Listing 5.1: DN eines Eintrages mit Umlaut
CN=B i e l i , Gérard ,OU=b ,OU=1862 2006 ,OU=S t u d e n t e n I W i n d i s c h ,OU=u s e r s ,OU=62
I ,OU=WI,OU=18 ,OU=edu ,OU=prod ,DC=edu ,DC=ds ,DC=fhnw ,DC=ch
Analyse
Um das Problem sauber analysieren zu können, vor allem um saubere Captures aufnehmen zu können,
wurden die Komponenten Apache Server und Penrose Server auf zwei verschiedene Rechner verteilt.
Wie in der Grafik 5.1 ersichtlich, wurde der Datenverkehr zwischen dem Apache Server und dem
Penrose Server abgehört, sowie zwischen dem Penrose und dem Windows 2003 Server.
Auf den Grafiken 5.2 und 5.3 sind die mit Wireshark aufgenommen Captures zu sehen. Wie dort
ersichtlich ist, liefert der Windows 2003 Server (IP 10.51.2.40) das Suchresultat (searchResEntry)
korrekt. Danach liefert der Penrose Server dieses Suchresultat mit – gemäss LDAP Spezifikation –
korrekt umgewandeltem Sonderzeichen zurück an den Apache Server. Der Apache Server versucht nun
ein Bind mit dem erhaltenen DN und dem vom Benutzer eingegebenen Passwort durchzuführen. Dazu
schickt er gemäss 5.2 den vom Penrose Server erhaltenen DN in gleicher Form zurück. Der Penrose
Server seinerseits leitet diesen Bindrequest an den Windows 2003 Server weiter. Hier liegt nun das
Problem. Der Penrose Server wandelt das Sonderzeichen an dieser Stelle nochmals um und versucht
ein Bind mit diesem ungültigen DN. Daher schlägt der Bind fehl und der Benutzer kann sich nicht
anmelden.
27
Kapitel 5. Probleme
5.1. Penrose
Penrose environment
Debian 5 (32bit)
(IP: 192.168.1.1)
Apache2
LDAP Module
Debian 5 (64bit)
(IPs: 192.168.1.2 &
10.196.134.139)
Capture 1
Penrose
Server 1.2.4
Windows 2003
(IP: 10.51.2.40)
Capture 2
Active
Directory
Abbildung 5.1.: Penrose Testumgebung
Bachelor Thesis
28
SVN Authentifizierung und Autorisierung
Kapitel 5. Probleme
Bachelor Thesis
5.1. Penrose
Abbildung 5.2.: Capture 1
29
SVN Authentifizierung und Autorisierung
Kapitel 5. Probleme
Bachelor Thesis
5.1. Penrose
Abbildung 5.3.: Capture 2
30
SVN Authentifizierung und Autorisierung
Kapitel 5. Probleme
5.2. Apache
Lösung
Nach intensivem Debugging wurde die Lösung für das Problem gefunden. Die Problemursache lag in
einer vom Penrose Server verwendeten Library und zwar in der Apache Directory Library (sharedldap-0.9.5.4.jar). Schliesslich musste, gemäss Listing 5.2, lediglich eine Zeile Code geändert werden.
Listing 5.2: Geänderter Code in org.apache.directory.shared.ldap.name.LdapDN.java
public S t r i n g toNormName ( ) {
...
// Line 2 8 0 :
// b y t e s = S t r i n g T o o l s . g e t B y t e s U t f 8 ( newNormName ) ;
// changed t o
b y t e s = S t r i n g T o o l s . g e t B y t e s U t f 8 (upName ) ;
...
}
In der String Variable newNormName wird von der Library ein normalisierter DN String abgelegt,
welcher dann für den Bind beim Active Directory Server verwendet wird. Diese Normalisierung ist
überflüssig und wurde daher entfernt. Danach funktionierte alles reibungslos.
5.2. Apache
5.2.1. Kompilieren des Moduls mod authz svn db
Aufgrund der äusserts mangelhaften Dokumentation bereitete das Kompilieren des Moduls etwas
Schwierigkeiten. Es war zu Beginn nicht klar, was für Libraries verfügbar sein müssen und wie dieses Modul zu kompilieren ist. Diese Informationen mussten alle aus dem Source Code herausgelesen
werden. Ausserdem war es nicht möglich, das Modul mit dem mitgelieferten Makefile zu kompilieren,
da dieses den GCC anstatt des für die Apache Modul Kompilierung üblichen apxs Tools verwendet.
Nach dem Kompiliervorgang, welcher dann mit dem apxs Tool problemlos verlief, wurde die Datenbank gemäss der Dokumentation zum mod authz svn db Modul aufgesetzt. Der anschliessende Test
des Modul schlug jedoch fehl. Ein Debugging förderte zu Tage, dass im Source Code an zwei Orten
falsche Feldnamen verwendet wurden. Nach dem Anpassen und erneutem Kompilieren des Moduls
funktionierte die Autorisierung einwandfrei.
5.2.2. SSL Verbindung zum FHNW AD
Der Versuch, eine mit SSL bzw. TLS verschlüsselte Verbindung zu den Active Directory Servern der
FHNW aufzubauen, misslang aufgrund des am 04.07.2009 abgelaufenen SSL Zertifikats des EDU Domain Controllers (siehe Listing 5.3). Daher schlug die Validierung und somit die Verbindung fehl. Dies
äusserte sich durch einen Verbindungsabbruch seitens des Apache Servers, nach dem durchgeführten
SSL Handshake. Ein Test mit dem eigenen Active Directory Server gelang problemlos.
Bachelor Thesis
31
SVN Authentifizierung und Autorisierung
Kapitel 5. Probleme
5.2. Apache
Das in Listing 5.3 gezeigte Zertifikat wurde mit Wireshark aus einem abgefangenen SSL Handshake
zwischen dem Apache Server und dem EDU Domain Controller extrahiert.
Listing 5.3: SSL Zertifikat des EDU Domain Controllers der FHNW
Certificate :
Data :
V e r s i o n : 3 ( 0 x2 )
S e r i a l Number :
2 2 : 0 1 : a7 : 5 6 : 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 1 6
S i g n a t u r e Algorithm : sha1WithRSAEncryption
I s s u e r : DC=ch , DC=fhnw , DC=ds , CN=fhnw . ch
Validity
Not B e f o r e : J u l 5 0 8 : 4 3 : 2 7 2007 GMT
Not A f t e r : J u l 4 0 8 : 4 3 : 2 7 2009 GMT
S u b j e c t : CN=dsemu11 . edu . ds . fhnw . ch
S u b j e c t P u b l i c Key I n f o :
P u b l i c Key Algorithm : r s a E n c r y p t i o n
RSA P u b l i c Key : ( 1 0 2 4 b i t )
Modulus ( 1 0 2 4 b i t ) :
0 0 : ae : f 9 : d8 : 4 4 : 7 0 : 7 8 : 6 1 : 1 c : 3 6 : f 3 : 4 5 : b3 : c6 : d0 :
d8 : d3 : f c : 9 9 : 0 3 : 3 3 : a0 : 9 5 : 0 f : 9 b : c8 : 3 0 : 2 0 : b9 : f 5 :
7 9 : b9 : 2 4 : 3 0 : 9 0 : 1 6 : f a : d6 : 7 5 : aa : 8 8 : 4 d : de : 8 6 : 9 e :
b6 : 4 1 : 0 1 : 7 b : 8 c : 4 b : 7 b : 6 1 : f 4 : c0 : d0 : 1 b : e2 : 7 6 : 2 4 :
6 0 : cb : 3 2 : 8 8 : 7 c : 9 e : 8 8 : be : 4 a : d5 : dd : 3 5 : a1 : 8 5 : 4 5 :
1 c : 8 1 : 1 9 : 6 7 : 0 1 : 9 b : c4 : 9 9 : 7 a : 4 4 : dc : f 0 : 7 f : 5 c : 6 f :
9 4 : 2 e : e8 : 1 f : d3 : 9 0 : 3 a : 0 e : 2 b : 1 3 : e9 : a9 : 1 e : 8 f : 1 d :
eb : 7 d : 5 2 : d2 : 1 d : 3 b : 0 7 : 8 1 : c9 : 6 6 : 7 2 : 5 d : 0 2 : 5 a : 0 8 :
d8 : 0 3 : 6 e : 3 e : c3 : 4 a : c6 : 9 4 : 6 5
Exponent : 65537 ( 0 x10001 )
X509v3 e x t e n s i o n s :
X509v3 S u b j e c t Key I d e n t i f i e r :
5F : 3 E : 3 8 : 1D: 1B : 0 4 : 6D: C9 : 6B :AA: 7 8 : 0 2 :CD: 5 6 : 9 8 : 2 2 : 0 C :EC : 1 1 :
EA
X509v3 Extended Key Usage :
TLS Web S e r v e r A u t h e n t i c a t i o n
X509v3 Key Usage :
D i g i t a l S i g n a t u r e , Key Encipherment
X509v3 A u t h o r i t y Key I d e n t i f i e r :
k e y i d : B3 : 0 5 :DB: 5 3 : E6 : E3 : 1A: 0 0 : 1 8 : D3 : 6 6 : 4 9 : A6 : 3C : 4 5 :ED: 2 1 :
D8 :BC: E3
X509v3 CRL D i s t r i b u t i o n P o i n t s :
URI : l d a p : / / /CN=fhnw . ch ,CN=DSRMU11,CN=CDP,CN=P u b l i c %20Key
%20 S e r v i c e s ,CN=S e r v i c e s ,CN=C o n f i g u r a t i o n ,DC=ds ,DC=fhnw
,DC=ch ? c e r t i f i c a t e R e v o c a t i o n L i s t ? b a s e ? o b j e c t C l a s s=
cRLDistributionPoint
URI : h t t p : / / dsrmu11 . ds . fhnw . ch / C e r t E n r o l l / fhnw . ch . c r l
Authority Information Access :
CA I s s u e r s − URI : l d a p : / / /CN=fhnw . ch ,CN=AIA ,CN=P u b l i c %20
Bachelor Thesis
32
SVN Authentifizierung und Autorisierung
Kapitel 5. Probleme
5.2. Apache
Key%20 S e r v i c e s ,CN=S e r v i c e s ,CN=C o n f i g u r a t i o n ,DC=ds ,DC=
fhnw ,DC=ch ? c A C e r t i f i c a t e ? b a s e ? o b j e c t C l a s s=
certificationAuthority
CA I s s u e r s − URI : h t t p : / / dsrmu11 . ds . fhnw . ch / C e r t E n r o l l /
DSRMU11. ds . fhnw . ch fhnw . ch . c r t
1.3.6.1.4.1.311.20.2:
. . .W. e . b . S . e . r . v . e . r
S i g n a t u r e Algorithm : sha1WithRSAEncryption
2 9 : e e : ed : e0 : 6 0 : 4 c : 7 6 : 2 1 : 8 b : 0 5 : e f : 2 4 : 8 a : a1 : 0 3 : a7 : e9 : 0 e :
5 3 : d4 : d9 : 9 2 : cb : d5 : 8 c : 6 b : 7 f : c5 : 8 1 : 2 3 : 6 a : 1 8 : 7 d : 4 a : 5 3 : da :
e5 : a f : 9 1 : 2 c : 9 d : e c : c2 : 5 b : 5 a : 7 b : 3 1 : c7 : 0 6 : 7 0 : 0 e : 0 7 : f 7 : 0 d :
6 3 : 9 6 : 0 6 : d f : a f : 6 0 : d5 : 4 7 : f d : 6 e : c e : 0 9 : a1 : 3 2 : 5 f : 9 4 : 7 4 : 4 1 :
2 2 : 2 d : da : 9 5 : f e : b9 : 4 8 : e1 : 0 0 : f 1 : f 2 : b0 : f 8 : 4 7 : 6 6 : e c : 5 d : 7 1 :
c f : 0 2 : e3 : 3 0 : 4 7 : da : 7 0 : a3 : 8 5 : 4 a : db : 9 e : 6 4 : 7 9 : 6 9 : 2 8 : 4 4 : 8 b :
8d : 2 c : 3 e : 9 3 : ae : 2 a : f 2 : 6 8 : 5 5 : b5 : d4 : e e : 9 5 : f d : 6 1 : 0 9 : 8 1 : 8 9 :
f b : de : 2 1 : 6 d : 8 0 : 3 7 : 5 3 : 8 d : ab : 6 c : 8 3 : 1 d : d1 : 9 f : 7 9 : f 8 : 8 0 : 5 4 :
6 c : b7 : 9 6 : ae : 8 3 : 2 b : e c : 8 7 : 7 2 : 8 3 : 1 f : 5 7 : 6 6 : 6 5 : bb : 5 7 : 0 5 : 2 8 :
9a : b7 : 9 1 : 8 2 : be : 0 7 : 5 9 : e1 : 6 3 : f 7 : b4 : 8 a : 5 a : 7 0 : 7 c : 3 1 : 6 c : 0 7 :
0 e : 3 e : ac : 1 f : 8 2 : 6 2 : c1 : eb : d0 : 7 7 : 2 c : 4 d : e c : 1 0 : 9 8 : f 8 : 8 a : d4 :
2 9 : 4 a : 3 7 : b7 : d1 : 1 b : 7 d : d1 : c e : 1 2 : 4 0 : a4 : 6 6 : c4 : f 9 : 1 7 : 2 1 : 4 4 :
5 4 : 7 1 : f 4 : f 6 : 5 d : 9 a : d4 : a8 : c5 : f 4 : 4 1 : e7 : 3 d : 5 9 : f 9 : 8 c : c8 : 6 d :
f 3 : 8 c : 2 6 : ac : bc : dd : 9 8 : 8 2 : c0 : ca : 5 2 : 8 4 : 4 8 : da : 3 f : 9 b : f 6 : 5 0 :
3 e : a0 : 2 7 : c3
}
Bachelor Thesis
33
SVN Authentifizierung und Autorisierung
6. Tests
Dieses Kapitel zeigt die verwendete Testumgebung und die durchgeführten Tests.
6.1. Testumgebung
Für das Testen der Lösung wurde die in der Grafik 6.1 abgebildete Testumgebung verwendet. In der
Grafik sind die Domain Controller, der OpenLDAP Server und der MySQL Server als eigenständige
Server aufgeführt. Mangels physikalischer Computer wurden der OpenLDAP und der MySQL Server
auf dem gleichen Server wie der Apache installiert. Aufgrund des abgelaufenen SSL Zertifikats der Domain Controller konnte nicht direkt mit LDAPS gearbeitet werden. Da die SSL Tests mit dem eigenen
Domain Controller problemlos funktionierten, kann davon ausgegangen werden, dass die Verschlüsselung mit gültigen Zertifikaten auch mit den FHNW Servern, wie in der Grafik gezeigt, funktionieren
würde.
Die Grafik 6.1 stellt die Lösung aus der physikalischen Sicht dar, wohingegen die Grafik 4.1 die Lösung
aus der logischen Sicht darstellt.
EDU Server 1
EDU Server 2
LDAP(S)
LDAP(S)
3.1
ADM Server 1
ADM Server 2
LDAP(S)
3.2
SVN Client
2
HTTPS
LDAP(S)
Apache Server
3.3
LDAP(S)
4
Login Daten
OpenLDAP
Server
1
MySQL Server
Abbildung 6.1.: Verwendete Testumgebung
34
Kapitel 6. Tests
6.2. Allgemeines
6.2. Allgemeines
Test
Der ganze Datenverkehr Client-Apache und Apache-LDAP Verzeichnis kann mit
SSL/TLS verschlüsselt werden
Resultat
funktioniert
6.3. Authentifizierung
Test
Benutzer aus der EDU Domäne können sich anmelden
Benutzer aus der ADM Domäne können sich anmelden
Benutzer aus der OpenLDAP Domäne können sich anmelden
Benutzer aus der EDU/ADM Domäne mit Umlauten im Namen können sich anmelden
Verbindung zu den LDAP Servern kann optional verschlüsselt werden
Resultat
funktioniert
funktioniert
funktioniert
funktioniert
funktioniert
6.4. Autorisierung
Test
Benutzer können lesend auf Repositories zugreifen
Benutzer können schreibend auf Repositories zugreifen
Benutzern kann der Zugriff auf Unterordner im Repository verweigert werden
Bachelor Thesis
35
Resultat
funktioniert
funktioniert
funktioniert
SVN Authentifizierung und Autorisierung
7. Ausblick
7.1. SVN Verwaltungsapplikation
Dieses Kapitel beschreibt, was eine allfällige spätere Applikation zur Verwaltung der Repositories und
der Berechtigungsdatenbank können soll. Da das saubere Erstellen einer solchen GUI Applikation
voraussichtlich ein eigenes Semesterprojekt füllen würde, wurde im Rahmen dieser Arbeit auf die
Umsetzung verzichtet. Es wird in diesem Kapitel lediglich geschildert, was denkbar wäre.
7.1.1. Use Case Diagramm
In Grafik 7.1 werden die Use Cases der Applikation dargestellt. Im Wesentlich soll man mit einer
allfälligen späteren Applikation die Repositories, Benutzer und Gruppen verwalten können. Optimal
wäre im Wesentlichen folgendes:
• Erstellen von Repositories auf dem Server.
• Importieren von Benutzern aus dem Active Directory und dem OpenLDAP Server in die Datenbank.
• Benutzern und Gruppen Berechtigungen auf den Repositories erteilen.
• Gelöschte LDAP Benutzer aus der Datenbank entfernen.
36
Kapitel 7. Ausblick
7.1. SVN Verwaltungsapplikation
Repository- und Berechtigungsverwaltung
Zugansdate
n eingeben
<include>
Grundkonfiguration
vornehmen
Repo Server
eingeben
<include>
<include>
LDAP
Server
eingeben
<include>
Repo
erstellen
<include>
MySQL
Server
eingeben
<extend>
Repository
verwalten
Repo
löschen
<extend>
Gr erstellen
Repository
Administrator
<extend>
<include>
Gr verwalten
Gr löschen
<extend>
Benutzer und
Gruppen
verwalten
LDAP
Benutzer
einer Gr
zuweisen
<extend>
Benutzer
verwalten
Gr an Repo
zuweisen
<extend>
<extend>
<extend>
Benutzer - Gr
Zuweisung
ändern
<extend>
Benutzer an
Repo
zuweisen
<extend>
Benutzer
löschen
Gelöschte
LDAP Benutzer
entfernen
Abbildung 7.1.: Use Case Diagramm der Applikation
Bachelor Thesis
37
SVN Authentifizierung und Autorisierung
Kapitel 7. Ausblick
7.1. SVN Verwaltungsapplikation
7.1.2. GUI Entwurf
Die in diesem Kapitel dargestellten Entwürfe der Fenster wurden in Visual Studio 2008 und C#
erstellt. Sie dienen dazu, die wichtigsten, im Diagramm 7.1 zu sehenden, Use Cases zu visualisieren.
Die Grafik 7.2 zeigt das Hauptfenster der Applikation. Es ermöglicht das Setzen von Zugriffsberechtigungen für ein bestimmtes Repository.
Abbildung 7.2.: Repositoryverwaltung
Bachelor Thesis
38
SVN Authentifizierung und Autorisierung
Das Bild 7.3 stellt das Auswählen der Benutzer für ein bestimmtes Repository dar. Hier können nach
der Wahl des LDAP Servers und nach Eingabe der Suchkriterien die gewünschten Benutzer angewählt
und einem Repository zugewiesen werden.
Abbildung 7.3.: Benutzerverwaltung
A. Anhang: Scripts und Konfigurationen
A.1. SQL: Erstellung der Datenbank
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
/∗
This SQL f i l e c o n t a i n s t h e SQL commands t o c r e a t e t h e d a t a b a s e f o r t h e apache
module a u t h z s v n d b
∗/
DROP DATABASE ‘ svnperm ‘ ;
CREATE DATABASE ‘ svnperm ‘ DEFAULT CHARACTER SET u t f 8 COLLATE u t f 8 u n i c o d e c i ;
USE ‘ svnperm ‘ ;
CREATE TABLE ‘ a u t h z s v n r e p o s i t o r y ‘
(
‘ id ‘ INT( 1 1 ) NOT NULL AUTO INCREMENT,
‘ name ‘ VARCHAR( 2 5 5 ) NOT NULL UNIQUE,
PRIMARY KEY ( ‘ id ‘ ) ,
INDEX r e p o n a m e i d x ( ‘ name ‘ )
) ENGINE=InnoDB ;
CREATE TABLE ‘ a u t h z s v n u s e r ‘
(
‘ id ‘ INT( 1 1 ) NOT NULL AUTO INCREMENT,
‘ name ‘ VARCHAR( 2 5 5 ) NOT NULL UNIQUE,
PRIMARY KEY ( ‘ id ‘ ) ,
INDEX u s e r n a m e i d x ( ‘ name ‘ )
) ENGINE=InnoDB ;
CREATE TABLE ‘ a u t h z s v n r e p o p a t h ‘
(
‘ id ‘ INT( 1 1 ) NOT NULL AUTO INCREMENT,
‘ r e p o s i t o r y i d ‘ INT( 1 1 ) NOT NULL,
‘ path ‘ VARCHAR( 2 5 5 ) NOT NULL,
PRIMARY KEY ( ‘ id ‘ ) ,
UNIQUE ( ‘ r e p o s i t o r y i d ‘ , ‘ path ‘ ) ,
FOREIGN KEY r e p o s i t o r y i d i d x f k ( ‘ r e p o s i t o r y i d ‘ ) REFERENCES ‘
a u t h z s v n r e p o s i t o r y ‘ ( ‘ id ‘ ) ON DELETE CASCADE
36 ) ENGINE=InnoDB ;
37
38
39 CREATE TABLE ‘ a u t h z s v n u s e r p e r m i s s i o n ‘
40 (
41 ‘ u s e r i d ‘ INT( 1 1 ) NOT NULL,
42 ‘ r e p o s i t o r y p a t h i d ‘ INT( 1 1 ) NOT NULL,
43 ‘ read ‘ TINYINT ( 1 ) NOT NULL,
44 ‘ write ‘ TINYINT ( 1 ) NOT NULL,
45 ‘ recursive ‘ TINYINT ( 1 ) NOT NULL,
46 PRIMARY KEY ( ‘ u s e r i d ‘ , ‘ r e p o s i t o r y p a t h i d ‘ ) ,
47 FOREIGN KEY u s e r i d i d x f k ( ‘ u s e r i d ‘ ) REFERENCES ‘ a u t h z s v n u s e r ‘ ( ‘ id ‘ ) ON DELETE
CASCADE,
48 FOREIGN KEY r e p o p a t h i d i d x f k ( ‘ r e p o s i t o r y p a t h i d ‘ ) REFERENCES ‘
49
50
a u t h z s v n r e p o p a t h ‘ ( ‘ id ‘ ) ON DELETE CASCADE
) ENGINE=InnoDB ;
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
CREATE TABLE ‘ a u t h z s v n g r o u p ‘
(
‘ id ‘ INT( 1 1 ) NOT NULL AUTO INCREMENT,
‘ name ‘ VARCHAR( 2 5 5 ) NOT NULL UNIQUE,
PRIMARY KEY ( ‘ id ‘ ) ,
INDEX group name idx ( ‘ name ‘ )
) ENGINE=InnoDB ;
CREATE TABLE ‘ authz svn groupmembership ‘
(
‘ id ‘ INT( 1 1 ) NOT NULL AUTO INCREMENT,
‘ u s e r i d ‘ INT( 1 1 ) NOT NULL,
‘ g r o u p i d ‘ INT( 1 1 ) NOT NULL,
PRIMARY KEY ( ‘ id ‘ ) ,
UNIQUE ( ‘ u s e r i d ‘ , ‘ g r o u p i d ‘ ) ,
FOREIGN KEY u s e r i d i d x f k ( ‘ u s e r i d ‘ ) REFERENCES ‘ a u t h z s v n u s e r ‘ ( ‘ id ‘ ) ON DELETE
CASCADE,
69 FOREIGN KEY g r o u p i d i d x f k ( ‘ g r o u p i d ‘ ) REFERENCES ‘ a u t h z s v n g r o u p ‘ ( ‘ id ‘ ) ON
DELETE CASCADE
70 ) ENGINE=InnoDB ;
71
72
73
74
75
76
77
78
79
80
81
82
83
84
CREATE TABLE ‘ a u t h z s v n g r o u p p e r m i s s i o n ‘
(
‘ id ‘ INT( 1 1 ) NOT NULL AUTO INCREMENT,
‘ g r o u p i d ‘ INT( 1 1 ) NOT NULL,
‘ r e p o s i t o r y p a t h i d ‘ INT( 1 1 ) NOT NULL,
‘ read ‘ TINYINT ( 1 ) NOT NULL,
‘ write ‘ TINYINT ( 1 ) NOT NULL,
‘ recursive ‘ TINYINT ( 1 ) NOT NULL,
PRIMARY KEY ( ‘ id ‘ ) ,
UNIQUE ( ‘ g r o u p i d ‘ , ‘ r e p o s i t o r y p a t h i d ‘ ) ,
FOREIGN KEY r e p o p a t h i d i d x f k ( ‘ r e p o s i t o r y p a t h i d ‘ ) REFERENCES ‘
a u t h z s v n r e p o p a t h ‘ ( ‘ id ‘ ) ON DELETE CASCADE,
85 FOREIGN KEY g r o u p i d i d x f k ( ‘ g r o u p i d ‘ ) REFERENCES ‘ a u t h z s v n g r o u p ‘ ( ‘ id ‘ ) ON
DELETE CASCADE
86 ) ENGINE=InnoDB ;
A.2. SQL: Beispieldaten
1
2
3
4
5
6
7
8
9
10
11
12
−−
−− Database : ‘ svnperm ‘
−−
−−
−− Dumping d a t a f o r t a b l e ‘ a u t h z s v n g r o u p ‘
−−
INSERT INTO ‘ a u t h z s v n g r o u p ‘ ( ‘ id ‘ , ‘ name ‘ ) VALUES
(1 , ’ allrepos ’ ) ,
(5 , ’ d n f c a l l ’ ) ,
(6 , ’ dnfc gruppe1 ’ ) ,
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
(7 ,
(8 ,
(2 ,
(4 ,
(9 ,
(10 ,
(11 ,
(3 ,
(12 ,
(13 ,
(14 ,
’ dnfc gruppe2 ’ ) ,
’ dnfc gruppe3 ’ ) ,
’ projectSVN ’ ) ,
’ swko all ’ ) ,
’ swko gruppe1 ’ ) ,
’ swko gruppe2 ’ ) ,
’ swko gruppe3 ’ ) ,
’ vesys all ’) ,
’ vesys gruppe1 ’ ) ,
’ vesys gruppe2 ’ ) ,
’ vesys gruppe3 ’ ) ;
−−
−− Dumping d a t a f o r t a b l e ‘ a u t h z s v n g r o u p m e m b e r s h i p ‘
−−
INSERT INTO ‘ authz svn groupmembership ‘ ( ‘ id ‘ , ‘ u s e r i d ‘ , ‘ g r o u p i d ‘ ) VALUES
(15 , 1 , 2) ,
(5 , 2 , 2) ,
(12 , 3 , 9) ,
(13 , 3 , 10) ,
(14 , 3 , 14) ,
(6 , 4 , 7) ,
(7 , 4 , 12) ,
(8 , 5 , 4) ,
(18 , 6 , 5) ,
(11 , 7 , 3) ,
(17 , 8 , 9) ,
(16 , 8 , 10) ,
(9 , 9 , 8) ,
(10 , 9 , 11) ,
(20 , 10 , 8) ,
(19 , 10 , 11) ,
(24 , 11 , 6) ,
(23 , 11 , 13) ,
(1 , 12 , 1) ,
(2 , 13 , 6) ,
(4 , 13 , 13) ,
(3 , 13 , 14) ,
(22 , 14 , 7) ,
(21 , 14 , 12) ;
−−
−− Dumping d a t a f o r t a b l e ‘ a u t h z s v n g r o u p p e r m i s s i o n ‘
−−
INSERT INTO
‘ read ‘ ,
(1 , 1 , 1 , 1 ,
(2 , 1 , 2 , 1 ,
(3 , 1 , 3 , 1 ,
(4 , 1 , 4 , 1 ,
(5 , 1 , 5 , 1 ,
(6 , 1 , 6 , 1 ,
(7 , 1 , 7 , 1 ,
(8 , 1 , 8 , 1 ,
‘ a u t h z s v n g r o u p p e r m i s s i o n ‘ ( ‘ id ‘ , ‘ g r o u p i d ‘ , ‘ r e p o s i t o r y p a t h i d ‘ ,
‘ write ‘ , ‘ recursive ‘ ) VALUES
1 , 1) ,
1 , 1) ,
1 , 1) ,
1 , 1) ,
1 , 1) ,
1 , 1) ,
1 , 1) ,
1 , 1) ,
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
(9 , 1 , 9 , 1 , 1 , 1) ,
(10 , 1 , 10 , 1 , 1 , 1) ,
(11 , 5 , 2 , 1 , 0 , 1) ,
(12 , 5 , 5 , 1 , 0 , 1) ,
(13 , 5 , 6 , 1 , 0 , 1) ,
(14 , 2 , 1 , 1 , 1 , 1) ,
(15 , 4 , 4 , 1 , 0 , 1) ,
(16 , 4 , 9 , 1 , 0 , 1) ,
(17 , 4 , 10 , 1 , 0 , 1) ,
(18 , 3 , 3 , 1 , 0 , 1) ,
(19 , 3 , 7 , 1 , 0 , 1) ,
(20 , 3 , 8 , 1 , 0 , 1) ,
(21 , 6 , 2 , 1 , 1 , 1) ,
(22 , 7 , 5 , 1 , 1 , 1) ,
(23 , 8 , 6 , 1 , 1 , 1) ,
(24 , 10 , 9 , 1 , 1 , 1) ,
(25 , 11 , 10 , 1 , 1 , 1) ,
(26 , 12 , 3 , 1 , 1 , 1) ,
(27 , 13 , 7 , 1 , 1 , 1) ,
(28 , 14 , 8 , 1 , 1 , 1) ,
(29 , 9 , 4 , 1 , 1 , 1) ;
−−
−− Dumping d a t a f o r t a b l e ‘ a u t h z s v n r e p o p a t h ‘
−−
INSERT INTO ‘ a u t h z s v n r e p o p a t h ‘ ( ‘ id ‘ , ‘ r e p o s i t o r y i d ‘ , ‘ path ‘ ) VALUES
(1 , 1 , ’/ ’ ) ,
(2 , 2 , ’/ ’ ) ,
(3 , 3 , ’/ ’ ) ,
(4 , 4 , ’/ ’ ) ,
(5 , 5 , ’/ ’ ) ,
(6 , 6 , ’/ ’ ) ,
(7 , 7 , ’/ ’ ) ,
(8 , 8 , ’/ ’ ) ,
(9 , 9 , ’/ ’ ) ,
(10 , 10 , ’ / ’ ) ;
−−
−− Dumping d a t a f o r t a b l e ‘ a u t h z s v n r e p o s i t o r y ‘
−−
INSERT INTO ‘ a u t h z s v n r e p o s i t o r y ‘ ( ‘ id ‘ , ‘ name ‘ ) VALUES
(2 , ’ dnfc gruppe1 ’ ) ,
(5 , ’ dnfc gruppe2 ’ ) ,
(6 , ’ dnfc gruppe3 ’ ) ,
( 1 , ’ projectSVN ’ ) ,
( 4 , ’ swko gruppe1 ’ ) ,
( 9 , ’ swko gruppe2 ’ ) ,
( 1 0 , ’ swko gruppe3 ’ ) ,
(3 , ’ vesys gruppe1 ’ ) ,
(7 , ’ vesys gruppe2 ’ ) ,
(8 , ’ vesys gruppe3 ’ ) ;
−−
−− Dumping d a t a f o r t a b l e ‘ a u t h z s v n u s e r ‘
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
−−
INSERT INTO ‘ a u t h z s v n u s e r ‘ ( ‘ id ‘ , ‘ name ‘ ) VALUES
( 1 2 , ’ admin ’ ) ,
( 1 3 , ’ a n d r e a s . a n t e n e r @ s t u d e n t s . fhnw . ch ’ ) ,
(2 , ’ christian ’ ) ,
( 4 , ’ c h r i s t i a n . h a l l e r @ s t u d e n t s . fhnw . ch ’ ) ,
( 5 , ’ c h r i s t o p h . denzler@fhnw . ch ’ ) ,
( 9 , ’ c l a u d i o . s c h n e i d e r @ s t u d e n t s . fhnw . ch ’ ) ,
( 7 , ’ dominik . gruntz@fhnw . ch ’ ) ,
( 3 , ’ g e r a r d . b i e l i @ s t u d e n t s . fhnw . ch ’ ) ,
(1 , ’ gery ’ ) ,
( 8 , ’ l a u r i n . m u e l l e r @ s t u d e n t s . fhnw . ch ’ ) ,
( 6 , ’ martin . kropp@fhnw . ch ’ ) ,
( 1 0 , ’ maxim . moschko@students . fhnw . ch ’ ) ,
( 1 4 , ’ m i c h a e l . f r a n k @ s t u d e n t s . fhnw . ch ’ ) ,
( 1 1 , ’ thomas . hartmann@students . fhnw . ch ’ ) ;
−−
−− Dumping d a t a f o r t a b l e ‘ a u t h z s v n u s e r p e r m i s s i o n ‘
−−
A.3. SQL: Datenbankabfrage
SELECT
a u t h z s v n r e p o p a t h . path AS r e p o s i t o r y p a t h , a u t h z s v n u s e r p e r m i s s i o n . read ,
a u t h z s v n u s e r p e r m i s s i o n . write ,
a u t h z s v n u s e r p e r m i s s i o n . recursive
FROM
a u t h z s v n r e p o s i t o r y INNER JOIN
a u t h z s v n r e p o p a t h ON
a u t h z s v n r e p o p a t h . r e p o s i t o r y i d = a u t h z s v n r e p o s i t o r y . i d AND
a u t h z s v n r e p o s i t o r y . name = ’ projectSVN ’ INNER JOIN
a u t h z s v n u s e r p e r m i s s i o n ON
a u t h z s v n u s e r p e r m i s s i o n . r e p o s i t o r y p a t h i d = a u t h z s v n r e p o p a t h . i d INNER JOIN
a u t h z s v n u s e r ON
a u t h z s v n u s e r . i d = a u t h z s v n u s e r p e r m i s s i o n . u s e r i d AND
a u t h z s v n u s e r . name = ’ g e r y ’
UNION SELECT
a u t h z s v n r e p o p a t h . path AS r e p o s i t o r y p a t h ,
a u t h z s v n g r o u p p e r m i s s i o n . read ,
a u t h z s v n g r o u p p e r m i s s i o n . write ,
a u t h z s v n g r o u p p e r m i s s i o n . recursive
FROM
a u t h z s v n r e p o s i t o r y INNER JOIN
a u t h z s v n r e p o p a t h ON
a u t h z s v n r e p o p a t h . r e p o s i t o r y i d = a u t h z s v n r e p o s i t o r y . i d AND
a u t h z s v n r e p o s i t o r y . name = ’ projectSVN ’ INNER JOIN
a u t h z s v n g r o u p p e r m i s s i o n ON
a u t h z s v n g r o u p p e r m i s s i o n . r e p o s i t o r y p a t h i d = a u t h z s v n r e p o p a t h . i d INNER JOIN
authz svn groupmembership ON
authz svn groupmembership . g r o u p i d = a u t h z s v n g r o u p p e r m i s s i o n . g r o u p i d INNER
JOIN
29 a u t h z s v n u s e r ON
30 a u t h z s v n u s e r . i d = authz svn groupmembership . u s e r i d AND
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
31
a u t h z s v n u s e r . name = ’ g e r y ’ ORDER BY r e p o s i t o r y p a t h DESC
A.4. Bash: Buildscript Apache Modul
1 #! / b i n / b a s h
2
3 / e t c / i n i t . d/ apache2 s t o p
4 cd mysql
5
6 #a p x s i s t h e apache b u i l d h e l p e r which i s used t o b u i l d modules . GCC d o e s not
work ! ! ! ! !
7
8 #c o m p i l e t h e module
9 apxs2 −c −I / u s r / i n c l u d e / s u b v e r s i o n −1 −I
..
−L / u s r / l i b / − l m y s q l c l i e n t
mod authz svn db mysql . c
10
11 #i n s t a l l t h e module
12 apxs2 − i e −n a u t h z s v n d b m y s q l m o d u l e mod authz svn db mysql . l a
13
14 / e t c / i n i t . d/ apache2 s t a r t
15 cd . .
A.5. Konfigurationsdatei: Apache
1
2
3
4
5
6
7
8
9
10
11
12
#−−−−−−−−−−−−−−−−−−−−−−−−−−
#Begin f i n a l i m p l e m e n t a t i o n
#−−−−−−−−−−−−−−−−−−−−−−−−−−
<A u t h n P r o v i d e r A l i a s l d a p openldap>
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
#A u t h e n t i c a t i o n d a t a f o r t h e OpenLDAP s e r v e r
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
AuthLDAPBindDN ”CN=admin , dc=imvs , dc=t e c h n i k , dc=fhnw , dc=ch ”
AuthLDAPBindPassword pw
AuthLDAPURL l d a p : / / l o c a l h o s t : 3 8 9 /DC=imvs ,DC=t e c h n i k ,DC=fhnw ,DC=ch ? cn ? sub
? ( o b j e c t C l a s s=p e r s o n ) NONE
13 </A u t h n P r o v i d e r A l i a s >
14
15 <A u t h n P r o v i d e r A l i a s l d a p ad−stud>
16
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
17
#A u t h e n t i c a t i o n d a t a f o r t h e edu domain
18
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
19
20
#For AD, a b i n d DN and password i s n e c e s s a r y b e c a u s e anonymous b i n d i n g
21
22
23
24
25
26
27
isn ’ t allowed f o r searching
AuthLDAPBindDN user@edu . ds . fhnw . ch
AuthLDAPBindPassword pw
#c h e c k t h e two redunda nt domain c o n t r o l l e r s
#3268 i s t h e g l o b a l c a t a l o g s e r v e r p o r t . This one i s needed t o r e l i a b l e
s e a r c h t h e domain . I f p o r t 389 i s used , t h e d i r e c t o r y can ’ t be
#s e a r c h e d r e l i a b l e
AuthLDAPURL ”l d a p : / / dsemu11 . edu . ds . fhnw . ch : 3 2 6 8 dsemu12 . edu . ds . fhnw . ch
: 3 8 9 / ou=edu , ou=prod ,DC=edu ,DC=ds ,DC=fhnw ,DC=ch ? m a i l ? sub ? ( o b j e c t C l a s s=
p e r s o n ) ” NONE
28 </A u t h n P r o v i d e r A l i a s >
29
30 <A u t h n P r o v i d e r A l i a s l d a p ad−adm>
31
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
32
#A u t h e n t i c a t i o n d a t a f o r t h e adm domain
33
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
34
35
#For AD, a b i n d DN and password i s n e c e s s a r y b e c a u s e anonymous b i n d i n g
36
37
38
39
40
isn ’ t allowed f o r searching
AuthLDAPBindDN user@edu . ds . fhnw . ch
AuthLDAPBindPassword pw
#remark : p o r t 3268 i s n ’ t r e a c h a b l e on t h e adm domain s e r v e r
AuthLDAPURL ”l d a p : / / dsamu11 . i c t . fhnw . ch : 3 8 9 dsamu12 . i c t . fhnw . ch : 3 8 9 /OU=
adm ,OU=Prod ,DC=adm ,DC=ds ,DC=fhnw ,DC=ch ? m a i l ? sub ? ( o b j e c t C l a s s=p e r s o n ) ”
NONE
41 </A u t h n P r o v i d e r A l i a s >
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
<L o c a t i o n / r e p o s >
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
#This l o c a t i o n r e p r e s e n t s t h e f i n a l i m p l e m e n t a t i o n .
#I t p e r m i t s a u t h e n t i c a t i o n a g a i n s t t h e openLDAP S e r v e r
#and t h e two AD domains edu and adm
#∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
#SVN s e c t i o n :
DAV svn
SVNParentPath / data / t e s t R e p o s
#A u t h e n t i c a t i o n s e c t i o n
A u t h B a s i c P r o v i d e r openldap ad−s t u d ad−adm
AuthType B a s i c
AuthName ”SVN Anmeldung ”
r e q u i r e v a l i d −u s e r
#A u t o r i z a t i o n
AuthzSVNDBHost ” l o c a l h o s t ”
AuthzSVNDBName ”svnperm ”
AuthzSVNDBUsername ”svn mod ”
AuthzSVNDBPassword ”pw”
</L o c a t i o n >
#−−−−−−−−−−−−−−−−−−−−−−−−
#End f i n a l i m p l e m e n t a t i o n
#−−−−−−−−−−−−−−−−−−−−−−−−
B. Anhang: Pflichtenheft
Literaturverzeichnis
[1] Virtual Home Organization: http://www.switch.ch/aai/join/vho.html, 30.03.2009
[2] Penrose Server 1.2.4: http://docs.safehaus.org/.../PENROSE12/Penrose+1.2+Release, 14.05.2009
[3] mod authz svn db: http://christopher.wojno.com/.../what-is-mod authz svn db, 31.07.2009
[4] Penrose Demo: http://docs.safehaus.org/display/PENROSE10/Demo, 14.05.2009
[5] mod authn alias: http://httpd.apache.org/docs/2.2/mod/mod authn alias.html, 02.08.2009
[6] SVN Book: http://svnbook.red-bean.com/nightly/de/svn-book.html, 31.07.2009
[7] mod ssl: http://httpd.apache.org/docs/2.2/mod/mod ssl.html, 03.08.2009
[8] mod auth basic: http://httpd.apache.org/docs/2.2/mod/mod auth basic.html, 03.08.2009
[9] mod ldap: http://httpd.apache.org/docs/2.2/mod/mod ldap.html, 03.08.2009
[10] mod authnz ldap: http://httpd.apache.org/docs/2.2/mod/mod authnz ldap.html, 03.08.2009
[11] mod dav: http://httpd.apache.org/docs/2.2/mod/mod dav.html, 03.08.2009
[12] Subversion: http://subversion.tigris.org/getting.html, 03.08.2009
[13] Nick Kew: The Apache Modules Book; Prentice Hall, Jan 2007
51