<attributeMapping>

Wenn Sie einen Verzeichnisdienst als Datenquelle für Ihre benutzerbezogenen Daten verwenden, müssen Sie die von der Java Application Programming Interface (API) der User Management Engine (UME) verwendeten Namen der logischen Attribute den im Schema Ihres Unternehmensverzeichnisdienstes verwendeten Namen der physischen Attribute zuordnen.

In den mit der UME ausgelieferten vorkonfigurierten Dateien sind die logischen Attribute der Java-User-Management-API den für die Objektklasse inetOrgPerson verwendeten physischen Attributen im X.500-Standard zugeordnet. Wenn Sie diesen Standard ohne Änderungen einsetzen, müssen Sie die Attributzuordnungsdaten nicht ändern. Wenn Sie diese Objektklasse in Ihrem Verzeichnisdienst erweitert haben oder eine andere Objektklasse verwenden, können Sie den Attributzuordnungsdaten weitere Attribute hinzufügen oder die Attributzuordnungsdaten nach Bedarf ändern. Da die UME Ihnen die Möglichkeiten zum Zuordnen von Attributen bietet, können Sie ein beliebiges Schema verwenden, das den Anforderungen Ihres Unternehmens entspricht.

Folgende Beispiele veranschaulichen Szenarien, in denen Sie die Attributzuordnungsdaten ändern müssen:

Tipp

Das von der Benutzerverwaltungskomponente verwendete logische Attribut für die E-Mail-Adresse eines Benutzers ist email, doch das physische Attribut im Schema für Ihr LDAP-Unternehmensverzeichnis heißt mail. Sie müssen in der Datenquellen-Konfigurationsdatei email zu mail zuordnen.

Tipp

In Ihrem Unternehmen möchten Sie, dass sich Benutzer mit ihrer E-Mail-Adresse und ihrem Kennwort statt mit ihrer Anmelde-ID und ihrem Kennwort anmelden. Im Benutzerkonto definiert das logische Attribut j_user die Anmelde-ID. Dieses Attribut ist standardmäßig der eindeutigen ID (uid) eines Benutzers zugeordnet. Durch das Zuordnen von j_user zum physischen Attribut für die E-Mail-Adresse des Benutzers, z.B. mail, können sich Benutzer in Zukunft mit ihrer E-Mail-Adresse anmelden.

Weitere Informationen finden Sie unter Logische Attribute.

Beispiel

<dataSources>
...
...
<dataSource id="CORP_LDAP"
    className="com.sap.security.core.persistence.datasource.imp.LDAPPersistence"
    isReadonly="false"
    isPrimary="true">
  ...
  <responsibleFor>
    <principal type="account">
    ...
    </principal>
    <principal type="user">
      <nameSpace name="com.sap.security.core.usermanagement">
        <attributes>
          <attribute name="firstname" populateInitially="true"/>
          <attribute name="displayname" populateInitially="true"/>
          <attribute name="lastname" populateInitially="true"/>
          <attribute name="fax"/>
          <attribute name="email"/>
          <attribute name="title"/>
          <attribute name="department"/>
          <attribute name="description"/>
          <attribute name="mobile"/>
          <attribute name="telephone"/>
          <attribute name="streetaddress"/>
          <attribute name="uniquename" populateInitially="true"/>
        </attributes>
      </nameSpace>
      ...
    </principal>
      <principal type="group">
      ...
      </principal>
  </responsibleFor>

  <attributeMapping>
    <principals>
      <principal type="account">
      ...
      </principal>
      <principal type="user">
        <nameSpace name="com.sap.security.core.usermanagement">
          <attributes>
            <attribute name="firstname">
              <physicalAttribute name="givenname"/>
            </attribute>
            <attribute name="displayname">
              <physicalAttribute name="displayname"/>
            </attribute>
            <attribute name="lastname">
              <physicalAttribute name="sn"/>
            </attribute>
            <attribute name="fax">
              <physicalAttribute name="facsimiletelephonenumber"/>
            </attribute>
            <attribute name="uniquename">
              <physicalAttribute name="uid"/>
            </attribute>
            <attribute name="loginid">
              <physicalAttribute name="*null*"/>
            </attribute>
            <attribute name="email">
              <physicalAttribute name="mail"/>
            </attribute>
            <attribute name="mobile">
              <physicalAttribute name="mobile"/>
            </attribute>
            <attribute name="telephone">
              <physicalAttribute name="telephonenumber"/>
            </attribute>
            <attribute name="department">
              <physicalAttribute name="ou"/>
            </attribute>
            <attribute name="description">
              <physicalAttribute name="description"/>
            </attribute>
            <attribute name="streetadress">
              <physicalAttribute name="postaladdress"/>
            </attribute>
            <attribute name="pobox">
              <physicalAttribute name="postofficebox"/>
            </attribute>
          </attributes>
        </nameSpace>
        ...
      </principal>
      <principal type="group">
      ...
      </principal>
    </principals>
  </attributeMapping>

