Revision 51d8e086
Von Moritz Bunkus vor 3 Monaten hinzugefügt
doc/html/ch02s10.html | ||
---|---|---|
eigentlichen Finanzdaten hinterlegt sein. Diese beiden Datenbanken
|
||
können, müssen aber nicht unterschiedlich sein.</p><p>Im einfachsten Fall gibt es für kivitendo nur eine einzige
|
||
Datenbank, in der sowohl die Benutzerinformationen als auch die Daten
|
||
abgelegt werden.</p><p>Zusätzlich ermöglicht es kivitendo, dass die Benutzerpasswörter gegen die Authentifizierungsdatenbank oder gegen einen oder
|
||
mehrere LDAP-Server überprüft werden.</p><p>Welche Art der Passwortüberprüfung kivitendo benutzt und wie
|
||
abgelegt werden.</p><p>Zusätzlich ermöglicht es kivitendo, dass die Benutzerpasswörter gegen verschiedene Authentifizierungsmethoden geprüft
|
||
werden. Dazu zählen die Authentifizierungsdatenbank, LDAP-Server sowie verschiedene Arten von HTTP-Header-basierten Methoden.</p><p>Welche Art der Passwortüberprüfung kivitendo benutzt und wie
|
||
kivitendo die Authentifizierungsdatenbank erreichen kann, wird in der
|
||
Konfigurationsdatei <code class="filename">config/kivitendo.conf</code>
|
||
festgelegt. Diese muss bei der Installation und bei einem Upgrade von
|
||
... | ... | |
"<code class="literal">postgres</code>")</p></dd><dt><span class="term">
|
||
<code class="literal">password</code>
|
||
</span></dt><dd><p>Das Passwort für den Datenbankbenutzer</p></dd></dl></div><p>Die Datenbank muss noch nicht existieren. kivitendo kann sie
|
||
automatisch anlegen (mehr dazu siehe unten).</p></div><div class="sect2" title="2.10.4. Passwortüberprüfung"><div class="titlepage"><div><div><h3 class="title"><a name="Passwort%C3%BCberpr%C3%BCfung"></a>2.10.4. Passwortüberprüfung</h3></div></div></div><p>kivitendo unterstützt Passwortüberprüfung auf zwei Arten: gegen
|
||
die Authentifizierungsdatenbank und gegen externe LDAP- oder
|
||
Active-Directory-Server. Welche davon benutzt wird, regelt der
|
||
Parameter <code class="varname">module</code> im Abschnitt
|
||
<code class="varname">[authentication]</code>.</p><p>Dieser Parameter listet die zu verwendenden Authentifizierungsmodule auf. Es muss mindestens ein Modul angegeben werden, es
|
||
automatisch anlegen (mehr dazu siehe unten).</p></div><div class="sect2" title="2.10.4. Passwortüberprüfung"><div class="titlepage"><div><div><h3 class="title"><a name="Passwort%C3%BCberpr%C3%BCfung"></a>2.10.4. Passwortüberprüfung</h3></div></div></div><p>kivitendo unterstützt verschiedene Module für die Passwortüberprüfung. Welche benutzt wird, regelt der Parameter
|
||
<code class="varname">module</code> im Abschnitt <code class="varname">[authentication]</code>.</p><p>Dieser Parameter listet die zu verwendenden Authentifizierungsmodule auf. Es muss mindestens ein Modul angegeben werden, es
|
||
können aber auch mehrere angegeben werden. Weiterhin ist es möglich, das LDAP-Modul mehrfach zu verwenden und für jede Verwendung
|
||
eine unterschiedliche Konfiguration zu nutzen, z.B. um einen Fallback-Server anzugeben, der benutzt wird, sofern der Hauptserver
|
||
nicht erreichbar ist.</p><p>Sollen die Benutzerpasswörter in der Authentifizierungsdatenbank geprüft werden, so muss der Parameter
|
||
<code class="varname">module</code> das Modul <code class="literal">DB</code> enthalten. Sofern das Modul in der Liste enthalten ist, egal an welcher
|
||
Position, können sowohl der Administrator als auch die Benutzer selber ihre Passwörter in kivitendo ändern.</p><p>Wenn Passwörter gegen einen oder mehrere externe LDAP- oder Active-Directory-Server geprüft werden, so muss der Parameter
|
||
<code class="varname">module</code> den Wert <code class="literal">LDAP</code> enthalten. In diesem Fall müssen zusätzliche Informationen über den
|
||
LDAP-Server im Abschnitt <code class="literal">[authentication/ldap]</code> angegeben werden. Das Modul kann auch mehrfach angegeben werden,
|
||
wobei jedes Modul eine eigene Konfiguration bekommen sollte. Der Name der Konfiguration wird dabei mit einem Doppelpunkt getrennt an
|
||
den Modulnamen angehängt (<code class="literal">LDAP:Name-der-Konfiguration</code>). Der entsprechende Abschnitt in der Konfigurationsdatei
|
||
lautet dann <code class="literal">[authentication/Name-der-Konfiguration]</code>.</p><p>Die verfügbaren Parameter für die LDAP-Konfiguration lauten:</p><div class="variablelist"><dl><dt><span class="term">
|
||
<code class="literal">host</code>
|
||
</span></dt><dd><p>Der Rechnername oder die IP-Adresse des LDAP- oder
|
||
Active-Directory-Servers. Diese Angabe ist zwingend
|
||
erforderlich.</p></dd><dt><span class="term">
|
||
<code class="literal">port</code>
|
||
</span></dt><dd><p>Die Portnummer des LDAP-Servers; meist 389.</p></dd><dt><span class="term">
|
||
<code class="literal">tls</code>
|
||
</span></dt><dd><p>Wenn Verbindungsverschlüsselung gewünscht ist, so diesen
|
||
Wert auf ‘<code class="literal">1</code>’ setzen, andernfalls auf
|
||
‘<code class="literal">0</code>’ belassen</p></dd><dt><span class="term">
|
||
<code class="literal">verify</code>
|
||
</span></dt><dd><p>Wenn Verbindungsverschlüsselung gewünscht und der Parameter <em class="parameter"><code>tls</code></em> gesetzt ist, so gibt dieser
|
||
Parameter an, ob das Serverzertifikat auf Gültigkeit geprüft wird. Mögliche Werte sind <code class="literal">require</code> (Zertifikat
|
||
wird überprüft und muss gültig sei; dies ist der Standard) und <code class="literal">none</code> (Zertifikat wird nicht
|
||
überpfüft).</p></dd><dt><span class="term">
|
||
<code class="literal">attribute</code>
|
||
</span></dt><dd><p>Das LDAP-Attribut, in dem der Benutzername steht, den der
|
||
Benutzer eingegeben hat. Für Active-Directory-Server ist dies
|
||
meist ‘<code class="literal">sAMAccountName</code>’, für andere
|
||
LDAP-Server hingegen ‘<code class="literal">uid</code>’. Diese Angabe ist
|
||
zwingend erforderlich.</p></dd><dt><span class="term">
|
||
<code class="literal">base_dn</code>
|
||
</span></dt><dd><p>Der Abschnitt des LDAP-Baumes, der durchsucht werden soll.
|
||
Diese Angabe ist zwingend erforderlich.</p></dd><dt><span class="term">
|
||
<code class="literal">filter</code>
|
||
</span></dt><dd><p>Ein optionaler LDAP-Filter. Enthält dieser Filter das Wort
|
||
<code class="literal"><%login%></code>, so wird dieses durch den vom
|
||
Benutzer eingegebenen Benutzernamen ersetzt. Andernfalls wird
|
||
der LDAP-Baum nach einem Element durchsucht, bei dem das oben
|
||
angegebene Attribut mit dem Benutzernamen identisch ist.</p></dd><dt><span class="term">
|
||
<code class="literal">bind_dn</code> und
|
||
<code class="literal">bind_password</code>
|
||
</span></dt><dd><p>Wenn der LDAP-Server eine Anmeldung erfordert, bevor er
|
||
durchsucht werden kann (z.B. ist dies bei
|
||
Active-Directory-Servern der Fall), so kann diese hier angegeben
|
||
werden. Für Active-Directory-Server kann als
|
||
‘<code class="literal">bind_dn</code>’ entweder eine komplette LDAP-DN wie
|
||
z.B. ‘<code class="literal">cn=Martin
|
||
Mustermann,cn=Users,dc=firmendomain</code>’ auch nur der
|
||
volle Name des Benutzers eingegeben werden; in diesem Beispiel
|
||
also ‘<code class="literal">Martin Mustermann</code>’.</p></dd><dt><span class="term">
|
||
<code class="literal">timeout</code>
|
||
</span></dt><dd><p>Timeout beim Verbindungsversuch, bevor der Server als nicht erreichbar gilt; Standardwert: 10</p></dd></dl></div></div><div class="sect2" title="2.10.5. Name des Session-Cookies"><div class="titlepage"><div><div><h3 class="title"><a name="Name-des-Session-Cookies"></a>2.10.5. Name des Session-Cookies</h3></div></div></div><p>Sollen auf einem Server mehrere kivitendo-Installationen
|
||
nicht erreichbar ist.</p><p>Verfügbare Module sind:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
|
||
<code class="literal">DB</code>: in Authentifizierungsdatenbank integrierte Benutzerverwaltung</p></li><li class="listitem"><p>
|
||
<code class="literal">ldap</code>: Bind mit User-Objekten gegen einen oder mehrere LDAP-Server</p></li><li class="listitem"><p>
|
||
<code class="literal">http_headers</code>: überlässt Authenfizierung vorgelagerten Proxy-Servern übernimmt Usernamen
|
||
aus mitgeschickten HTTP-Headern</p></li></ul></div><div class="sect3" title="2.10.4.1. Authentifizierungsdatenbank"><div class="titlepage"><div><div><h4 class="title"><a name="Passwort%C3%BCberpr%C3%BCfung_DB"></a>2.10.4.1. Authentifizierungsdatenbank</h4></div></div></div><p>Sollen die Benutzerpasswörter in der Authentifizierungsdatenbank geprüft werden, so muss der Parameter
|
||
<code class="varname">module</code> das Modul <code class="literal">DB</code> enthalten. Sofern das Modul in der Liste enthalten ist, egal an welcher
|
||
Position, können sowohl der Administrator als auch die Benutzer selber ihre Passwörter in kivitendo ändern.</p></div><div class="sect3" title="2.10.4.2. LDAP-Server"><div class="titlepage"><div><div><h4 class="title"><a name="Passwort%C3%BCberpr%C3%BCfung_LDAP"></a>2.10.4.2. LDAP-Server</h4></div></div></div><p>Wenn Passwörter gegen einen oder mehrere externe LDAP- oder Active-Directory-Server geprüft werden, so muss der Parameter
|
||
<code class="varname">module</code> den Wert <code class="literal">LDAP</code> enthalten. In diesem Fall müssen zusätzliche Informationen über den
|
||
LDAP-Server im Abschnitt <code class="literal">[authentication/ldap]</code> angegeben werden. Das Modul kann auch mehrfach angegeben werden,
|
||
wobei jedes Modul eine eigene Konfiguration bekommen sollte. Der Name der Konfiguration wird dabei mit einem Doppelpunkt getrennt an
|
||
den Modulnamen angehängt (<code class="literal">LDAP:Name-der-Konfiguration</code>). Der entsprechende Abschnitt in der Konfigurationsdatei
|
||
lautet dann <code class="literal">[authentication/Name-der-Konfiguration]</code>.</p><p>Die verfügbaren Parameter für die LDAP-Konfiguration lauten:</p><div class="variablelist"><dl><dt><span class="term">
|
||
<code class="literal">host</code>
|
||
</span></dt><dd><p>Der Rechnername oder die IP-Adresse des LDAP- oder
|
||
Active-Directory-Servers. Diese Angabe ist zwingend
|
||
erforderlich.</p></dd><dt><span class="term">
|
||
<code class="literal">port</code>
|
||
</span></dt><dd><p>Die Portnummer des LDAP-Servers; meist 389.</p></dd><dt><span class="term">
|
||
<code class="literal">tls</code>
|
||
</span></dt><dd><p>Wenn Verbindungsverschlüsselung gewünscht ist, so diesen
|
||
Wert auf ‘<code class="literal">1</code>’ setzen, andernfalls auf
|
||
‘<code class="literal">0</code>’ belassen</p></dd><dt><span class="term">
|
||
<code class="literal">verify</code>
|
||
</span></dt><dd><p>Wenn Verbindungsverschlüsselung gewünscht und der Parameter <em class="parameter"><code>tls</code></em> gesetzt ist, so gibt dieser
|
||
Parameter an, ob das Serverzertifikat auf Gültigkeit geprüft wird. Mögliche Werte sind <code class="literal">require</code> (Zertifikat
|
||
wird überprüft und muss gültig sei; dies ist der Standard) und <code class="literal">none</code> (Zertifikat wird nicht
|
||
überpfüft).</p></dd><dt><span class="term">
|
||
<code class="literal">attribute</code>
|
||
</span></dt><dd><p>Das LDAP-Attribut, in dem der Benutzername steht, den der
|
||
Benutzer eingegeben hat. Für Active-Directory-Server ist dies
|
||
meist ‘<code class="literal">sAMAccountName</code>’, für andere
|
||
LDAP-Server hingegen ‘<code class="literal">uid</code>’. Diese Angabe ist
|
||
zwingend erforderlich.</p></dd><dt><span class="term">
|
||
<code class="literal">base_dn</code>
|
||
</span></dt><dd><p>Der Abschnitt des LDAP-Baumes, der durchsucht werden soll.
|
||
Diese Angabe ist zwingend erforderlich.</p></dd><dt><span class="term">
|
||
<code class="literal">filter</code>
|
||
</span></dt><dd><p>Ein optionaler LDAP-Filter. Enthält dieser Filter das Wort
|
||
<code class="literal"><%login%></code>, so wird dieses durch den vom
|
||
Benutzer eingegebenen Benutzernamen ersetzt. Andernfalls wird
|
||
der LDAP-Baum nach einem Element durchsucht, bei dem das oben
|
||
angegebene Attribut mit dem Benutzernamen identisch ist.</p></dd><dt><span class="term">
|
||
<code class="literal">bind_dn</code> und
|
||
<code class="literal">bind_password</code>
|
||
</span></dt><dd><p>Wenn der LDAP-Server eine Anmeldung erfordert, bevor er
|
||
durchsucht werden kann (z.B. ist dies bei
|
||
Active-Directory-Servern der Fall), so kann diese hier angegeben
|
||
werden. Für Active-Directory-Server kann als
|
||
‘<code class="literal">bind_dn</code>’ entweder eine komplette LDAP-DN wie
|
||
z.B. ‘<code class="literal">cn=Martin
|
||
Mustermann,cn=Users,dc=firmendomain</code>’ auch nur der
|
||
volle Name des Benutzers eingegeben werden; in diesem Beispiel
|
||
also ‘<code class="literal">Martin Mustermann</code>’.</p></dd><dt><span class="term">
|
||
<code class="literal">timeout</code>
|
||
</span></dt><dd><p>Timeout beim Verbindungsversuch, bevor der Server als nicht erreichbar gilt; Standardwert: 10</p></dd></dl></div></div><div class="sect3" title="2.10.4.3. HTTP-Header: Username in Header"><div class="titlepage"><div><div><h4 class="title"><a name="Passwort%C3%BCberpr%C3%BCfung_HTTPHeaders"></a>2.10.4.3. HTTP-Header: Username in Header</h4></div></div></div><p>
|
||
Diese Methode der Authentifizierung überlässt einem vorgelagerten Webserver oder Proxyserver die Authentifizierung. Dazu können
|
||
SSO-Systeme wie z.B. Authelia oder Authentik zum Einsatz kommen. Die vorgelagerten Server übermitteln dann den Usernamen der
|
||
authentifizierten Person in einem speziellen HTTP-Header, der an kivitendo durchgereicht wird. Damit kivitendo nicht von
|
||
beliebigen Quellen aus mit so einem Usernamen aufgerufen werden kann, verlangt kivitendo weiterhin, dass in einem weiteren
|
||
Header ein Shared Secret übertragen wird. Dieses Secret wird vom Administrator vergeben und sollte nicht weitergegeben werden.
|
||
</p><p>
|
||
Über einen weiteren Header wird wiederum gesteuert, an welchem Mandanten die Anmeldung erfolgt. Dies geschieht über die
|
||
Datenbank-ID des Mandanten.
|
||
</p><p>
|
||
Um diese Methode zu aktivieren, muss das Authentifizierungsmodul auf <code class="literal">HTTPHeaders</code> gestellt werden. Zusätzlich
|
||
muss im Abschnitt <code class="literal">authentication/http_headers</code> der Parameter <code class="literal">enabled=1</code> und im Abschnitt
|
||
<code class="literal">authentication/http_basic</code> der Parameter <code class="literal">enabled=0</code> gesetzt werden. Die folgenden Parameter
|
||
müssen anschließend im Abschnitt <code class="literal">authentication/http_headers</code> konfiguriert werden:
|
||
</p><div class="variablelist"><dl><dt><span class="term">
|
||
<code class="literal">client_id_header</code>
|
||
</span></dt><dd><p>Name des Headers, in dem das vorgelagerte System die Datenbank-ID des Mandanten überträgt.</p></dd><dt><span class="term">
|
||
<code class="literal">user_header</code>
|
||
</span></dt><dd><p>Name des Headers, in dem das vorgelagerte System den Namen des authentifizierten Users überträgt.</p></dd><dt><span class="term">
|
||
<code class="literal">secret_header</code>
|
||
</span></dt><dd><p>Name des Headers, in dem das vorgelagerte System das Shared Secret.</p></dd><dt><span class="term">
|
||
<code class="literal">secret</code>
|
||
</span></dt><dd><p>Wert des Shared Secrets selber, der vom vorgelagerten System übertragen werden muss, damit die Werte als gültig
|
||
angesehen werden.</p></dd></dl></div></div><div class="sect3" title="2.10.4.4. HTTP-Header: Basic Authorization"><div class="titlepage"><div><div><h4 class="title"><a name="Passwort%C3%BCberpr%C3%BCfung_HTTPBasic"></a>2.10.4.4. HTTP-Header: Basic Authorization</h4></div></div></div><p>
|
||
Diese Methode der Authentifizierung überlässt dem Webserver (meist Apache) die Authentifizierung mittels der standardisierten
|
||
HTTP Basic Authentication (RFC 7617). Dazu muss der Webserver so konfiguriert werden, dass er für alle kivitendo-Requests vom
|
||
Webbrowser Authentifizierung verlangt. Zusätzlich muss er veranlasst werden, den angegebenen Usernamen auch an kivitendo zu
|
||
übermitteln. Dies könnte beispielhaft wie folgt aussehen:
|
||
</p><pre class="programlisting"><Directory /path/to/kivitendo-erp>
|
||
AllowOverride All
|
||
Options ExecCGI Includes FollowSymlinks
|
||
|
||
# Require authentication from local user file:
|
||
AuthType Basic
|
||
AuthName "kivitendo"
|
||
AuthUserFile /etc/apache2/htpasswd.kivitendo
|
||
Require valid-user
|
||
|
||
# Pass name of authorized user to kivitendo:
|
||
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
|
||
</Directory></pre><p>
|
||
Um diese Methode zu aktivieren, muss das Authentifizierungsmodul auf <code class="literal">HTTPHeaders</code> gestellt werden. Zusätzlich
|
||
muss im Abschnitt <code class="literal">authentication/http_basic</code> der Parameter <code class="literal">enabled=1</code> und im Abschnitt
|
||
<code class="literal">authentication/http_headers</code> der Parameter <code class="literal">enabled=0</code> gesetzt werden.
|
||
</p></div></div><div class="sect2" title="2.10.5. Name des Session-Cookies"><div class="titlepage"><div><div><h3 class="title"><a name="Name-des-Session-Cookies"></a>2.10.5. Name des Session-Cookies</h3></div></div></div><p>Sollen auf einem Server mehrere kivitendo-Installationen
|
||
aufgesetzt werden, so müssen die Namen der Session-Cookies für alle
|
||
Installationen unterschiedlich sein. Der Name des Cookies wird mit dem
|
||
Parameter <code class="varname">cookie_name</code> im Abschnitt
|
Auch abrufbar als: Unified diff
Auth: HTML- & PDF-Dokumentate neu bauen