GSB 7.0 Standardlösung

Springe direkt zu:

Version: GSB 7LDAP-Anbindung

Um Mandantenfähigkeit für den Government Site Builder auch im Bereich Benutzeradministration zu gewährleisten, ist es notwendig eine externe LDAP-Nutzerverwaltung einzubinden. Dies ermöglicht es, für jeden Mandanten einen separaten Benutzer „Manager“ einzurichten, der eingeschränkt auf diesen Mandanten die Administration der Benutzer übernimmt. In der Standard-Benutzerverwaltung der CoreMedia-Version 4.2 ist eine Einschränkung der Administrationsprivilegien auf bestimmte Benutzergruppen/Mandanten nicht möglich.

Es ist wichtig anzumerken, daß im LDAP-Verzeichnis lediglich Benutzerdaten, inklusive Paßwort, Login, Emailadresse, Gruppenzugehörigkeiten wie auch Gruppen inklusive ihrer Namen und Obergruppenzugehörigkeiten etc. gespeichert werden, nicht jedoch die Rechtestruktur. Dies hat zur Folge, daß einer neu angelegten Gruppe zunächst bestimmte Rechte, wie z.B. Leserechte auf dem CoreMedia Root-Ordner zugeteilt werden müssen, sofern sie keine entsprechenden Rechte von einer ihrer Obergruppen erbt. Erst danach können sich Benutzer, die dieser Gruppe zugeordnet sind anmelden bzw. auf die entsprechenden Ressourcen zugreifen.

