Entwurf einer anwendungsunabhängigen Zugriffskontrolle mittels ...

Entwurf: Policy-basierte Zugriffskontrolle
Wenn ein neues Anwendungsobjekt erzeugt wird, werden die folgenden Schritte
ausgeführt:
1. Wenn ein neues Anwendungsobjekt erzeugt wird, erkennt dies der
Sicherheitsproxy (die Klasse „AbstractAuthorizationAspect“).
2. Dieser prüft mit Hilfe der Objekt-Verwaltung, ob es sich bei dem Objekt um
eine zu schützende Anwendungsklasse handelt.
3. Wenn ja, dann muss die Policy-Verwaltung diesem Objekt eine Policy
zuweisen.
4. Wenn der Benutzer bereits ein „PolicySet“ für diese Klasse und die von ihm
gewählte Objekt-Klassifizierung (z.B. alle Fahrtenbucheinträge mit der
Klassifikation Privat) hat, dann wird dem Objekt dieses „PolicySet“ zugeordnet.
5. Andernfalls wird ein neues PolicySet erzeugt und dem Objekt zugewiesen.
Es wird hier jedoch auf verschachtelte Objektgruppen verzichtet. Das Konzept kann
aber entsprechend abgeändert werden. Dabei ist darauf zu achten, dass kein Zyklus im
Objektgruppengraph entsteht, da eine Gruppe nicht in sich selbst enthalten sein kann.
4.3.4 Die Aktionsverwaltung
Genauso wie die Policy-Verwaltung ist auch die Aktionsverwaltung eine Singelton
Klasse. Sie verwaltet die Einstellungen für alle zu schützenden Methoden. Die
Aktionsverwaltung wird beispielsweise in dem Sequenzdiagramm in Abbildung 16
verwendet.
Für jede zu schützende Methode erzeugt die Aktionsverwaltung eine Ontologie
„SecureAction“. Außerdem bietet sie Funktionen zum Erzeugen, Ändern, Einsehen und
Löschen von den Ontologien „ObjectType“ und „Permission“ an (siehe Abbildung 19).
Zugriffsrechte (engl. permissions) könnten z.B. wie folgt definiert sein:
• Für get-Methoden Leserechte,
• für set-Methoden Schreibrechte und
• für delete-Methoden Löschrechte.
46