Branding

Benutzeridentität

Für den internen Bereich (unter anderem GSB Editor und Adminportal) wurden bislang separate Benutzeridentitäten gepflegt, so dass für einen Benutzer, der sowohl im Redaktionssystem als auch im Adminportal gearbeitet hat, zwei unabhängige Benutzeridentitäten mit entsprechenden Berechtigungen gepflegt wurden.

Hierbei konnte nur die Benutzeridentität für das Redaktionssystem durch den Mandanten selbst gepflegt werden. Als  'Übergreifende Benutzeridentität' soll die für das Redaktionssystem existierende Benutzeridentität auch für eine Anmeldung am Adminportal genutzt werden können, wodurch diese Benutzeridentität zu einer übergreifenden Benutzeridentität wird. Mit Hilfe dieser übergreifenden Benutzeridentität soll es auch ermöglicht werden, dass dieser, neben Berechtigungen im CMS, auch Berechtigungen in weiteren GSB-Komponenten, wie etwa dem Adminportal zugewiesen werden können. Im Zuge der Umsetzungen wird außerdem die Funktionalität zum Archivieren der übergreifenden Benutzeridentitäten bereitgestellt.

Zur Umsetzung der Übergreifenden Benutzeridentität sind folgende Anpassungen erforderlich:

  • CAS-Server
  • CAS-Anmeldung und LDAP-Import
  • LDAP-Admin-Portlet

Die jeweils durchzuführenden Anpassungen werden in den entsprechenden Artikeln beschrieben.

Im Zuge der Einführung der übergreifenden Benutzeridentität werden den Benutzeridentitäten neben Content-Server-Gruppen auch Adminportal-Gruppen und gegebenenfalls Gruppen zur Vergabe von Berechtigungen in weiteren Drittsystemen zugeordnet.

Die Zuordnung von Gruppen, die zu unterschiedlichen Systemen gehören, soll für den Anwender des Administrationswerkzeug LDAP-Admin transparent erfolgen.

Abbildung 1 zeigt diese transparente Zuordnung am Beispiel des Benutzers. Der Benutzeridentität wurde mit der Gruppe gsbsl_Rechte_Administration eine Content-Server-Gruppe und mit den Gruppen gsbsl_solrAdmin, gsbsl_userAdmin und gsbsl_workflowAdmin drei Adminportal-Gruppen zugeordnet. LDAP-seitig werden diese Gruppen unter Nutzung eines gemeinsamen Schemas (bkcmsGroup) gespeichert, was die transparente Verwendung der Gruppen in der Benutzerverwaltung ermöglicht.

Zuordnung von Adminportal- und Content-Server-Gruppen zu einer übergreifenden Benutzeridentität Abbildung 1: Zuordnung von Adminportal- und Content-Server-Gruppen zu einer übergreifenden Benutzeridentität.

Die eigentliche Verwaltung von Gruppen unterschiedlicher Typen ist aufgrund von konzeptioneller Unterschiede zwischen den Gruppen zu trennen. Diese Trennung ist in der Gruppen-Verwaltung des LDAP-Admin-Portlets zu reflektieren.

Anpassungen und Erweiterungen

Gruppen werden zukünftig unterschiedlichen Drittsystemen zugeordnet. Es erfolgt daher eine Typisierung der Gruppen, aus der diese Zuordnung hervorgeht. Ein Beispiel für einen Gruppentyp ist die „Content-Server-Gruppe“. Zusätzlich dazu werden zukünftig Gruppen vom Typ „Adminportal-Gruppe“ und „Piwik-Gruppe“ existieren, die den entsprechenden Drittsystemen zugeordnet sind. Der Gruppentyp wird im LDAP gespeichert, wozu das Schema bkcmsGroup um das Attribut groupType erweitert wird.

Jedem Gruppentyp ist im LDAP-Admin-Portlet eine eigene Sicht auf die Gruppenverwaltung zugeordnet. Zur Erhaltung der bisherigen Funktionalität bleibt die Sicht auf Content-Server-Gruppen unverändert. Zusätzlich zu dieser werden Sichten auf Adminportal-Gruppen und Piwik-Gruppen eingeführt. Die Sichten unterscheiden sich in:

  • der Übersicht über die Gruppen (Registerkarte: Gruppe suchen),
  • der Stammdatenverwaltung und dem Dialog zum Anlegen einer neuen Gruppe,
  • und in der Regel-Verwaltung.

Die ersten beiden Unterschiede ergeben sich daraus, dass die weitere Klassifikation von Content-Server-Gruppen in „Admin“, „Content-Server“ und „Live“ für weitere Gruppentypen nicht erforderlich ist und daher die Anzeige und Auswahl dieser Parameter entfällt. Die Unterschiede in der Regel-Verwaltung ergeben sich dadurch, dass die bisherige Regel-Verwaltung auf die Vergabe von Berechtigungen im CMS zugeschnitten ist. Zukünftig wird in Abhängigkeit des Typs der Gruppe eine jeweils auf das Drittsystem angepasste Ansicht von Regeln (Berechtigungen) angezeigt (in der Abbildung 2, gelb-umrandeter Bereich). Dies ist erforderlich, um auf die Spezifika des angebundenen Systems einzugehen (bspw. Vergabe von Berechtigungen im CMS für Content-Server-Gruppen vs. Vergabe von Berechtigungen auf Liferay-Seiten für Adminportal-Gruppen).

