Was es beim Thema GUI-Security zu berücksichtigen gibt, beantworten wir in einem weiteren Rückblick auf die JAX 2010. Wir blicken erneut in eine Session von Mike Wiesner.

Wir suchen Antworten auf die Frage “Ist GUI-Security wichtig?”

Grundsätzlich gibt es folgende Anliegen zu berücksichtigen:

• Als Kunde möchte ich, dass die Anwendung sicher ist.
• Als Entwickler möchte ich ein gutes Framework (Spring).
• Als Benutzer möchte ich eine benutzbare Anwendung.

Sollte man den Ansatz von Security First wählen? Dieser hat den Nachteil, dass das Erstellen eines Testszenarios erheblich schwieriger ist, wenn z.B. Links oder Buttons, die man selektieren möchte, bereits nicht mehr sichtbar sind. Man muss also berücksichtigen, ob es das eingesetzte Framework erlaubt, ohne grosse Umstände die Security aus- respektive wieder einzuschalten.

Wäre es also vielleicht besser, den Ansatz von Full Access with Errors zu wählen? Die Idee dahinter ist es, alle Komponenten des GUIs anzuzeigen, und beim Zugriff einen Fehler einzublenden. Von diesem Vorgehen wird schwerstens abgeraten. Zum einen ist es aus Usability Sicht für den Benutzer sehr unangenehm, dauernd mit Fehlermeldungen bombardiert zu werden und zum anderen taucht früher oder später die Anforderung auf, dass nicht alle Benutzer alles sehen dürfen. Ein gutes Beispiel hierfür ist ein Navigationslink auf eine Controlling Page, die nur für Controller gedacht ist. Wird dieser Link immer angezeigt, gibt dies dem Angestellten eventuell bereits einen zu tiefen Einblick ins Unternehmen.

Welches System sollte man denn nun wählen?

Bestens bekannt ist das Rollen-basierte System, wo Benutzer unterschiedliche Rollen zugewiesen bekommen und in der Benutzeroberfläche nur das angezeigt wird, was effektiv für diese Rollen erlaubt ist.

 

Folgendes Codebeispiel zeigt, wie man mittels Spring Security einen Bereich einer Seite nur für gewisse Rollen sichtbar macht:

<%@ taglib prefix=“authz“ uri=“http:// www.springframework.org/security/tags“ %>
<authz:authorize ifAllGranted=“ROLE_ADMIN“>
TOP SECRET
</authz:authorize>

Viel flexibler ist allerdings das Rechte-basierte System, bei dem direkt mit Rechten operiert wird. Sollte eine bestehende Rolle ein zusätzliches Recht haben, muss nicht gleich die Security im GUI angepasst, sondern lediglich der Rolle ein weiteres Recht zugewiesen werden.

 

<%@ taglib prefix=“authz“ uri=“http:// www.springframework.org/security/tags“ %>
<authz:authorize ifAllGranted=“RIGHT_TOPSEC“>
TOP SECRET
</authz:authorize>

Noch flexibler ist folgender Ansatz, bei dem zusätzlich das Verschachteln von Rollen möglich ist. So muss z.B. eine Grundauswahl von Rechten nur einmal einer Rolle zugewiesen werden:

 

Bis jetzt haben wir uns nur darum gekümmert, aufgrund von Rollen und Rechten Komponenten ein- bzw. auszublenden. Wie gehen wir aber mit Instanz-Berechtigungen um? Folgendes Beispiel erläutert die Problematik. Es handelt sich um Ferienanfragen.

 

Es wäre natürlich jetzt nicht nett, wenn der eingeloggte Benutzer (Mike Wiesner) eine Ferienanfrage von einem anderen Benutzer (Agim Emruli) canceln könnte, also darf dieser Link nicht sichtbar sein.
Auf unserem Objekt für die Ferienanfrage (Request) muss nun also ein Flag drauf (deletable):

 

Um unser Domänenmodell sauber zu halten, kann dieses Objekt in zwei Objekte aufgesplittet werden:

 

Mittels AspectJ werden die Objekte dann wieder zusammengefügt:

 

So bleibt das Domänenmodell sauber und die Security kann separat oder sogar erst am Schluss umgesetzt werden.

Fazit

• GUI-Security ist wichtig
• Rechte statt Rollen
• GUI-Security gegebenenfalls nicht zu früh umsetzen
• Instanz-Berechtigungen mit AspectJ Inter-type declarations