Entitlement (Berechtigungsmechanismus)

Beiträge zur Dokumentation von Cameleon OSP

Seit "Jedermann" auf Internet-Applikationen zugreifen kann, ist es wichtig einen einfachen und dennoch mächtigen Berechtigungsmechanismus zur Verfügung zu haben. Das Cameleon-Framework kennt einen solchen Mechanismus um Berechtigungen zu erteilen – Christoph Müller nennt es "Entitlement". Damit ist es möglich anhand bestimmter Rollen bestimmte Rechte zu vergeben, beispielsweise das Recht einen Datensatz zu löschen.

Die zentrale Methode um das alles zu regulieren ist "getLevel(int subjectArea)". Den Begriff "subjectArea" muss man sich in diesem Zusammenhang als "Anwendungsgebiet" vorstellen. Wie funktioniert nun das Ganze?
 
 
Vorbereitungsarbeit

Zunächst einmal gibt es da den Anwender. Dieser muss in der Datenbanktabelle "User" gespeichert sein. Folgende Feldinhalte sind hier von Bedeutung:

- UserID (Benutzerkennung des Benutzers)
- GroupID (Gruppennummer des Benutzers)

Hinweis: Die Tabelle "User" wird automatisch angelegt, wenn Sie die Demo "cookbook" installieren. Wie Sie sehen, ist damit jeder Anwender einer bestimmten Benutzergruppe zugeordnet. In der Klasse "Constants" können Sie nun festlegen welche Gruppen es geben soll. Diese Gruppen müssen Sie in dem zweidimensionalen Array USER_GROUP speichern. Jede Benutzergruppe erhält dort einen Namen und eine mit der GruppenID der Datenbanktabelle "User" korrespondierende GruppenID. Je höher die GruppenID desto mehr darf der Benutzer im Beispiel "cookbook" tun.

Die Zuordnung zwischen dieser Benutzergruppe und dem was ein Benutzer letztendlich darf (die Berechtigungsstufe) wird dann in der Klasse "Entitlement" festgelegt. So schaut das Framework beispielsweise bei jedem Aufruf eines Dialogs nach, ob in der entsprechenden Dialog-Klasse (z.B. "DataPropertyAdministration") eine Konstante namens "subjectArea" definiert ist - etwa in der Art: 

public static final int subjectArea = Entitlement.AREA_GLOBAL_ADMINISTRATION;
Wenn dies wie hier der Fall ist, dann weiß das Framework, dass dieser Dialog (dieses Anwendungsgebiet) der "subArea"-Stufe "99" angehört. (so vereinbart in der Klasse "Entitlement"). Das genügt an sich, um diesen Dialog vor einem unberechtigten Anwender zu verbergen, sofern in der Klasse "Entitlement" dies entsprechend reglementiert wird.
 
 
Klasse "Entitlement"

Die Reglementierung erfolgt in der Klasse "Entitlement".
 
