Dieser Abschnitt enthält neue und berichtigte Informationen für das Handbuch Sun Identity Manager Deployment Guide.
Im Abschnitt Adding Localization Support for the WIC in Sun Identity Manager Deployment Guide wird beschrieben, wie Exportschema-Strings auf der Seite „Data Exporter-Typkonfiguration“ in eine andere Sprache übersetzt werden. Die Anweisungen sollten jedoch einen Hinweis enthalten, dass diese Schritte nur von Kunden durchgeführt werden müssen, die keine der offiziell unterstützten Sprachen verwenden. Die offiziell unterstützten Sprachen sind Vereinfachtes Chinesisch, Traditionelles Chinesisch, Koreanisch, Japanisch, Deutsch, Spanisch, Französisch, Italienisch und Portugiesisch (Brasilien). (ID-19264)
Eine JAR-Lokalisierungsdatei, die in einer lokalisierten WICMessages.properties-Datei enthalten ist, wird mit Identity Manager 8.1 ausgeliefert. Wenn Sie ein lokalisiertes Identity Manager-System verwenden, können Sie lokalisierte WICMessages.properties-Meldungen anzeigen. Beispielsweise können Sie mit lang=ja auf die URL für die Identity Manager Administratorbenutzeroberfläche in einem Browser zugreifen.
Das in diesem Abschnitt verwendete Beispiel ist ungeeignet. Da Deutsch eine unterstützte Sprache ist, müssen deutsche Benutzer die in diesem Abschnitt aufgeführten Schritte nicht ausführen.
In diesem Handbuch fehlt die folgende Beschreibung der Anmeldefehlercodes: (ID-5657)
Identity Manager bietet die folgenden Fehlercodes, die benutzerdefinierte Codes prüfen können, um den Anmeldestatus zu ermitteln. Die tatsächlichen String-Werte sind die numerischen Werte in Klammern (z. B. 101 oder 102). Die Datei Constants.java enthält die folgenden Fehlercodes:
LIGHTHOUSE_USER_NOT_FOUND = 101; LIGHTHOUSE_AUTHN_FAILED = 102; RESOURCE_AUTHN_SUCCESSFUL = 104; RESOURCE_AUTHN_FAILED = 108; X509_CERT_NOT_FOUND = 110; END_USER_ATTEMPTED_LOGIN_TO_ADMIN_APP = 120; LIGHTHOUSE_USER_DISABLED = 140; LIGHTHOUSE_USER_LOCKED = 180;
Die Beschreibung der Systemkonfigurationsobjekte muss die folgenden Informationen zu diesen Attributen enthalten:
ProvisioningDisabledUserShouldThrow – Wenn dieses Attribut auf „true“ gesetzt ist, wird jeder Versuch der Bereitstellung eines deaktivierten Benutzers für eine Ressource verhindert und eine Fehlermeldung erzeugt. Ist dieses Attribut nicht auf „true“ gesetzt, wird die Bereitstellung weiterhin verhindert, aber es wird keine Fehlermeldung erzeugt. (ID-20064)
security.delegation.historyLength – Legt die Anzahl der vorherigen Delegierungen fest, die aufgezeichnet werden. (ID-13331)
runPasswordLoginOnSuccess – Ist dieses Attribut auf „true“ gesetzt, führt Identity Manager den Ablauf für eine Anmeldung über das Passwort aus, wenn ein Benutzer die Authentifizierungsfragen korrekt beantwortet. In der Standardeinstellung lautet der Wert für diese Eigenschaft „false“. (ID-10030)
PasswordSyncThreshold - Ist die Passwortsynchronisation für eine Ressource aktiviert, für die Identity Manager auch Passwortänderungen initiieren kann, können Sie mit diesem Attribut verhindern, dass bereits benutzte Passwörter erneut verwendet werden. (ID-7887) Wenn Sie eine Passwortänderung in Identity Manager initiieren, wird das Passwort in der Ressource zurückgesetzt und die PasswordSync-Bibliothek informiert Identity Manager über die Änderung. Identity Manager vergleicht dann das „lastPasswordDate“ für das Benutzerobjekt mit der aktuellen Zeit. Ist der Unterschied niedriger als der Wert für „PasswordSyncThreshold“, ignoriert Identity Manager die Passwortänderung. Auf diese Weise können zusätzliche oder unnötige Passwortänderungen ignoriert werden.
PasswordSyncResourceExcludeList – Enthält eine Liste mit Ressourcennamen, die von einer Synchronisierung immer ausgeschlossen werden sollen.(ID-3275)
process.handleNativeChangeToAccountAttributes – Wenn dieses Attribut auf „true“ gesetzt ist, wird eine Prüfung des Attributwerts aktiviert. Standardmäßig ist diese Eigenschaft deaktiviert. (Hinweis: Diese Eigenschaft aktiviert eine Attributwertprüfung sowohl für den Abstimmungsprozess als auch für den Provisioner.) (ID-3275)
sources.subject – Gibt den Anmeldenamen des Administrators an, der als Eigentümer der Quelladapter-Aufgabe zugewiesen ist (ID-19694)
sources.host – Gibt den Server an, auf dem die Quelladapter-Aufgabe ausgeführt wird.
security.saveNoValidateAllowedFormsAndWorkflows – Führt die IDs der Formulare und Arbeitsabläufe auf, die als eine „SaveNoValidate“-Aktion verarbeitet werden. Alle sonstigen Formulare und Arbeitsabläufe werden als eine „Save“-Aktion verarbeitet. Wenn diese Liste nicht vorhanden ist, wird das Verhalten für alle Formulare und Arbeitsabläufe beibehalten (alle Formulare und Arbeitsabläufe werden als „SaveNoValidate“ verarbeitet). (ID-19474)
Mit Data Exporter können von Identity Manager verwaltete oder verarbeitete Daten in regelmäßigen Abständen zur Weiterverarbeitung in DBMS-Tabellen exportiert werden. Der Exportprozess kann in verschiedenen Bereichen angepasst werden, das heißt, es ist ein Eingriff durch den Benutzer erforderlich, um das gewünschte Verhalten zu erreichen. Die für Data Exporter entscheidenden Identity Manager-Konfigurationsobjekte werden beibehalten und entsprechend aktualisiert. Einige Anpassungen von Data Exporter finden jedoch in Dateien innerhalb der Web-Anwendung statt. Für diese Dateien ist eine besondere Vorgehensweise erforderlich.
Während der Aktualisierung überschreibt Identity Manager alle nicht modifizierten Data Exporter-Dateien in den Verzeichnissen $WSHOME und $WSHOME/exporter. Wenn Sie Änderungen an Data Exporter-Dateien vorgenommen haben, lässt der Aktualisierungsprozess Ihre modifizierte Version unberührt und installiert die neuere Version der Datei unter $WSHOME/patches/Identity_Manager_8_1_0_0_ Datum/filesNotInstalled. Wenn Sie die neuen Funktionen mit den von Ihnen vorgenommenen Anpassungen kombinieren möchten, ist dies nur manuell möglich.
Häufig werden die folgenden Dateien im Verzeichnis $WSHOME angepasst:
model-export.dtd model-export.xml model-export.xsl exporter/exporter.jar exporter/create_warehouse.* exporter/drop_warehouse.* exporter/hbm/*.hbm.xml
Die von Ihnen durchzuführenden Aktualisierungsschritte hängen davon ab, ob Sie Data Exporter in der Version 8.0 angepasst haben und was Sie mit Data Exporter in der Version 8.1 planen.
Wenn Sie Data Exporter in der Version 8.0 angepasst haben und die 8.1-Funktionen implementieren möchten:
Verwerfen Sie das Warehouse-Schema.
Aktualisieren Sie Identity Manager.
Erstellen Sie das Schema mit der neuen DDL im Verzeichnis $WSHOME/exporter neu.
Es gibt keine Schema-Aktualisierungsskripten, mit denen Sie ein Schema mit vorhandenen Daten modifizieren können. Wenn Sie also das Überschreiben der Daten verhindern wollen, müssen Sie die Daten zunächst exportieren und dann wieder importieren. Das 8.1 Warehouse-Schema ist hinsichtlich der Tabellen und Felder kompatibel mit der vorherigen Version, obwohl in der Version 8.1 neue Tabellen und Felder zu den bestehenden Tabellen hinzugefügt wurden. Auch die Feldreihenfolge wurde geändert. Aus diesem Grund dürfen Sie nur die reinen Daten exportieren. Führen Sie keinen DDL- und Daten-Export durch.
Führen Sie Ihre Anpassungen mit den neuen 8.1 Exporter-Dateien zusammen. Wenn die Datei model-export.xml angepasst wurde, erstellen Sie die Datei exporter.jar neu.
Laden Sie das neue Warehouse-Schema.
Wenn Sie Data Exporter in der Version 8.0 angepasst haben und die 8.1-Funktionen nicht implementieren möchten:
Sie können auf die Version 8.1 aktualisieren, ohne die zusätzlichen Schritte auszuführen. Wenn Sie jedoch auf den 8.1 Exporter aktualisieren, aber die Warehouse-DDL nicht aktualisieren, zeigt die Seite „Warehouse-Konfiguration“ eine Fehlermeldung an, in der darauf hingewiesen wird, dass die EXT_ADMINGROUP-Tabelle fehlt. Dies deutet darauf hin, dass zwar neue 8.1-Objekte vorhanden sind, die alte 8.0 Warehouse-DDL aber noch immer geladen ist.
Wenn Sie Data Exporter in der Version 8.0 nicht angepasst haben und die 8.1-Funktionen nicht implementieren möchten:
Verwerfen Sie das Warehouse-Schema.
Aktualisieren Sie Identity Manager.
Laden Sie das neue Warehouse-Schema.
Die Daten im Warehouse bleiben unberührt. Sie müssen die DDL nicht ändern, wenn die Datei model-export.xml angepasst wurde. Wenn die Datei model-export.xml nicht angepasst wurde, müssen Sie die neue DDL laden.
Nachdem 8.1 installiert und die 8.1-Version der Datei „model-export.xml“ eingefügt wurde, können Sie die neuen Dateitypen und -attribute sehen, wenn Sie die Schema-Datei unter http://server: port/idm/model-export.xml anzeigen. Die neuen Typen und Attribute sind mit der Versionsnummer 8.1 gekennzeichnet.