Identity Manager 8.1 Deployment Reference

Dieser Abschnitt enthält neue und berichtigte Informationen für das Handbuch Sun Identity Manager Deployment Reference.

Formulare-bezogene Dokumentationsprobleme

In diesem Kapitel fehlt die folgende Beschreibung zum Hinzufügen einer geheimen Frage zur Passwortbestätigung für Formulare: (ID-7604)

Sie können die Formulareigenschaft „RequiresChallenge“ verwenden, um ausgewählten Formularen eine geheime Frage zur Passwortbestätigung hinzuzufügen. Ist diese Funktion aktiviert, stellt Identity Manager dem aktuell angemeldeten Administrator eine geheime Frage zu seinem Passwort, bevor die Anforderung verarbeitet wird. Diese Option wird von den folgenden Formularen unterstützt:

UserForm (Registerkarten-Benutzerformular, Assistent-Benutzerformular, Standard-Benutzerformular)

changePassword (standardmäßig, Benutzerpasswort ändern-Formular)

resetPassword (standardmäßig, Benutzerpasswort zurücksetzen-Formular)

Diese Eigenschaft ist für jedes Formular auf andere Weise angegeben.

Einrichten der „RequiresChallenge“-Eigenschaft für Benutzerformulare

Um einem Benutzerformular eine Geheimfrage zur Passwortbestätigung hinzuzufügen, fügen Sie das folgende „RequiredElement“-Element ein und ersetzen dabei die Angaben für „password“, „email“ und „fullname“ entsprechend:

<Property name='RequiredChallenge'>
    <List>
      <String>password</String>
      <String>email</String>
      <String>fullname</String>
    </List>
</Property>

Der Wert der Eigenschaft ist eine Liste mit einem oder mehreren der folgenden Benutzeransicht-Attributnamen: applications, adminRoles, assignedLhPolicy, capabilities, controlledOrganizations, email, firstname, fullname, lastname, organization, password, resources, roles.

Einrichten der „RequiresChallenge“-Eigenschaft für die Formulare „Passwort ändern“ und „Passwort zurücksetzen“

Um einem „changePassword“- oder „resetPassword“-Formular eine Geheimfrage zur Passwortbestätigung hinzuzufügen, fügen Sie das folgende <RequiresChallenge>-Element ein und ersetzen dabei die Angaben für „password“, „email“ und „fullname“ entsprechend:

<Property name='RequiresChallenge' value='true'/>

Dabei lautet der Wert der Eigenschaft entweder „true“ oder „false“.

Wenn die Eigenschaft im Formular auf „true“ gesetzt ist, stellt Identity Manager dem aktuellen Administrator, der eine Änderung des Passworts anfordert, mit dem er sich bei Lighthouse angemeldet hat, eine Geheimfrage. Kann die Geheimfrage nicht korrekt beantwortet werden (das heißt, das aktuelle Administratorpasswort wird nicht korrekt eingegeben), verweigert Identity Manager die Änderung. Wurde die Geheimfrage korrekt beantwortet, lässt Identity Manager die Änderungsanforderung zu. Beide Formulare zur Passwortverwaltung unterstützen die Verwendung der Formulareigenschaft 'RequiresChallenge'. Ist diese Eigenschaft auf „true“ gesetzt, wird der Benutzer aufgefordert, das alte Passwort einzugeben, nachdem er das neue Passwort angegeben hat.

Überschreiben der Versionsinformationen

Sie können zwei benutzerdefinierte Nachrichtenkatalogschlüssel erstellen, mit denen verhindert wird, dass Identity Manager die Versionsinformationen anzeigt, wenn ein Benutzer den Mauszeiger auf der Schaltfläche „Hilfe“ platziert. Der Schlüssel UI_END_USER_VERSION blendet die Versionsinformationen in der Endbenutzeroberfläche aus, der Schlüssel UI_VERSION führt die gleiche Funktion in der Administratorbenutzeroberfläche aus.

Setzen Sie den Wert dieses Schlüssels auf eine leere Zeichenfolge, um zu verhindern, dass Versionsinformationen angezeigt werden.

In dem folgenden Beispiel wird die Anzeige der Versionsinformationen in beiden Benutzeroberflächen verhindert.

