fairchat:

Anonym or identifiziert, auf https://fairchat.net kann man sich sowohl anonym als auch mit einer fairchat.net Identity austauschen.  Jeder darf in die öffentlichen Kanäle und sich an den Diskussionen beteiligen.  Wenn man sich mit einer fairlogin Identität aber authentifiziert, kann man auch eigene geschlossene Kanäle anlegen und Mitglieder dazu einladen bzw. eingeladen werden.

GitLab:

Unsere fairlogin-Integration wird von unsere faircoop-Community geschätzt: https://git.fairkom.net/fairlogin/fairkom/issues/35#note_1277 und es zeigt sich das hier bei der Anbindung doch ein paar Schwierigkeiten ergeben hatten.  Die SAML2 der meteor-SAML Bibliothek konnte mit Email Adressen, die Großbuchstaben enthielten nicht vernünftig umgehen.  Aber nachdem wir das Problem bei uns behoben haben, konnten wir es auch Upstream zur Verfügung stellen und nun ist es auch angenommen worden: https://github.com/arminfelder/Rocket.Chat/pull/1

ISPConfig:

Wenn die Verwaltung von Identitäten nicht eindeutig einer Anwendung zugeordnet werden kann, müssen gut integrierte Schnittstellen eine gemeinsame Verwaltung ermöglichen.  Der Domain-Verwalter einer Domain im ISPConfig muss unter anderem IMAP Benutzer anlegen können die dann auch von fairlogin verwaltet werden.  Eine Möglichkeit das zu realisieren, ist die Verwaltung dieser User im fairlogin Dashboard zu integrieren, welches einerseits die Identititäten in fairlogin und andererseits über die REST-API diese auch ISPConfig anlegt.  Damit der normalen Domianverwalter aber nicht zwangsläufig mit zwei Anwendungen arbeiten muss, sollten die Kernfunktionen des ISPConfig über das Dashboard implementiert werden.  Dazu gibt ISPConfig ein Beispiel, wie man solch eine REST-API zur Verfügung stellen kann.  Wenn man sich auf diesen Pfad einlässt, muss sichergestellt werden, dass diese REST-API Erweiterung auch mit zukünftigen ISPConfig Versionen funktionieren.  Das könnte intensive Instandhaltungskosten verursachen.  Das sollte man sich also gut überlegen, bevor man die Möglichkeit verwirft doch die Verwaltung grundsätzlich über das ISPConfig zu realisieren.

GroupOffice:

Um GroupOffice mit fairlogin statt mit seiner internen User-Datenbank zu betreiben, muss das LDAP-Schema noch um entsprechende Felder erweitert werden.  An sich sollte dieses Schema vom GroupOffice Plugin zur Verfügung gestellt werden.  Nach der Verfollständigung der Felder haben wir anschließend auch die GroupOffice Gruppen ins LDAP und damit ins fairlogin übertragen können.  Diese Gruppenzugehörigkeiten sollen später genutzt werden um zum Beispiel Berechtigungen Anwendungsübergreifend zu pflegen.  Jeder sollte auch die Mitglieder seine Gruppe sehen, in jeder Anwendung.  Aber es gibt Gruppen, wie zum Beispiel die Gruppe "Alle" die dann nur von den Administratoren gesehen werden sollen, um z.B. neue Mitglieder einer Gruppe zuzuordnen.  Diese Semantik applikationsübergreifend z.B. per LDAP Zugriffe sicherzustellen, wird eine der nächsten Herausforderungen.

Federated Identity Management - Einbindung von externen Identity Providern

Unser Ziel ist es ein Netzwerk von Föderierten Identity Providern https://de.wikipedia.org/wiki/F%C3%B6derierte_Identit%C3%A4t zu etablieren.  Mit mit fairlogin, das auf KeyClock basiert erlaubt derzeit das Registrieren und einloggen mit einem GitHub oder Google Account.  Damit braucht fairlogin zunächst kein Passwort.  Zugegebenermaßen können damit aber manche Dienste, die noch mit LDAP statt mit SAML2, OpenID oder OAuth2 angebunden wurden, vorerst nur eingeschränkt oder noch nicht genutzt werden. 

Smartphones:

Mit Smartphones: https://www.fairkom.eu/smartphone-cloud ergibt sich ein neuer Anwendungsfall für fairlogin... kann eine Federated SSO Identity als Smartphone Identität dienen?  Das gilt es für uns noch herauszufinden!

Es sind gerade viele Teile in Bewegung aber nun werden auch die ersten echten praktischen Erfahrungen gesammelt!  Stay tuned!