</dataSources>

Im obigen Beispiel enthält der Abschnitt der Datenquelle CORP_LDAP alle Konfigurationsdaten für das LDAP-Verzeichnis.

Der Abschnitt zu <responsibleFor> definiert, welche Daten im LDAP-Verzeichnis abgelegt werden und insbesondere die logischen Attribute, die im Verzeichnis abgelegt werden. Für jedes hier aufgeführte Attribut muss ein Eintrag im Attributzuordnungsabschnitt vorliegen.

Der Abschnitt zu <attributeMapping> enthält standardmäßig Attributzuordnungsdaten für die Objektklasse inetOrgPerson im X.500-Standard. Hier können Sie den physicalAttribute-Namen (Attributname im LDAP-Verzeichnis) ändern oder können eine weitere Attributzuordnung für Attribute außerhalb von inetOrgPerson anlegen, die Sie Ihrem LDAP-Schema hinzugefügt haben.

<attribute name="firstname">
        <physicalAttribute name="givenname"/>
    </attribute>

Selbst wenn der Name des physischen und des logischen Attributs identisch ist, sollten sie diese einander zuordnen. Im obigen Beispiel wurde displayname zu displayname zugeordnet.

Attribute müssen zugeordnet werden, damit die API auf diese Daten zugreifen kann.

Einige logische Attribute sind "* null* " zugeordnet. Dies bedeutet, dass die API dieses logische Attribut verwendet, das logische Attribut jedoch keinem physischen Attribut zugeordnet ist. Es ist stattdessen einem errechneten Wert zugeordnet.

Hinweis

Stellen Sie sicher, dass alle inetOrgPersons in Ihrem LDAP-Verzeichnis einen gültigen Wert für das Attribut uid enthalten. In der Standardkonfiguration wird dieses Attribut für die Suche nach Benutzern verwendet, die in Benutzerverwaltungsanwendungen wie dem Rollenzuordnungswerkzeug angezeigt werden sollen.

Alternativ können Sie die Attributzuordnung so ändern, dass uniquename zu cn statt uid zugeordnet ist.

<attribute name="uniquename">
        <physicalAttribute name="cn"/>
    </attribute>

Dadurch wird cn für die Suche nach Benutzern verwendet, die in Benutzerverwaltungsanwendungen angezeigt werden sollen.

Namensräume

Ein weitere hilfreiche Funktion ist, dass Sie logische Attribute verschiedenen physischen Attributen in Abhängigkeit vom Namensraum zuordnen können. Beispiel: Eine Anwendung im Namensraum com.mycompany.app1 verwendet das physische Attribut uid als displayname, während eine andere Anwendung com.mycompany.app2 das physische Attribut sn als displayname verwendet. Dies wäre folgendermaßen zugeordnet:

 <attributeMapping>
    <principals>
      <principal type="user">
        <nameSpace name="com.mycompany.app1">
          <attributes>
            <attribute name="displayname">
              <physicalAttribute name="uid"/>
            </attribute>
          </attributes>
        </nameSpace>
        <nameSpace name="com.mycompany.app2">
          <attributes>
            <attribute name="displayname">
              <physicalAttribute name="sn"/>
            </attribute>
          </attributes>
        </nameSpace>
        ...
      </principal>
    </principals>
  </attributeMapping>

