API und minimale Leserechte für jeden

[Florian_1990]

Ich bin gerade dabei, die API ein wenig auszuprobieren, Anwendungsfälle zu überlegen und die Grenzen der API zu erkunden. Als ich Zugang zur Testumgebung der API bekommen habe, wurde mir auch mitgeteilt, dass zukünftig voraussichtlich jeder User API-Rechte bekommen soll. Meines Erachtens ist das prinzipiell eine gute Sache.

Mein erster Gedanke war, dass sich das super dafür eignen würde, den Zugang zum internen Bereich von Stammesseiten direkt über den NaMi-Zugang zu regeln. Das wäre aber einer eigenen Lösung mit automatischem User-Import nur dann überlegen, wenn jeder NaMi-User über einige minimale Leserechte verfügt (darunter einige personenbezogene Daten über sich selbst, eigene Tätigkeiten und Gruppierungszugehörigkeit). In diesem Fall wäre es möglich, einige Funktionen (z. B. vorausgefüllte Aktionseinladungen) sowie eine Loginverwaltung völlig ohne zentral auf dem Webserver hinterlegte Logindaten eines Users mit großflächigen Leserechten umzusetzen.

Außerdem wäre das gegenüber Import-Lösungen vorteilhaft, da bei diesen vielfach über explizite Abfragen geprpüft werden muss, über welche Rechte (oder andere Attribute, z. B. Stufe) ein User aktuell verfügt. Auch verleiten sie dazu, die Rechte (Attribute) lediglich einmal beim Import in die Datenbank zu prüfen und im Anschluss nicht erneut zu berechnen.

Auch aus Gesichtspunkten der Sicherheit wäre das vorteilhaft. Es wäre nämlich sicherer, das Login mittels Javascript direkt zwischen Browser und NaMi zu regeln und der entsprechenden Homepage dann (wieder mittels Javascript oder ganz klassisch als http-Cookie) lediglich den Cookie zu übermitteln. So würden die Zugangsdaten beim User (und natürlich in der NaMi) bleiben. Aber auch hier müsste eine serverbasierte Anwendung schließlich bei jedem User in der Lage sein, Informationen über die Identität eines Users in Erfahrung zu bringen, da sich sonst jeder x-beliebige NaMi-User einloggen könnte.

[daniel]

Hallo Florian,

ein paar Hintergründe zur Rechteverwaltung in NaMi:

1. NaMi unterscheidet zwischen Mitgliedern und Benutzern/Usern. Alle Mitglieder, die bestimmte Tätigkeiten innehaben können sich als Benutzer registrieren. z.B. können sich Mitglieder der Kinderstufen sowie Mitglieder ohne aktive Tätigkeit nicht als Benutzer registrieren.
Nur wenn du einen Benutzer hast, kannst du dich überhaupt in NaMi einloggen, wirst aber ersteinmal nichts weiter sehen können, solange dir nicht jemand Rechte zugewiesen hat.

2. Die Rechtevergabe bezieht sich immer auf Gruppierungen (Stamm, Bezirk, Diözese, Bund) d.h. wenn du Leserechte hast, gelten diese immer für die ganze Gruppierung. Rechte auf einzelne Personen oder Stufen sind im NaMi-Rechte-Modell nicht vorgesehen. Wir haben 2015 schon einen Feature-Request eingekippt, dass es von diesem Modell eine Ausnahme gibt: ich kann Rechte auf meine eigenen Daten erhalten. Bisher sagt die Firma aber dazu, dass NaMi ein Mitgliederverwaltungssystem ist, also jeder Benutzer andere Mitglieder verwaltet. Wir werden daher den Selfservice eher auf anderem Wege z.B. über eine Webseite bereitstellen.

Zu der von Dir vorgeschlagenen Loginlösung über NaMi Benutzer machen wir uns auch schon seit längerem Gedanken. Hier über JS & Cookies selbst etwas zu basteln wäre zwar möglich, ist aber auch mit einigen Problemen behaftet (z.B. Same-Origin-Policy, Replay-Attacken usw)
Unsere Idee geht eher in die Richtung, eine oder mehrere vorhandene SingleSignOn Lösungen zu unterstützen. Dazu würden wir einen IdentityProvider z.B. per SimpleSAMLphp ( https://simplesamlphp.org/ ) aufbauen und könnten dann Authentitfizierungsmechanismen wie SAML2, CAS, OAuth2 oder OpenID oder OpenID unterstützen.

Das hätte für Dich als Betreiber einer Stammeshomepage den Vorteil, dass es für viele dieser Mechanismen bereits fertige Bibliotheken bzw Plugins für gängige Progammiersprachen und CMSe gibt.

Einige Fragen die du aufgeworfen hast, bleiben natürlich immer noch bestehen:
– wie registriert sich eine Stammesseite um an so einer Authentifizierung teilzunehmen
– welche Attribute werden übergeben (Stufe, Tätigkeit, Mailadresse,….)
usw.

Da gibts noch einiges zu Basteln und auch noch ein paar administrative Fragen zu klären.
Aber der Trend wird in diese Richtung gehen.

Viele Grüße & Gut Pfad
Daniel

[zirnm]

Hallo Florian,

ich suche jemanden, der Lust hat, eine API-Schnittstelle zu programmieren. Hintergrund ist, dass ich ein Programm auf Excelbasis geschrieben habe (den NaMi-Booster), für das die im NaMi gespeicherten Daten exportiert und in den NaMi-Booster importiert werden.

Ideal wäre allerdings, wenn ich diese Schnittstelle in den NaMi-Booster derart integrieren könnte, dass ich Benutzername und Passwort übermittle und dafür eine vorher definierte Mitgliederliste erhalte.

Wenn Dich das Thema interessiert, dann schau Dir doch meinen Artikel an, den ich unter dem Beitrag „Werbekampagne“ soeben geschrieben habe und natürlich den NaMi-Booster.

Gut Pfad,
Michael

[Autor]

Beiträge