B2B-Kundenportal-Berechtigungen sollten vor der Gestaltung des ersten Dashboards feststehen. In einem Kundenunternehmen können Einkauf, Buchhaltung und Geschäftsführung unterschiedliche Aufgaben haben. Wer eine Bestellung vorbereitet, darf möglicherweise keine Zahlung freigeben. Ein pauschaler Kundenlogin bildet diese Unterschiede nicht ausreichend ab und erschwert später die Prüfung konkreter Zugriffsprobleme.
Nehmen wir einen fiktiven Lieferanten für Werkstattausstattung. Seine Kunden möchten Angebote vergleichen, Bestellungen bestätigen und Rechnungen herunterladen. Einige Beschäftigte arbeiten für mehrere Niederlassungen. Vor der Entwicklung muss deshalb geklärt werden, ob die Berechtigung für das gesamte Unternehmen, eine Niederlassung oder einen einzelnen Vorgang gilt. Diese Entscheidung beeinflusst Oberfläche und Datenzugriff gleichermaßen.
Aufgaben statt allgemeiner Rollennamen beschreiben
Erstellen Sie eine Liste wichtiger Tätigkeiten und ordnen Sie diese den zuständigen Personen zu. Ein Angebot lesen, einen Preis ändern und eine Bestellung freigeben sind getrennte Tätigkeiten. Der Rollenname Administrator erklärt für sich genommen nicht, ob die Person nur eigene Beschäftigte oder sämtliche Kunden des Dienstes verwalten darf.
Notieren Sie außerdem, welche Informationen für eine Tätigkeit erforderlich sind. Der Einkauf benötigt möglicherweise eine Lieferadresse, aber keine internen Supportnotizen. Die Zugriffsmatrix sollte genügend genau sein, damit ein Entwickler und eine fachliche Verantwortliche denselben erwarteten Zustand beschreiben können. Unklare Ausnahmen gehören in eine Entscheidungsliste und nicht in spontane Annahmen während der Umsetzung.
Auch indirekte Zugriffe prüfen
Die Oberfläche kann einen fremden Auftrag ausblenden, obwohl eine direkte Anfrage weiterhin Daten liefert. Verwenden Sie deshalb zwei unabhängige Testorganisationen. Prüfen Sie bekannte Datensatzkennungen, Suchergebnisse, Exporte und Anhänge. Jeder dieser Wege muss die vorgesehene organisatorische Grenze berücksichtigen und bei einer Ablehnung verständlich reagieren.
Besonders wichtig sind vorbereitete Dateien und zeitversetzte Aufgaben. Ein Bericht kann nach dem Entzug einer Mitgliedschaft erstellt werden. Ein bereits erzeugter Download kann außerhalb des normalen Portalservers liegen. Legen Sie fest, welches Verhalten in diesen Situationen gelten soll, und prüfen Sie den tatsächlichen Abruf statt nur die sichtbare Menüstruktur.
Änderungen während einer Aufgabe berücksichtigen
Entziehen Sie einer Testperson die Freigabeberechtigung, nachdem sie eine Bestellung geöffnet hat. Versuchen Sie danach die Bestätigung über die noch offene Seite. Wiederholen Sie den Ablauf bei einem Wechsel der ausgewählten Niederlassung. Die Anwendung sollte keine alten Annahmen über die aktuelle Organisation ungeprüft übernehmen.
Bewahren Sie dabei erforderliche Entwürfe mit einer nachvollziehbaren Behandlung auf. Ein abgewiesener Vorgang und ein verlorener Arbeitsstand sind verschiedene Probleme. Erklären Sie, ob die Person einen neuen Verantwortlichen auswählen, sich erneut anmelden oder eine fachliche Entscheidung abwarten muss. So bleibt die Zugriffskontrolle mit einem nutzbaren Arbeitsablauf verbunden.
Die Übergabe an Beispielen abnehmen
Fordern Sie für jede wichtige Tätigkeit einen erlaubten und einen abgewiesenen Testfall an. Halten Sie die verwendeten Rollen und Organisationen fest. Ergänzen Sie automatisierte Prüfungen für die gemeinsam vereinbarten Grenzen. Ein einzelner erfolgreicher Testlauf ist keine umfassende Sicherheitsprüfung, bietet aber einen überprüfbaren Ausgangspunkt für die Abnahme.
Bringen Sie zum Projektgespräch mit Brainbaby Labs eine Bestellung oder Freigabe aus Ihrem heutigen Ablauf mit. Gemeinsam lassen sich daraus die notwendigen Ansichten, Serverentscheidungen und Supportaufgaben ableiten. Eine belastbare Leistungsbeschreibung erklärt dann, wer welchen Vorgang unter welchen Bedingungen abschließen kann. Das macht Angebote verschiedener Entwicklungsteams wesentlich besser vergleichbar.