<Waveset>
   <Configuration name="sampleCustomCatalog">
      <Extension>
         <CustomCatalog id="defaultCustomCatalog" enabled="true">
            <MessageSet language="en" country="US">
               <Msg id="UI_END_USER_VERSION"></Msg>
               <Msg id="UI_VERSION"></Msg>
            </MessageSet>
         </CustomCatalog>
      </Extension>
   </Configuration>
</Waveset>

Weitere Formulare-bezogene Probleme

In dem Kapitel „Forms“ (Formulare) fehlt die folgende Abhandlung: (ID-18869)

Standardmäßig gibt es zwei Implementierungen des Formulars zum Ändern des Passworts:

Das Formular zum Ändern des Endbenutzer-Passworts ist das Standardformular zum Ändern eines Passwortes. Es enthält eine einfache Reihe von Feldern, mit denen der Benutzer sein Passwort ändern kann. Die Passwortrichtlinien für alle Ressourcen, die dem Benutzer zugewiesen sind, werden gesammelt und zusammengefasst, und Identity Manager übernimmt die Passwortänderung für alle zugewiesenen Ressourcen.

Das Formular für eine allgemeine Passwortänderung ist in beiden Benutzeroberflächen (Administrator und Endbenutzer) vorhanden. Es enthält Informationen zu den Ressourcen, die dem Benutzer zugeordnet sind, und ermöglicht es dem Benutzer, individuell auszuwählen, für welche Ressourcen Identity Manager das Passwort ändern soll.

Beide Formulare zur Passwortverwaltung unterstützten die Verwendung der Formulareigenschaft 'RequiresChallenge'. Ist diese Eigenschaft auf „true“ gesetzt, wird der Benutzer aufgefordert, das alte Passwort einzugeben, nachdem er das neue Passwort angegeben hat.

Probleme in Arbeitsabläufen und Formularen

In den Kapiteln zu den Formularen und Arbeitsabläufen fehlt die folgende Abhandlung über das Zuweisen eines Geltungsbereichs für <Variable>-Elemente: (ID-14915)

Identity Manager weist allen <Variable>-Elementen beim Deklarieren des Elementes einen Geltungsbereich zu. Wenn Sie einem Bereichsattribut keinen Wert zuweisen, weist Identity Manager den Wert „local“ zu. Dieser Wert bedeutet, dass die Variable nur innerhalb des XPRESS-Abschnitts zugänglich ist, in dem sie deklariert wird.

Weitere Variablen-Attribute, die den Geltungsbereich definieren, sind:

input – Deklariert, dass das <Variable>-Element einen lokalen Geltungsbereich besitzt und dass der Wert vom Aufrufer initialisiert werden kann.

output – Deklariert, dass das <Variable>-Element einen lokalen Geltungsbereich besitzt, aber dem Aufrufer zurückgegeben werden kann.

external – Deklariert, dass das <Variable>-Element einen nicht lokalen Geltungsbereich besitzt. Das heißt, dass Zuweisungen zu dieser Variablen dazu führen, dass sie in dem Geltungsbereich erfolgen, in dem sie zuerst deklariert wurde.

In diesem Kapitel fehlt die folgende Abhandlung zur Whitelist-Funktion von Identity Manager. (ID-19474)

Mit der Whitelist-Funktion von Identity Manager können Formulare und Arbeitsabläufe, die die „SaveNoValidate“-Aktion verwenden, gegen eine Liste mit IDs oder Formularnamen geprüft werden. Identity Manager prüft die Weißbücher entweder auf Formularnamen oder Formulareigentümer-IDs. Die ID-Liste mit der Bezeichnung „saveNoValidateAllowedFormsAndWorkflows“ befindet sich im „security“-Attribut des Systemkonfigurationsobjekts. Befindet sich der Formularname oder die Eigentümer-ID in der Whitelist, kann das Formular bzw. der Arbeitsablauf die „SaveNoValidate“-Aktion verwenden. Befindet sich der Formularname oder die Eigentümer-ID nicht in der Whitelist, wird das Formular bzw. der Arbeitsablauf mit der „Save“-Aktion verarbeitet. Ist diese Liste nicht vorhanden, können alle Formulare und Arbeitsabläufe als „SaveNoValidate“ verarbeitet werden.