Sie müssen nun in der Methode "getLevel()" der Klasse "Entitlement" dafür sorgen, dass an das Framework der zur Benutzergruppe passende Level zurückgegeben wird. Beispiel aus dem Demoprogramm "cookbook":
//Der Methode "getLevel()" wird vom Framework die "subjectArea" des vom Benutzer angeforderten Anwendungsgebiets übergeben
  public int getLevel(int subjectArea) {
    //Wenn die "subjectArea" 90 oder größer ist
    if (subjectArea >= 90) {
      //Wenn der angemeldete Benutzer unbekannt ist, dann gib den Level LEVEL_NOTHING zurück
      if (sessionData.loggedInUser == null) return LEVEL_NOTHING;
      //Wenn die Benutzergruppe des angemeldeten Benutzers unbekannt ist, dann gib den Level LEVEL_NOTHING zurück
      if (sessionData.loggedInUser.getUserGroup() == null) return LEVEL_NOTHING;
      //Wenn der angemeldete Benutzer zwar bekannt ist, aber die Benutzergruppe des Benutzers nicht "9" ist, dann gib den Level LEVEL_NOTHING zurück
      if (!sessionData.loggedInUser.getUserGroup().equals("9")) return LEVEL_NOTHING;
    }
    String userGroup;
    //Wenn die "subjectArea" kleiner als 90 ist, dann werden diese Anweisungen ausgeführt
    //Wenn der angemeldete Benutzer unbekannt ist oder die Gruppe des angemeldeten Benutzers unbekannt ist, dann ist die Benutzergruppe gleich "0"
    if (sessionData.loggedInUser == null || (userGroup = sessionData.loggedInUser.getUserGroup()) == null) userGroup = "0";
    //Wenn die "subjectArea" 15 ist, dann führe folgende Anweisungen aus
    if (subjectArea == Entitlement.AREA_COOKBOOK_ORGANIZATION) {
      //Wenn die Benutzergruppe "9" ist, dann gib darf der Benutzer alles tun
      if (userGroup.equals("9")) return LEVEL_ALL;
      //Wenn die Benutzergruppe "5" ist, dann darf der Benutzer Datensätze löschen
      if (userGroup.equals("5")) return LEVEL_DELETE;
      //Wenn die Benutzergruppe "2" ist, dann darf der Benutzer nur Daten ansehen
      if (userGroup.equals("2")) return LEVEL_VIEW;
      //Wenn die Benutzergruppe "1" ist, dann darf der Benutzer nur Daten ansehen
      if (userGroup.equals("1")) return LEVEL_VIEW;
      //Alle anderen Benutzergruppen dürfen nichts machen
      return LEVEL_NOTHING;
    }
    //Bei allen anderen Anwendungsgebieten ("subjectArea"-Werten) gilt dies
    //Wenn die Benutzergruppe "9" ist, dann gib darf der Benutzer alles tun
    if (userGroup.equals("9")) return LEVEL_ALL;
    //Wenn die Benutzergruppe "5" ist, dann darf der Benutzer Datensätze löschen
    if (userGroup.equals("5")) return LEVEL_DELETE;
    //Wenn die Benutzergruppe "2" ist, dann darf der Benutzer Datensätze löschen
    if (userGroup.equals("2")) return LEVEL_DELETE;
    //Wenn die Benutzergruppe "1" ist, dann darf der Benutzer nur Daten ansehen
    if (userGroup.equals("1")) return LEVEL_VIEW;
    //Alle anderen Benutzergruppen dürfen die Daten nur ansehen
    return LEVEL_VIEW;
}
Genauso verhält es sich auch mit Menüs. Der Konstruktor der Superklasse "MustMenu" verlangt zum Beispiel im Konstruktor die Angabe der "subjectArea", damit das Framework weiß, ob das Menü dem Anwender gezeigt werden darf oder nicht. Außerdem kann im Konstruktor eines Menüs noch der minimale Level (minimumLevel) angegeben werden, bei welchem das Menü noch angezeigt werden darf. Auf diese Weise könnte man z.B. "Unteradministratoren" einführen, die zwar eine bestimmte Klasse wie z.B. "DataPropertyAdministration" aufrufen können, aber dort nur Daten ändern dürfen, weil deren in der Klasse "Entitlement" zugestandener Level nur LEVEL_CHANGE ist.
Folgende Level kennt das Framework:
  • LEVEL_NOTHING – der Benutzer darf nichts
  • LEVEL_VIEW – der Benutzer darf die Daten nur ansehen
  • LEVEL_ADD – Der Benutzer darf nur Datensätze aufnehmen, aber keine ändern oder löschen
  • LEVEL_CHANGE – der Benutzer darf Daten ändern
  • LEVEL_DELETE – der Benutzer darf Datensätze löschen
  • LEVEL_ALL – der Benutzer darf uneingeschränkt alles. Der Administrator sozusagen.
    • Man muss sich das nun so vorstellen, dass das Framework die Klasse "Entitlement" mittels der abstrakten Methode "getLevel()" befragt: "Darf ich dem Benutzer XY das Menü/den Dialog zeigen?". Die Klasse liefert daraufhin anhand der Gruppenzugehörigkeit den Level zurück. Nun weiß das Framework, welche Funktionen dem Anwender angeboten werden dürfen.

    Autor: Gunter Koch, 08.03.02