Für die mandantenfähige Benutzerverwaltung wird eine Installation der freien Software OpenLDAP in der Version 2.1.4-x benötigt (erhältlich unter http://www.openldap.org). Für diesen LDAP-Server stellt der GSB eine Schema-Erweiterung bereit (bkcms.schema). Dieses Schema führt die beiden Objektklassen bkcmsPerson und bkcmsGroup ein, die die Gruppen und Benutzer des Mandanten modellieren. Die Java-Klasse

de.bundonline.basis.cap.ldap.BOLUserPropvider

liefert dem CoreMedia-System Zugriff auf dieses spezielle Schema und stellt Funktionen zum Abfragen von Gurppenzugehörigkeiten, Auslesen von Benutzern, Gruppen etc. bereit.

Schema

Der GSB verwendet eine angepasste Schema-Definition, die in der Datei bkcms.schema abgelegt ist. Es definiert die beiden Objektklassen bkcmsPerson und bkcmsGroup.

Eine bkcmsGroup ist von der Objektklasse top aus dem core.schema abgeleitet und enthält die folgenden zusätzlichen Attribute:

  • cn: Der Name der Gruppe
  • isAdminGroup TRUE/FALSE ist die Gruppe eine AdmnistratorGruppe (CoreMedia-Internes Attribut)
  • isContentServerGroup: TRUE/FALSE ist die Gruppe eine auf dem contentServer verfügbare Gruppe (CoreMedia-Internes Attribut)
  • isLiveServerGroup TRUE/FALSE ist die Gruppe eine auf dem Generator verfügbare Gruppe (CoreMedia-Internes Attribut)
  • group: multiples Attribut, das die Zugehörigkeit zu anderen Gruppen angibt. Es wird hier der DistinguishedName der Obergruppe registriert
  • bkcmsDN: der DistinguishedName der Gruppe; OpenLDAP speichert den DistinguishedName nicht als eigenes Attribut, daher wird dies für eine Vereinheitlichung von Suchanfragen hier separat vorgenommen.

Ein bkcmsUser ist von der Objektklasse person aus dem Standard-Schema cosine.schema abgeleitet. Es wurden die folgenden erweiterten Attribtue angelegt:

  • group: multiples Attribut, das die Zugehörigkeit zu Gruppen angibt. Es wird hier der DistinguishedName derGruppe registriert
  • mail: die Emailadrese des Users
  • bkcmsDN: der DistinguishedName des Users für vereinheiltichte Suchanfragen
  • uid: das Login des Users. Es muss innerhalb eines Mandanten eindeutig sein.
  • absent: TRUE/FALSE gibt an, ob der Benutzer gegenwärtig abwesend ist.

Konfiguration

Die Konfiguration unterteilt sich in die Konfiguration des LDAP-Servers und in die des ContentServer

Beispiel-LDAP-Verzeichnis-Struktur

Im Folgenden orientieren wir uns an einer Beispiel-Verzeichnis-Struktur. Wird eine alternative Struktur gewünscht, so sind die nachfolgenden Konfigurationen entsprechend anzupassen:

Der DistinguishedName des globalen LDAP-Administrators lautet:

cn=Manager,dc=bva,dc=bund,dc=de

Der Name des Mandanten lautet

Tests

Die Domäne des Mandanten lautet

Tests.bva.bund.de

Sämtliche LDAP-Einträge für den Mandanten werden unterhalb

BaseDN DC=Tests,DC=bva,DC=bund,DC=de

abgelegt

Der DistinguishedName des Mandanten-Administrators lautet

cn=Manager,DC=Tests,dc=bva,dc=bund,dc=de

Benutzer werden unterhalb der

BaseDN ou=Users,DC=Tests,DC=bva,DC=bund,DC=de

abgelegt

Gruppen werden unterhalb der

BaseDN ou=Groups,DC=Tests,DC=bva,DC=bund,DC=de

abgelegt

Hier eine kleine Skizze, die die Struktur verdeutlicht:

LDAP-Anbindung

OpenLDAP

Es wird davon ausgegangen, daß lauffähige Installationen eines OpenLDAP-Servers und des GSB vorhanden sind. Bei allen Pfadangaben orientieren wir uns an im Folgenden an der Pfadstruktur der mit der Version Suse Linux 8.1/8.2 mitgelieferten OpenLDAP-Version. Bei anderen Installationen wird die Struktur sehr ähnlich sein. Es muss nun die Schema-Erweiterung bkcms.schema in das Schema-Verzeichnis des LDAP-Server kopiert und in der Datei slapd.conf per Include-Direktive zusammen mit den benötigten Standard-Schema.-Definitionen registrierte werden:

include /etc/openldap/schema/core.schema

include /etc/openldap/schema/cosine.schema

include /etc/openldap/schema/bkcms.schema

Neben den Standard-Konfigurationen müssen die Zugriffsrechte die einzelnen Mandanten konfiguriert werden. Eine Beispielkonfiguration für einen Mandaten mit Namen „Tests“ in der Datei slapd.conf könnte wie folgt aussehen:


<syntaxhighlight lang="xml" enclose="div">

        1. Access-Control
  1. Schreibrechte fuer ausgewaehlte Attribute
  1. Fuer alle User selber, fuer alle Site-Administratoren und LDAP-Gesamt-Administrator

access to attr=userPassword,cn,sn,mail,telephoneNumber

           by self write
           by anonymous auth
           by dn.base="cn=Manager,dc=bva,dc=bund,dc=de" write
           by dn.base="cn=Manager,DC=Tests,dc=bva,dc=bund,dc=de" write
           by * none
  1. Tests-Mandant
  1. Schreib-/Leserechte fuer Site-Administrator UND LDAP-Gesamt-Administrator

access to dn.subtree="DC=Tests,DC=bva,DC=bund,DC=de"

by dn.base="cn=Manager,DC=Tests,dc=bva,dc=bund,dc=de" write

       by dn.base="cn=Manager,dc=bva,dc=bund,dc=de" write

by self read

by anonymous auth

access to *

   by dn.base="cn=Manager,dc=bva,dc=bund,dc=de" write
   by dn.base="cn=Manager,DC=Tests,dc=bva,dc=bund,dc=de" read
   by self read
   by anonymous auth
          1. ENDE Access-Control

</syntaxhighlight>

Es wird in diesem Fall sichergestellt, daß Benutzer ihr Paßwort, ihren Namen, Emailadresse etc. selber editieren können, nicht jedoch ihre Gruppenzugehörigkeiten im Attribut group. Dieses Attribut steht nur dem Administrator des Mandanten und dem LDAP-Gesamt-Administrator zur Verfügung. Der DistinguishedName des Gesamt-Administrators ist in diesem Fall cn=Manager,dc=bva,dc=bund,dc=de, die des Tests-Mandante-Administrators cn=Manager,DC=Tests,dc=bva,dc=bund,dc=de.

Sobald weitere Mandanten angelegt werden, müssen die Berechtigungen entsprechend angepaßt werden und z.B. der Administrator des Mandanten Schreibrechte für seine Benutzer erhalten.

GSB/CoreMedia ContentServer

Der externe LDAP-Server muß im CoreMedia-ContentServer registriert. Dies geschieht in der Datei

CONTENT_SERVER_DIR/properties/corem/capserver.properties

Hier werden für jeden per LDAP angebundenen Mandanten zwei Zeilen der Form

cap.server.ldap.N.class=de.bundonline.basis.cap.ldap.BOLUserProvider

cap.server.ldap.N.properties=properties/corem/jndi_MANDANT.properties

eingefügt, wobei N beginnend bei 1 für jeden Mandanten hochgezählt wird und MANDANT der Name des Mandanten ist. Dadurch wird eine Instanz der Klasse de.bundonline.basis.cap.ldap.BOLUserProvider, die das BKCMS-Schema kennt, auf die Besonderheiten des Mandanten hin konfiguriert. Die eigentliche Konfiguration der Klassen steht in der Datei

CONTENT_SERVER_DIR/properties/corem/ jndi_MANDANT.properties

Hier werden die folgenden Werte (beispielhaft für den Mandanten Tests) gesetzt. Sie müssen mit den Werten in slapd.conf und ldap.conf übereinstimmen

<syntaxhighlight lang="xml" enclose="div">

      1. Log configuration

log.action.1.class=StdOutAction

log.action.1.selectors=debug

log.action.2.class=FileAction

log.action.2.selectors=ldap:info

log.action.2.initArgs=file=var/logs/ldap.log

  1. Authentifisizerungs-Methode desLDAP-Server

java.naming.security.authentication=simple

  1. Root-DN des LDAP-Servers

java.naming.security.principal=cn=Manager,dc=bva,dc=bund,dc=de

  1. Passwort der Root-DN des LDAP-Servers

java.naming.security.credentials=secret

  1. Hostname des LDAP-Servers

com.coremedia.ldap.host=server.host.com

  1. Port des LDAP-Servers

com.coremedia.ldap.port=389

  1. Die Base-DNs des Tests-Mandanten, relativ zu der alle Suchanfragen des Mandanten ausgeführt werden
  1. Es hat sich als praktisch herausgestellt eine OrganizationalUnit jeweils für Gruppen (ou=Groups) und für Benutzer (ou=Users) anzulegen

com.coremedia.ldap.basedns=OU=Users,DC=Tests,dc=bva,dc=bund,DC=de;OU=Groups,DC=Tests,dc=bva,dc=bund,DC=de

  1. Cache-Erneuerungs-Intervall

com.coremedia.ldap.expiration=3600

  1. Der Domänen-Name des Mandanten, muß fuer die gesamte BKCMS-Installation eindeutig sein

com.coremedia.ldap.domains=Tests.bva.bund.de

  1. Dieser Name erscheint in der Select-Box des Java-Editors beim Login
  1. Er muß mit den zusammengesetzten Domain-Komponenten des Mandanten übereinstimmen zum Thema Domain-Komponente siehe unten

com.coremedia.ldap.domains=Tests.bva.bund.de

  1. Maximale Anzahl von Suchergebnissen

com.coremedia.ldap.searchlimit=1000

com.coremedia.ldap.ou.predicate=(objectClass=organizationalUnit)

  1. LDAP-Attribute, die dem Cap-Server zugänglich gemacht werden sollen

com.coremedia.ldap.user.attrs=cn group sn userPassword bkcmsDN uid absent

  1. Weitere LDAP-Attribute

com.coremedia.ldap.user.customattrs= uid sn cn mail telephoneNumber absent

  1. Filter für Suchanfragen für Benutzer

com.coremedia.ldap.user.filter=(objectClass=bkcmsPerson)

  1. Name-Attribut für LDAP-Benutzer

com.coremedia.ldap.user.nameattr=uid

  1. Bleibt laut CoreMedia leer

com.coremedia.ldap.user.domainattr=

  1. LDAP-weite eindeutige ID des Benutzers

com.coremedia.ldap.user.idattr=bkcmsDN

  1. LDAP-Attribute, die dem Cap-Server zugänglich gemacht werden sollen

com.coremedia.ldap.group.attrs=member group sn bkcmsDN cn isContentServerGroup isLiveGroup isAdminGroup

  1. Filter für suchanfragen für Benutzer

com.coremedia.ldap.group.filter=(objectClass=bkcmsGroup)

  1. Name-Attribut für LDAP-Gruppen

com.coremedia.ldap.group.nameattr=cn

  1. Bleibt –laut CoreMedia leer

com.coremedia.ldap.group.domainattr=

  1. LDAP-weite eindeutige ID der Gruppe

com.coremedia.ldap.group.idattr=bkcmsDN

  1. Name des isContentServer-Attributes

com.coremedia.ldap.group.isContentGroupAttr=isContentServerGroup

  1. Name des isLiveGroup-Attributes

com.coremedia.ldap.group.isLiveGroupAttr=isLiveGroup

  1. Name des isAdminGroup-Attributes

com.coremedia.ldap.group.isAdminGroupAttr=isAdminGroup </syntaxhighlight>


Als letzte Datei muß

CONTENT_SERVER_DIR/properties/corem/jaas.conf

angepaßt werden. Hier werden die folgenden Properties gesetzt:

JaasCap {

/**

* weitere Properties

*/

hox.corem.login.LdapLoginModule sufficient host=<LDAP-Server-Hostname>" port="<LDAP-Server-Port>" domain="<Domain des Mandanten in Übereinstimmung mit den Doamin-Komponenenten des LDAP-Servers (siehe unten), z.B. Tests.bva.bund.de >";

};

Domain-Komponenten

Jeder Benutzer eines Mandanten muss vor dem Login in den ContentServer in der Select-Box seine Domain auswählen. Anhand der ausgewählten Domain wird die für die Konfiguration der Instanz der Klasse de.bundonline.basis.cap.ldap.BOLUserProvider

zu benutzende jndi_MANDANT.properties Datei ausgewählt. Die so konfigurierte UserProvider-Komponente berechnet aus dem DistinguishedName eines Suchergebnisses einen Domain-Namen nach der folgenden Regel:

Die einzelnen, durch Kommata getrennte Komponenten des DistinguishedNames werden mit „.“ als Trennzeichen miteinander verbunden, wenn sie mit „dc=“ beginnen. Hierbei wird davon ausgegangen, daß alle DistinguishedNames mit einer Serie von „dc=...,dc=..“ relativer DistinguishedNames enden und daß die Komponenten „dc=“ nur am Ende des DistinguishedNames auftreten. Der so erhaltene Domain-Name muss mit den in den Dateien jaas.conf und jndi_MANDANT.properties registrierten Domainnamen des Mandanten übereinstimmen.

Beispiel:

1. Die berechnete Domäne des Eintrages mit DistinguishedName

„uid=Kevin,ou=Users,dc=Tests,dc=bva,dc=bund,dc=de“

ist „Tests.bva.bund.de“

2. Der folgende DistinguishedName ist illegal, da nach der Komponente dc=SpecialUsers nicht ausschließlich weitere dc—Komponenten folgen, sondern eben auch die auch ou=Users:

uid=Kevin,dc=SpecialUsers,ou=Users,dc=Tests,dc=bva,dc=bund,dc=de