Um diese Funktion in Ihrer Bereitstellung zu implementieren, müssen Sie alle Formulare oder Arbeitsabläufe mit „SaveNoValidate“ zur „SaveNoValidateAllowedFormsAndWorkflows“-Liste im Systemkonfigurationsobjekt hinzufügen. Um die IDs oder Formularnamen anzuzeigen, die Sie hinzufügen müssen, prüfen Sie das Systemprotokoll (syslog) oder aktivieren die Ablaufverfolgungsebene 4 für „com.waveset.ui.util.GenericEditForm“ und übermitteln alle benutzerdefinierten Formulare oder Arbeitsabläufe, die „SaveNoValidate“ verwenden. Es wird eine Warnmeldung protokolliert, in der auch die ID enthalten ist. Wenn Sie „null“ Formularnamen im Systemprotokoll erhalten, prüfen Sie, ob das Formular in der ausgeführten TaskDefinition über ein „name“-Attribut verfügt.

Arbeitsablauf-bezogene Probleme

In dem Kapitel „Workflow“ (Arbeitsablauf) fehlt die folgende Abhandlung zum „handleNativeChangeToAccountAttributes“-Arbeitsablauf: (ID-3275):

Jedes Mal, wenn Identity Manager eine native Änderung an den Werten eines prüffähigen Attributs eines Ressourcenkontos erfasst (das heißt, eine Änderung, die nicht von Product_IDMgr; durchgeführt wurde), führt es den Arbeitsablauf „handleNativeChangeToAccountAttributes“ aus, der diesem Systemkonfigurationsobjekt-Attribut zugeordnet ist:

<Attribute name='process'>
  <Object>
    <Attribute name='handleNativeChangeToAccountAttributes' value='Audit Native
      Change To Account Attributes'/>
  </Object>
</Attribute>

Dieser Arbeitsablauf protokolliert native Änderungsereignisse in einem Ereignisprotokoll, wenn Sie den Überwachungsfilter „Changes Outside Lighthouse“ (Änderungen außerhalb von Lighthouse) aktiviert haben. Anderenfalls wird das Ereignis von Identity Manager ignoriert. Achtung: Achten Sie sorgfältig darauf, welche Methoden Sie von einem Arbeitsablauf aus aufrufen, der den oben aufgeführten Standard-Arbeitsablauf ersetzt.

Da Identity Manager diesen Arbeitsablauf immer dann startet, wenn das Abrufen eines Ressourcenkontos eine native Änderung aufdeckt, sollte keine Methode oder kein Arbeitsablauf aufgerufen werden, der einen weiteren Abruf des gleichen Ressourcenkontos auslöst. Beispielsweise würde eine unendliche Schleife entstehen, wenn Sie eine „WorkflowServices“-Methode aufrufen, die die Benutzeransicht zusammensetzt: getView(User),checkoutView(User) und possibly checkinView(User).

Da Identity Manager jede native Änderung durch Ausführen eines Arbeitsablaufs verarbeitet, können Sie das native Änderungsereignis erfassen und es entweder durch Ersetzen oder Hinzufügen zum standardmäßigen Arbeitsablauf für eine native Änderung verarbeiten. So können Sie z. B. wählen, eine E-Mail an einen Administrator oder Benutzer zu senden, das Ereignis in einer Datenbank zu erfassen, eine Aktualisierung in eine Warteschlange einzureihen, die diese native Änderung wieder rückgängig macht oder sogar diese native Änderung einbeziehen und an andere Ressourcen weiterzusenden.

In dem Kapitel „Workflow“ (Arbeitsablauf) dieses Handbuchs fehlt die folgende Beschreibung, wie das Thema oder der Administrator einer Quelladapter-Aufgabe angegeben wird. (ID-19694).

Sie können einer Quelladapter-Aufgabe ein Thema oder einen Administrator zuordnen und den Server zuweisen, auf dem die Aufgabe ausgeführt wird, indem Sie die folgenden Attribute des Systemkonfigurationsobjekts ändern. „source.subject“ gibt den Anmeldenamen des Administrators an, der als Eigentümer dieser Aufgabe zugewiesen ist. „sources.host“ gibt den Server an, auf dem die Aufgabe ausgeführt wird. Die neuen Werte im Konfigurationsobjekt lauten standardmäßig:

<Attribute name='sources'>
           <Object>
             <Attribute name='hosts'/> <!-- any host is the default -->
           <Attribute name='subject' value='Configurator'/>
         </Object>
         </Attribute>