Branding

CAS-Anmeldung und LDAP-Import

Das CAS-Anmeldemechanismus im Liferay und der daran anschließende LDAP-Import von Benutzern aus dem LDAP sind an die Anforderungen der Übergreifenden Benutzeridentität anzupassen.

Nachdem ein Benutzer (mit gültigem CAS-Ticket) erstmals auf das Adminportal zugreift, wird dieser von dem zugrundeliegenden CAS-Mechanismus im Liferay automatisch angemeldet. Während der Anmeldung werden die Informationen zu der Benutzeridentität mit dem LDAP-Server abgeglichen und diese beim Vorliegen etwaigen Änderungen im Liferay aktualisiert, bzw. der Benutzer wird im Liferay neu angelegt, falls dieser bislang noch nicht existiert.

Das dem Adminportal zugrundliegende Liferay-Portal stellt relativ restriktive Anforderungen an die Beschaffenheit von möglichen Benutzernamen. Unter anderem sind die folgenden Zeichen nicht als Bestandteil eines Benutzernamens erlaubt: „@“, „.“, „/“, „&“. Weitere Informationen zu den tatsächlichen Anforderungen an einen möglichen Benutzernamen können der Liferay-Dokumentation entnommen werden, die unter folgenden URL aufgerufen werden kann:

https://web.liferay.com/de/community/wiki/-/wiki/Main/Liferay+Users+and+Screennames

Anpassungen und Erweiterungen

In der Liferay-Benutzerverwaltung existieren keine Organisationskonstrukte wie Organisationseinheiten oder Domänen, mit denen das LDAP-Mandanten-Konzept nachgebildet werden kann.

Aus dem bereits geschilderten Problem, dass prinzipiell zwei oder mehr Benutzeridentitäten mit einer identischen Benutzerkennung in zwei oder mehreren unterschiedlichen Mandanten existieren können, ergibt sich die Anforderung, dass auch die Mandanten-Information zusätzlich in der Benutzerkennung innerhalb des Liferays gespeichert werden muss, um auch hier eine eindeutige Zuordnung von Benutzerkennungen zu Benutzeridentitäten zu ermöglichen.

Die Mandanten-Information wurde bereits bei der CAS-Anmeldung als Suffix mit vorangestelltem „@“-Zeichen an den Benutzernamen angehangen. Der so erweiterte und somit eindeutige Benutzername wird als Liferay-Benutzername verwendet. Allerdings führt das enthaltene @-Zeichen dazu, dass der Benutzername vom Liferay zurückgewiesen wird, da per Konvention Benutzerkennungen im Liferay kein @-Zeichen enthalten dürfen. Aus diesem Grund wird der mit dem CAS-Ticket assoziierte Benutzername zusätzlich transformiert, wobei alle @-Zeichen im Benutzernamen durch eine konfigurierbare Zeichenkette ersetzt werden. Dieser Ansatz ermöglicht unter anderem auch, das prinzipiell E-Mail-Adresse als Benutzernamen verwendet werden können, solange innerhalb der E-Mail-Adresse keine weiteren Zeichen enthalten sind, die vom Liferay nicht akzeptiert werden. Der Benutzername „max.mustermann@example.com“ innerhalb des Mandanten „gsbsl“ wird im Liferay dementsprechend als „max.mustermann_AT_example.com_AT_gsbsl“ angelegt, wenn „_AT_“ als ersetzende Zeichenkette für das @-Zeichen konfiguriert ist.

Im Zuge der Anpassung des LDAP-Imports werden auch die einer Benutzeridentität zugeordneten Gruppen aus dem LDAP importiert. Die Gruppenzuordnung soll zukünftig genutzt werden, um den übergreifenden Benutzeridentitäten auch Berechtigungen im Adminportal zuzuordnen. Folglich ist festzulegen, auf welches Liferay-Konstrukt die LDAP-Gruppen abgebildet werden sollen.

Berechtigungen können im Liferay ausschließlich an Rollen oder Site-Teams vergeben werden, nicht aber direkt an Benutzer. Sowohl Site-Teams als auch Rollen werden einerseits Berechtigungen zugeordnet und andererseits Benutzer. Die effektiven Berechtigungen eines Benutzers ergeben sich aus der Vereinigung der Berechtigungen aller Rollen und Site-Teams, die dem Benutzer zugeordnet sind. Die Konstrukte Rollen und Site-Teams unterscheiden sich in der Sichtbarkeit innerhalb des Liferay-Portals. Ein Site-Team ist nur innerhalb einer Site (d.h. innerhalb eines Mandanten) sichtbar, während eine Rolle systemweit sichtbar ist. Um es Mandanten zu ermöglichen, unabhängig von anderen Mandanten eine eigene Berechtigungsstruktur zu etablieren, werden zur Abbildung von Berechtigungen im Adminportal Site-Teams verwendet.  