Bereich der Gruppen-Typ-abhängigen Regel-Verwaltung Abbildung 2: Bereich der Gruppen-Typ-abhängigen Regel-Verwaltung

Die Auswahl des aktuell angezeigten Gruppentyps und der damit assoziierten Sicht erfolgt über eine Drop-Down-Box im oberen Bereich des Portlets. Die Abbildung 3 zeigt die Auswahl für Content-Server-Gruppen.

Auswahl des Gruppentyps (Skizze) Abbildung 3: Auswahl des Gruppentyps (Skizze)

Innerhalb einer Sicht werden ausschließlich die Gruppen eines bestimmten Typs dargestellt. Dies wirkt sich auf die Übersicht über alle Gruppen und auf sämtliche Hierarchiedarstellungen aus. Die Abbildung 4 zeigt eine mögliche Darstellung der Gruppen-Hierarchie für den Gruppen-Typ Adminportal. Es ist zu erkennen, dass in dieser Sicht ausschließlich Gruppen vom Typ Adminportal angezeigt werden.

Darstellung der Hierarchie bei der Auswahl des Gruppentyps "Adminportal" (Skizze) Abbildung 4: Darstellung der Hierarchie bei der Auswahl des Gruppentyps "Adminportal" (Skizze).

Technische Umsetzung

Um die Zuordnung von Gruppen zu Gruppen-Typen zu reflektieren, wird das Model-Element „Group“ zur internen Repräsentation von Gruppen um das Attribut GroupType erweitert. Die verfügbaren Gruppen-Typen werden durch die Klasse GroupTypeDAO bereitgestellt. Zu einem Gruppen-Typ werden die zusätzlich zu administrierenden Stammdaten in einer generischen Map als Key-Value-Paare gespeichert.

Die DAO-Klassen, die den Zugriff auf Gruppen im LDAP-Server kapseln, werden um einen Filter erweitert, der das Abrufen von Gruppen eines bestimmten Gruppentyps ermöglicht. Außerdem ordnen die DAO-Methoden den instanziierten Gruppen gleichzeitig  dem entsprechenden Gruppentyp als Instanz der Klasse GroupType zu.

Für die Auswahl des Gruppentyps in der Benutzeroberfläche wird eine JSF-Bean GroupTypeSelection angelegt. Die Bean steuert die korrekte Anzeige des aktuell ausgewählten Gruppentyps und löst das Ereignis EventGroupTypeChanged aus, wenn der Gruppentyp geändert wird. Die den Views zugeordneten Controller (Beans) reagieren auf dieses Ereignis, indem diese die Liste der angezeigten Gruppen anhand der aktuellen Gruppen-Typ-Auswahl aktualisieren.

Der Controller zur Steuerung der Stammdaten-View wird so angepasst, dass er die administrierbaren Stammdaten zu einer Gruppe aus dem jeweiligen Gruppentyp ableitet und der View zur Verfügung stellt. Die View rendert die so ermittelten Stammdaten, wobei zurzeit nur boolsche Stammdaten berücksichtigt werden, die (so wie bislang isContentServerGroup, etc.) als „schaltbare Checkboxen“ dargestellt werden.

Die Ausgabe der administrierbaren Stammdaten einer Gruppe erfolgt zusätzlich auch in der tabellarischen Darstellung innerhalb der View „Gruppe Suchen“. Die Spalten der angezeigten Tabelle waren bislang statisch in der View codiert (z.B. Anzeige der Spalte „Content-Server Gruppe“). Da die Anzeige der Spalten allerdings in Abhängigkeit des ausgewählten Gruppentyps variiert, müssen die Spalten dynamisch generiert werden. Die entsprechende Logik ist im Controller implementiert, der der View „Gruppe Suchen“ zugeordnet ist (GroupSearchBean).

Die Regel-Verwaltung für Gruppen war bislang auf die Verwaltung von Content-Server-Gruppen und damit auf die Vergabe von Berechtigungen im Content eingeschränkt. Die Oberflächenlogik (View und Controller) zur Verwaltung der Content-Server-Regeln wurde aus der View „Regeln“ und dem dazu zugehörigen Controller extrahiert. Die entsprechenden Oberflächenkomponenten (Übersicht über die zugeordneten Content-Server-Regeln und die Dialoge zum Hinzufügen/Bearbeiten dieser Regeln) werden jetzt nur noch dann angezeigt, wenn der Gruppen-Typ CONTENT-SERVER ausgewählt ist. Die Extraktion der entsprechenden Klassen und deren Organisation in der Paket-Struktur des Portlets werden bei Rollen- und Rechteverwaltung genauer beschrieben.

Für Adminportal-Gruppen wird im Rahmen dieses Arbeitspakets keine dedizierte Regelverwaltung umgesetzt. Dies ist ebenfalls Gegenstand von Rollen und Rechteverwaltung und wird dort beschrieben.