Task-based role system and access control

Einleitung

Das ehrenamtliche System der Freiwilligen ist hinsichtlich der Aufgabenverteilung hochdynamisch. Aufgaben werden mitunter wöchentlich neu vergeben, teilweise zerlegt und neu zusammengesetzt, so dass klassische Rollensysteme nicht angewandt werden können. Mit der Bewältigung von Aufgaben können auch stets spezielle Zugriffsrechte innerhalb des Pools verbunden sein. Daher impliziert eine neue Gestaltung des Rollensystems auch eine Umgestaltung der Konzeption der Zugriffsrechte.

Es soll also ein Konzept entwickelt werden, welches die Verwaltung von Zugriffsrechten über dem Nutzer zugeordnete Aufgaben erlaubt. Hierfür ist es notwendig Aufgaben im digitalen System zu verwalten (CRUD) und diese auf Ebene der Crews (und teilweise durch das Brunnenbüro) zu verteilen. Ein Nutzer kann dann auf eine Funktion zugreifen, wenn dem Nutzer Aufgaben zugewiesen sind, die den Zugriff auf die Funktion erlauben. Da es viele kleine Aufgaben geben wird, ist eine skalierbare Verteilung der Aufgaben nötig. Dies wird über dynamische Rollen erreicht. Eine Crew ist in der Lage Rollen zu definieren und diese Rollen einzelnen (oder auch parallel mehreren) Supportern zuzuweisen.

Access Control

• Zuordnung Zugriffsrechte -> Aufgabe: Entwickler beschreiben kurz Sinn & Zweck einer Action, benennen diese und bündeln die Action ggf. mit anderen Actions. Diese beschriebenen Actions können dann Aufgaben (Tasks) zugeordnet werden, was einer impliziten Permission im Kontext des Tasks entspricht.
• MS fragt Nutzer bei Drops (Nutzer via Shared Sessions) und Tasks MS (für Tasks des Nutzers) an --> beide Infos können in Session gespeichert werden --> Für Veränderungen der Tasks-Liste eines Nutzers PUSH Kommunikation von Task MS zu MS implementieren?
• Po(Nutzer, Task) mit Task in Tasks kann bestimmt werden, da (Task, Action) Assoziation existiert --> Sum(Po(Nutzer, Task) | Task in Tasks) != Empty? --> Permission granted
• Braucht View in der Assoziationen zwischen Tasks und Zugriffsrechten (Actions) hergestellt werden kann. Dabei bestehen Many-to-Many Beziehungen zwischen Tasks und Actions
• View dafür in eigenem MS oder Tasks MS? --> leitet Assoziationen (task_id; action_id) an die jeweiligen MS weiter, die die Actions verwalten --> MS müssen eine ACL für Tasks implementieren

Offene Herausforderungen

• Hierarchien innerhalb der Aufgaben und Rollen? --> Was passiert wenn eine Rolle oder Aufgabe zwischen zwei Personen aufgeteilt werden soll?
• Vorgabe bestimmter Rollen und Aufgaben? Ist das BB in der Lage jeder Crew Aufgaben und damit inherent auch Rollen vorzugeben? Wenn ja: Wie kann deren Verteilung realisiert werden, vor allem in Bezug auf der erste Frage der Aufteilung von Aufgaben und Rollen? Sind diese Rollen aus Sicht der Crews statisch?
• Initiierung des Systems durch die Verteilung der Aufgabe "Aufgaben und Rollen definieren und verteilen" an einzelne Supporter innerhalb der Crew durch das BB
• Mapping zwischen Aufgaben und Zugriffsrechten und der damit verbundenen Implementierung des neuen Systems? Woher weiß ich an einer Action, ob der aktuelle Nutzer Zugriff auf diese hat?