Erwägungen für die Attributzuordnung

Wenn die UME für ein LDAP-Verzeichnis als Datenquelle konfiguriert ist, werden nicht alle Attribute standardmäßig im LDAP abgelegt. Einige Attribute werden in der Datenbank des AS Java abgelegt. Das stellt für Sie als Systemadministrator ein Problem dar. Da diese Daten in einzelnen Systemen abgelegt sind, müssen Sie die Daten über alle Systeme hinweg synchronisiert halten. Folgende Tabelle listet die Optionen für das Zuordnen von Attributen auf.

Optionen für das Zuordnen von Attributen

Option	Vorteil	Nachteil
Attribute in den einzelnen Systemen belassen	Sie müssen nichts mehr konfigurieren.	Sie können die Daten nicht zentral verwalten. Dies ist in Ordnung, wenn Sie nicht über zu viele Systeme verfügen. Über je mehr Systeme Sie verfügen, desto mehr Aufwand ist bei der Synchronisation der Daten erforderlich.
Eigenschaften einem bestehenden Attribut zuordnen	Sie können das Attribut zentral im LDAP verwalten.	Das Datenformat des Attributs muss für jedes System übereinstimmen, dass die Daten liest. Alle Systeme, die in diesem Attribut schreiben, müssen dies im richtigen Format tun. Der AS Java unterstützt Gebietsschemata, die aus dem Sprachcode ISO 639-1 und dem optionalen Landescode ISO 3166 bestehen und durch einen Unterstrich (`_`) getrennt sind. Wenn Sie dieses Attribut dem Attribut zur bevorzugten Sprache im LDAP zuordnen, muss dieses Attribut dieses Format verwenden. Wenn ein anderes System `English` in das LDAP-Attribut zur bevorzugten Sprache schreibt, kann der AS Java diesen Wert nicht interpretieren, da dies nicht dem erforderlichen Datenformat entspricht. Weitere Informationen finden Sie unter UME-Datenquellen-Konfiguration anpassen.
LDAP-Schema erweitern	Sie können das Attribut zentral im LDAP verwalten.	Zum Erweitern des LDAP-Schemas müssen Sie ein Entwicklungsprojekt implementieren, um Ihrem LDAP neue physische Attribute hinzuzufügen und die den logischen Attributen des AS Java zuzuordnen. Sie müssen diese kundenspezifische Entwicklung auch unterstützen. Dies gilt auch dafür, sicherzustellen, dass das Datenformat des Attributs in allen System wie oben beschrieben konsistent bleibt. Weitere Informationen über das Erweitern eines LDAP-Schemas finden Sie in der Dokumentation Ihres LDAP-Herstellers.

Option

Vorteil

Nachteil

Attribute in den einzelnen Systemen belassen

Sie müssen nichts mehr konfigurieren.

Sie können die Daten nicht zentral verwalten. Dies ist in Ordnung, wenn Sie nicht über zu viele Systeme verfügen. Über je mehr Systeme Sie verfügen, desto mehr Aufwand ist bei der Synchronisation der Daten erforderlich.

Eigenschaften einem bestehenden Attribut zuordnen

Sie können das Attribut zentral im LDAP verwalten.

Das Datenformat des Attributs muss für jedes System übereinstimmen, dass die Daten liest. Alle Systeme, die in diesem Attribut schreiben, müssen dies im richtigen Format tun.

Der AS Java unterstützt Gebietsschemata, die aus dem Sprachcode ISO 639-1 und dem optionalen Landescode ISO 3166 bestehen und durch einen Unterstrich (_) getrennt sind. Wenn Sie dieses Attribut dem Attribut zur bevorzugten Sprache im LDAP zuordnen, muss dieses Attribut dieses Format verwenden. Wenn ein anderes System English in das LDAP-Attribut zur bevorzugten Sprache schreibt, kann der AS Java diesen Wert nicht interpretieren, da dies nicht dem erforderlichen Datenformat entspricht.

Weitere Informationen finden Sie unter UME-Datenquellen-Konfiguration anpassen.

LDAP-Schema erweitern

Sie können das Attribut zentral im LDAP verwalten.

