splinux account
===============
Anforderungen
-------------
* support für mehere dienste!
* verschieden passwörter pro dienst möglich
* aber ein master passwort
* man kann muss aber nicht
* openid (oder ähnliche) Schnittstelle
* migrations möglichkeit aus altem ???
* wie schaffen wir eine eindeutige nickname situation (auch mit den alten sachen)
* sollten accounts angelegt werden die genauso wie normale spline accounts heißen? (über die weboverfläche?)
* sollte jeder interne spline account automatisch einen neuen externen brauchen
* userping
* sollte in ein ldap
* sprechen viele applicationen
* "einfaches" handling
Dienste
-------
* gitlab (done)
* jabber
* foren (done)
* dev?
* zettel (done)
* pad (alt) -> nein
* pad (neu) -> entscheiden wir wenn es accounts richtig kann
* spline ldap?
Problem
-------
Die meisten Dienste checken PW/Username über das durch führen eines binds (login auf dem ldap server). Bei open-ldap-server wird dies immer gegen das userPassword Feld des Objekts als das man sich einloggt getestet. Damit ist es nicht einfach möglich verschiedene Passwörter für das gleiche Objekt zu haben.
Idee wäre das der Dienst versucht auf "dc=[...],uid=exampleuser,cn=$DIENST" zu binden, und der ldap server dann intern iwie das Passwort management mach muss.
Lösungsansätze
--------------
* einen Account pro Dienst für jeden User
* wenig (keine) automatismen die uns helfen
* nur ldap als Protokoll benutzen, aber eigenen Ldapserver/Storage
* zum Beispiel mit: https://github.com/antong/ldaptor
* einen existierenden patchen
* http://www.fefe.de/tinyldap/
* oder halt open ldap
* anderen ldap server testen (die sowas eventuell können)
* apache direcotry
* open directory
* fedora directory
* unter verwendung von open-ldap und rwm die Daten in korrekter Art und Weise umschreiben
[ webseite ] <=> [ postgres ] => [ dump-script ] => [ ldap ] <=> [ seiten ]
[ webseite ] <=> [ postgres ] <=> [ ldaptor ] <=> [ seiten ]
[ webseite ] <=> [ openldap (rvm oder n-Accounts pro user/flag) ] <=> [ seiten ]
[ webseite ] & [ seiten ] <=ldapv3=> [ ldaptor ] <=> [ backend ]
Lösung
------
Beim bind auf den Ldap-Server kann mit rwm leider nich das password Feld umgeschrieben werde. Daher wird für jeden Dienst ein eigener Entry benötigt. Mit rwm wird dann fall in diesem Entry kein userPassword gesetzt ist, die bindDN auf die eigentlich userDN übersetzt.
Zugriffsrechte für die Unteraccounts sollte mit regexp genau für den jeweiligen Eigentümer gegeben werden können. (siehe slapd.access(5))
Für die einzelnen Dienste werden die Daten aus dem Hauptuser per rwm reingemappt. (Name, EMail, uid)
Todo:
* Schemas definieren (Hauptaccount (posixAccount ist zu viel), Dienste ())
* rwm Mapping für die Daten in die Dienstaccounts (damit können dann die Dienste einfach einen Bind auf die Dienstaccounts durchführe und bekommen alle Daten)
* Problem: gemappte attribute könnten anscheinend nicht als LDAP Filter verwendet werden, für uid wird das aber zwingend benötigt, als Lösung geht vielleicht das slapd-meta backend
* WICHTIG: Wenn rwm Mapping für search steht, beim bindDN rewriting beim matching auf den speziellen Dienstaccount auch die uid überprüfen.
Migration
---------
betroffene Dienste:
* foren
* jabber
* eventuell zettel
Vorraussetzung:
* für jeden Dienst liegen Username/ Passworthashlisten vor
Vorgehen:
* zu erst wählt der Nutzer einen Dienst aus dem er seinen Username mitnehmen möchte.
* dann muss sich der Benutzer für diesen Namen authenfieren
* ermittle alle Dienste die einen Benutzer mit dem gleichen Namen haben
* für jeden Dienst muss der Benutzer sich authentifizieren
* gelingt dies für jeden Dienst, wird der entsprechende Splinuxaccount angelegt
Doku für neue Dienste
Im folgenden eine Dokumentation um neue Dienste an den Spline-Account-Ldap-Server anzubinden. Wir benutzen einen LDAP-Server in dem mittels folgenden LDAP-Overlays "translucent" und "rvm" dienstspezifische Passwörter möglich sind. Alle Spline-Accounts selbst werden in einem eigenen LDAP-Tree und zwar unter ou=users abgespeichert. Dienste versuchen sich nun nicht gegen diesen Tree zu binden, sondern gegen den virtuellen cn=$DIENST_NAME,cn=virtual-Tree. Um nun einen neuen Dienst an die Spline-Accounts anzubinden, muss folgendes getan werden:
Zuerst (wenn man ihn braucht) muss ein neuer Admin-Account für den jeweiligen Dienst in "dc=accounts,dc=spline,dc=inf,dc=fu-berlin,dc=de" erstellt werden:
dn: cn=admin-$DIENST_NAME,dc=accounts,dc=spline,dc=inf,dc=fu-berlin,dc=de
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin-$DIENST_NAME
description: LDAP administrator
Danach den Service selbst die services und virtual als organizationalRole anlegen.
Für services:
dn: cn=$DIENST_NAME,ou=services,dc=account,dc=spline,dc=inf,dc=fu-berlin,dc=de
objectClass: top
objectClass: organizationalRole
cn: $DIENST_NAME
Für virtual
dn: cn=$DIENST_NAME,ou=virtual,dc=account,dc=spline,dc=inf,dc=fu-berlin,dc=de
objectClass: top
objectClass: organizationalRole
cn: $DIENST_NAME
Jetzt kann im Dienst selbst mit folgenden LDAP-Einstellungen sich authentifiziert werden:
server: ldap://vm-accounts
base-dn: cn=$DIENST_NAME,ou=virtual,dc=account,dc=spline,dc=inf,dc=fu-berlin,dc=de
admin-dn: cn=admin-$DIENST_NAME,dc=accounts,dc=spline,dc=inf,dc=fu-berlin,dc=de
admin-pw: ...
user-mask: uid=%s
Doku Slapd