Der LDAP-Import wird dementsprechend so angepasst, dass zusätzlich zu den Informationen zu einer Benutzeridentität auch die der Benutzeridentität zugeordneten Gruppen importiert werden. Die LDAP-Gruppen werden dabei durch Namensgleichheit auf entsprechende Site-Teams abgebildet. Da der vorhandene Liferay-LDAP-Import nicht ausreichend flexibel ist, wird parallel dazu ein eigener LDAP-Import-Mechanismus geschaffen.

Technische Umsetzung

Die wesentliche Logik ist in der Methode login implementiert. Das Diagramm in Abbildung 1 zeigt den Ablauf der Methode.

Nachdem das CAS-Ticket erfolgreich validiert wurde, wird zunächst die mit dem CAS-Ticket assoziierte Benutzerkennung in die eigentliche Benutzerkennung und der Mandanten-information aufgespalten und in die Liferay-Repräsentation transformiert. Anschließend wird überprüft, ob der Benutzer bereits im Liferay vorhanden ist.

  • Falls ja, werden die im Liferay hinterlegten Benutzerinformationen mit den Informationen im LDAP verglichen und bei Bedarf im Liferay aktualisiert.
  • Falls der Benutzer noch nicht im Liferay vorhanden ist, wird der Benutzer angelegt.

 Im Anschluss hieran wird überprüft, ob das „absent-Flag“ des Benutzers gesetzt ist. Das Flag zeigt an, dass die Benutzeridentität archiviert ist. Falls das Flag gesetzt ist, wird die Anmeldung des Benutzers verweigert und der Anmeldevorgang am Liferay abgebrochen.

Abschließend werden die der Benutzeridentität zugeordneten Benutzergruppen synchronisiert. Dazu werden die zugeordneten LDAP-Gruppen vom Typ „ADMINPORTAL“ (das sind Gruppen, denen zukünftig Berechtigungen für das Adminportal zugeordnet werden) aus dem LDAP-Server abgerufen, sämtliche Vorfahren (übergeordnete Gruppen) dieser Gruppen berechnet und diese ebenfalls aus dem LDAP abgerufen.

Die Menge der direkt zugeordneten Gruppen zusammen mit sämtlichen Vorfahren dieser Gruppen entspricht der Menge der „effektiv zugeordneten Gruppen“. Für jede dieser effektiv zugeordneten Gruppen wird eine Zuordnung zu einem Site-Team im Liferay vorgenommen, wobei eine Namensgleichheit zwischen LDAP-Gruppe und Site-Team zugrunde gelegt wird. Falls ein Site-Team nicht existiert, wird dieses angelegt. Letztlich wird die Benutzeridentität aus allen Site-Teams entfernt, zu denen es keine korrespondierende LDAP-Gruppe in der Menge der effektiv zugeordneten Gruppen gibt. Im Ergebnis sind dem Benutzer im Liferay exakt die Site-Teams zugeordnet, die der Menge der effektiv zugeordneten LDAP-Gruppen vom Typ ADMINPORTAL entsprechen, die der korrespondierenden Übergreifenden Benutzeridentität im LDAP zugeordnet sind.

Ablauf der Login-Methode Abbildung 1: Ablauf der Login-Methode

Die bei der Transformation des Benutzernamens zur Ersetzung des @-Zeichens verwendete Zeichenkette wird mit der Property de.bund.gsb.adminportal.login .ldap.liferayUserCustomerDivider in der Datei portal-ext.properties konfiguriert, wobei als Standardwert -at- verwendet wird, falls die Property nicht explizit konfiguriert ist.

Gruppen werden im LDAP typisiert, um sie eindeutig einem bestimmten System (bspw. Adminportal oder Content-Server) zuzuordnen. Um die Typisierung von LDAP-Gruppen im LDAP-Server zu reflektieren, wird eine Erweiterung des existierenden LDAP-Schemas bkcmsGroup vorgenommen. In diesem wird das Attribut groupType vom Typ String aufgenommen. Für Adminportal-Gruppen ist als Wert 'ADMINPORTAL' für dieses Attribut einzutragen (vergleiche Import-Mechanismus weiter oben). Um Content-Server-Gruppen von Adminportal-Gruppen zu unterscheiden, sind diese jeweils mit dem Typ JCR-CONTENT-SERVER für den GSBOS bzw. CM-CONTENT-SERVER für den GSBCM zu versehen. Die hier vorgenommene Typisierung von Gruppen hat auch einen wesentlichen Einfluss auf die Steuerung der Rechtevergabe, die im Arbeitspaket AP06-A2.4W beschrieben wird.

Die Verbindung zum LDAP-Server sowie die Abstraktion der LDAP-Kommunikation sind in der Klasse LDAPConnector implementiert. Die Konfiguration der LDAP-Verbindung erfolgt durch die folgenden Properties (vgl. Betriebsdokumentation):

  • Hostname: bund.gsb.adminportal.login.ldap.host
  • Benutzername: bund.gsb.adminportal.login.ldap.bindDn
  • Password: bund.gsb.adminportal.login.ldap.bindPassword