Zum Erweitern des LDAP-Schemas müssen Sie ein Entwicklungsprojekt implementieren, um Ihrem LDAP neue physische Attribute hinzuzufügen und die den logischen Attributen des AS Java zuzuordnen. Sie müssen diese kundenspezifische Entwicklung auch unterstützen. Dies gilt auch dafür, sicherzustellen, dass das Datenformat des Attributs in allen System wie oben beschrieben konsistent bleibt. Weitere Informationen über das Erweitern eines LDAP-Schemas finden Sie in der Dokumentation Ihres LDAP-Herstellers.

Folgende Liste enthält bedeutende Attribute oder Gruppen von Attributen, die in der Datenbank des AS Java abgelegt werden.

Zeitzone und Gebietsschema
Barrierefreiheitsstufe
Adressattribute
Sicherheitskonzeptattribute

Zeitzone und Gebietsschema

Die Java-basierten Attribute Zeitzone und Gebietsschema verfügen nicht immer über ein geeignetes physisches Attribut im LDAP-Verzeichnis. Das LDAP-Verzeichnis unterstützt möglicherweise nicht das vom AS Java verwendete Format oder ist nicht vorhanden. Wenn Sie diese Attribute nicht in allen Systemen konsistent halten, kann dies zu unerwünschtem Verhalten führen, z.B. dass ein Benutzer für eine Sprache oder Zeitzone in einem Frontend-System und für eine andere Sprache oder Zeitzone im Backend-System konfiguriert ist. Dies kann dazu führen, dass der Benutzer vom Backend-System eine E-Mail in einer Sprache erhält, die er nicht versteht, oder in einer anderen Zeitzone, was verwirrend sein kann.

Barrierefreiheitsstufe

Dieses Attribut benachrichtigt SAP-Anwendungen über Benutzer, die beispielsweise zusätzliche Audiounterstützung für Screenreader benötigen. Alle Systeme, die SAP-Anwendungen deployen, benötigen dieses Attribut zur Unterstützung von Benutzern mit besonderen Anforderungen.

Weitere Informationen finden Sie in der Dokumentation zur Barrierefreiheit.

Adressattribute

Entsprechend dem inetOrgPerson-Standard sind alle Adressdaten in im Attribut "streetaddress" enthalten. Wenn Sie Ihr LDAP als schreibgeschützte Datenquelle verwenden, werden alle diese Daten im Attribut "streetaddress" abgelegt. Wenn Sie Ihr LDAP als Datenquelle mit Lese-/Schreibzugriff verwenden, werden beim Schreiben in das LDAP nur im Attribut "streetaddress" enthaltene Daten in das LDAP geschrieben. Andere Adressattribute wie city oder zip werden in die Datenbank des AS Java geschrieben. Sie müssen wissen, wohin der AS Java diese Daten schreibt, insbesondere dann, wenn andere Systeme diese Informationen benötigen.

Tipp

Wenn Sie Selbstverwaltung in einem System mit Schreibzugriff auf Ihr LDAP aktivieren, müssen Ihre Benutzer möglicherweise die Stadt und die Postleitzahl aus ihrer Adresse entfernen und sie in die Attribute "city" und "zip" eingeben. Dadurch ist das Attribut "streetaddress" im LDAP für andere Systeme wenig hilfreich.

Sicherheitskonzeptattribut

Wenn Sie ein LDAP-Verzeichnis zur Kennwortverwaltung verwenden, ist es erstrebenswert, Attribute wie lastpasswordchange, validto und passwordhistory zentral zu verwalten. LDAP-Verzeichnisse verwenden leider proprietäre und nicht unterstützte Datenformate zum Ablegen von Informationen. Jeder LDAP-Hersteller behandelt diese Eigenschaften anders. SAP liefert keine Zuordnungen zu Sicherheitskonzeptattributen und schreibt Daten stattdessen in die Datenbank des AS Java. Diese Daten müssen dezentral gepflegt werden.

Weitere Informationen finden Sie unter Sicherheitskonzept.

Weitere Informationen:

Beispiel: Attributzuordnung für Client-Zertifikate

Beispiel: Attributzuordnung für benutzerdefinierte Attribute