Förderjahr 2016 / Projekt Call #11 / ProjektID: 1909 / Projekt: fairlogin
Login Prozeduren vereinheitlicht
faircoop
Die FairCoop Community nutzt die fairchat Infrastruktur von fairkom und unser GitLab seit längerem. Aber nun wurde auch eine eigenständige DokuWiki Installation über unseren fairlogin Dienst integriert. Unser eigenes Internes DokuWiki hatten DokuWiki wir ja vor Kurzem an das fairlogin angebunden. Ursprünglich versuchten wir das DokuWiki so einfach wie möglich zugänglich zu machen und die Registrierung automatisiert aus dem DokuWiki an das fairlogin zu delegieren. Das hat dieses mal leider doch zu erheblichen Spam Einträgen geführt und wir mussten diese automatische Registrierung entsprechend einschränken (mit ReCaptcha) und unsere Daten bereinigen. Zusätzlich haben wir beim Registrierungsformular Anti-Spam-Fragen eingeführt und in drei Sprachen übersetzt.
Handy-Signatur & Bürgerkarte
Testweise haben wir die Handysignatur schon im fairlogin eingebaut und man kann diese auch schon nutzen. Angebunden sind wir an der Demo-Anwendung des EGIZ. Jedoch möchten wir diesen Dienst auch produktiv anbieten. Dafür werden wohl einen MOA-ID3 Dienst benötigen. MOA steht für Module für Online-Applikationen und wir brauchten das Modul Identifikation ID, welches die Autorisierung über der Bürgerkarte und der Handysignatur realisiert. Derzeit suchen wir nach vertrauenswürdigen Partnern (das heißt einen aus der öffentlichen Verwaltung), gegen die wir User authentifizieren können. Wir würden es gerne vermeiden einen eigenen MOA-ID3 Dienst zu betreiben und aktuell halten zu müssen, jedoch wäre das auch eine Option.
GroupOffice
Das GroupOffice ist für fairkom ein zentraler Dienst, den wir soweit wie möglich einbinden wollen. In der für uns zur Verfügung stehenden Version unterstützt GroupOffice jedoch nur eine direkte LDAP Integration und noch keine OpenID Connect oder SAML Schnittstelle. Daher versuchen wir zunächst die LDAP Integration umzusetzen, um in zukünftigen Versionen auf eine OIDC Integration umzustellen.
Schwierig wird es, da unsere User bisher Gruppen und Benutzer im GroupOffice verwaltet konnten. Diese Verwaltung musste nun vorerst im KeyCloak passieren. Bei der LDAP Integration werden wir die Benutzer und Gruppen Verwaltung innerhalb vom GroupOffice zunächst abschalten und diese ausschließlich über KeyCloak bzw. einem LDAP-Explorer vornehmen. Am schönsten wäre es wenn wir im GroupOffice die Benutzer und Gruppen Verwaltung alternativ über SCIM an das KeyCloak delegieren könnten ohne dass der GroupOffice User das bemerkt.
Letztendlich sollten aber im GroupOffice auch nur ein Subset der User und Gruppen von KeyCloak verfügbar sein. Innerhalb von GroupOffice sollten User nur User sehen, die ihren GroupOffice sichtbaren Gruppen vorhanden sind. Letzteres wird von GroupOffice intern bei eigenen Verwaltung der Gruppen auch sichergestellt. Jedoch ob wir das auch über die LDAP Schnittstelle ermöglichen könnten, wissen wir noch nicht.
Bisher arbeiten wir an dieser LDAP Integration auf extra dafür eingerichteten Testsystemen. Und wir müssen dann noch die aktuelle und die zukünftige User und Gruppen-Verwaltung lösen. KeyCloak bietet zwar ein paar grundlegende Verwaltungsmasken an. Jedoch sind diese doch nicht wirklich für die Veraltung von anwendungsübergreifenden und anwendungsspezifischen Gruppen und Rollen ideal geeignet. Derzeit eruieren wir, ob man entweder die entsprechenden Berechtigungen und Anpassungen im KeyCloak realisieren kann, oder ob es darauf hinauslaufen wird, eine eigene fairlogin Oberfläche für die anwendungsübergreifende aber auch anwendungsspezifische Benutzer und Gruppen Verwaltung zu implementieren.