Sun Java System Access Manager 7 2005Q4 Versionshinweise

Access Manager 7 2005Q4-Patch 3

Access Manager 7-Patch 3 (Überarbeitung 03) behebt eine Reihe von Problemen, die in der README-Datei zum Patch aufgeführt sind. Des Weiteren enthält Patch 3 folgende neue Funktionen und bekannte Probleme:

Neue Funktionen in Patch 3

Bekannte Probleme und Einschränkungen in Patch 3

Neue Konfigurationseigenschaften für Siteüberwachung

Die Siteüberwachungsfunktion von Access Manager enthält folgende neue Eigenschaften:

Eigenschaft 

Beschreibung 

com.sun.identity.sitemonitor.interval

Intervallzeit in Millisekunden für Siteüberwachung. Die Siteüberwachungsfunktion überprüft die Verfügbarkeit der einzelnen Sites im angegebenen Zeitintervall. Standard: 60000 Millisekunden (1 Minute). 

com.sun.identity.sitemonitor.timeout

Zeitüberschreitung in Millisekunden für Überprüfung der Siteverfügbarkeit. Die Siteüberwachungsfunktion wartet auf eine Antwort von der Site, bis der angegebene Zeitüberschreitungswert erreicht wurde. Standard: 5000 Millisekunden (5 Sekunden).  

Der Patch fügt diese Eigenschaften der Datei AMConfig.properties nicht hinzu. So verwenden Sie diese neuen Eigenschaften mit anderen Werten als den Standardwerten

  1. Fügen Sie die Eigenschaften und deren Werte zur Datei AMConfig.properties im folgenden Verzeichnis (abhängig von der Plattform) hinzu:

    • Solaris-Systeme: /etc/opt/SUNWam/config

    • Linux-Systeme: /etc/opt/sun/identity/config

    Fügen Sie für Richtlinienagenten diese Eigenschaften der Datei AMAgents.properties hinzu.

  2. Starten Sie den Access Manager-Webcontainer neu, damit die Werte in Kraft treten.

Benutzerdefinierte Implementierung. Die Klasse com.sun.identity.sitemonitor.SiteStatusCheck ermöglicht Ihnen zusätzlich, Ihre eigene Implementierung für die Überprüfung der Siteverfügbarkeit über folgende Schnittstelle anzupassen:

package com.iplanet.services.naming.WebtopNaming$SiteStatusCheck

Alle Implementierungsklassen müssen die Methode doCheckSiteStatus verwenden.

public interface SiteStatusCheck { 
public boolean doCheckSiteStatus(URL siteurl);
}

Unterstützung für Liberty Identity Web Services Framework (ID-WSF) 1.1

WSF1.1 ist die in Access Manager 7-Patch 3 verwendete Standardversion von ID-WSF. Zum Auslösen von ID-WSF ist keine gesonderte Konfiguration erforderlich, die Beispiele müssen jedoch die neuen Sicherheitsmechanismen verwenden. Die neuen Sicherheitsmechanismen für ID-WSF1.1 lauten:

urn:liberty:security:2005-02:null:X509
urn:liberty:security:2005-02:TLS:X509
urn:liberty:security:2005-02:ClientTLS:X509
urn:liberty:security:2005-02:null:SAML
urn:liberty:security:2005-02:TLS:SAML
urn:liberty:security:2005-02:ClientTLS:SAML
urn:liberty:security:2005-02:null:Bearer
urn:liberty:security:2005-02:TLS:Bearer
urn:liberty:security:2005-02:ClientTLS:Bearer

Neue Eigenschaft für Liberty ID-WSF-Unterstützung

Die Eigenschaft com.sun.identity.liberty.wsf.version legt das Liberty ID-WSF-Framework fest, wenn das Framework nicht von der eingehenden Nachricht oder vom Ressourcenangebot festgelegt werden kann und Access Manager als WSC agiert. Gültige Werte sind 1.0 und 1.1. Der Standardwert lautet 1.1.

Hinweis Bei der Patch-Installation wird die Eigenschaft com.sun.identity.liberty.wsf.version der Datei AMConfig.properties nicht hinzugefügt (6458184). Um diese neue Eigenschaft zu verwenden, fügen Sie sie der Datei AMConfig.properties mit dem enstprechenden Wert hinzu, nachdem Sie den Patch installiert und den Access Manager-Webcontainer neu gestartet haben.

Führen Sie nach der Installation von Access Manager 7-Patch 3 den folgenden Befehl aus, um die Schemaänderungen zu laden. Im folgenden Beispiel ist Access Manager im Standardverzeichnis für Solaris-Systeme installiert:

# /opt/SUNWam/bin/amadmin -u amadmin -w amadmin_password 
-t /etc/opt/SUNWam/wsf1.1_upgrade.xml

Die Erkennungsregistrierung von ID-WSF kann diese neuen Sicherheitsmechanismen bei der Registrierung verwenden. Darüber hinaus erkennen WSCs automatisch, welche Version bei der Kommunikation mit WSPs verwendet werden muss. Um die Konfiguration für ID-WSF1.1 vorzunehmen, folgen Sie den Anweisungen in den im Produkt enthaltenen Readme-Dateien für Liberty ID-FF Beispiel 1 und ID-WSF-Beispiele.

Protokoll amProfile_Client der verteilten Authentifizierung und Access Manager-Serverprotokoll amProfile_Server enthalten unbedenkliche Ausnahmefehler (6463779)

Anfragen bei Access Manager über die "Verteilte Authentifizierungsbenutzeroberfläche" lösen Ausnahmefehler im Protokoll distAuth/amProfile_Client und im Access Manager-Serverprotokoll debug/amProfile_Server aus. Nach mehreren Sitzungen kann das Protokoll amProfile_Client auf mehrere Gigabyte und das Access Manager-Serverprotokoll amProfile_Server auf mehrere Megabyte anwachsen. Die Funktionalität wird durch die Ausnahmefehler in diesen Protokollen nicht beeinträchtigt. Die Ausnahmefehler können jedoch unnötigerweise Benutzer alarmieren und dazu führen, dass die Protokolle den gesamten Festplattenspeicherplatz einnehmen.

Lösung. Führen Sie cron-Aufträge aus, die den Inhalt der Protokolldateien auf null setzen. Beispiel:

Standardmäßiger Anwendungsbenutzer der verteilten Authentifizierung darf nicht amadmin sein (6460974)

Wenn Sie einen Server mit der "Verteilten Authentifizierungsbenutzeroberfläche" bereitstellen, darf der Administrator der verteilten Authentifizierung nicht amadmin sein. Der standardmäßige Anwendungsbenutzer der verteilten Authentifizierung in der Datei Makefile.distAuthUI lautet amadmin und somit auch in der Datei AMConfig.properties, nachdem die Datei distAuth.war auf Clientseite bereitgestellt wurde. Der Benutzer amadmin verfügt über ein AppSSOToken, das nach Zeitüberschreitung der amadmin-Sitzung abläuft. Dies kann zu einem SCHWEREN FEHLER in der Protokolldatei amSecurity führen, die sich standardmäßig im Verzeichnis /tmp/distAuth befindet.

Lösung. Geben Sie UrlAccessAgent als Anwendungsbenutzer der verteilten Authentifizierung an. Beispiel:

Ändern Sie vor der Bereitstellung der Datei distAuth.war im Client-Webcontainer folgende Parameter in der Datei Makefile.distAuthUI :

APPLICATION_USERNAME=UrlAccessAgent
APPLICATION_PASSWORD=shared-secret-password or amldapuser-password

oder

Ändern Sie nach der Bereitstellung der Datei distAuth.war im Client-Webcontainer die folgenden Eigenschaften in der Datei AMConfig.properties für jeden Access Manager-Server:

com.sun.identity.agents.app.username=UrlAccessAgent
com.iplanet.am.service.password=shared-secret-password or amldapuser-password

Siehe auch Die "Verteilte Authentifizierung" sollte nicht als amadmin-Benutzer ausgeführt werden (6440697).

Fehlender Link für Benutzerdienst unter "Gefilterte Funktion" in Konsolenonlinehilfe (6460576)

In der Konsolenonlinehilfe zu Access Manager fehlt unter "Gefilterte Funktion" der Link zum Benutzerdienst. Navigieren Sie in der Onlinehilfe zu "Inhalt", "Gefilterte Funktion" und "So erstellen Sie eine gefilterte Rolle". Wenn Sie weiterblättern, wird je nach ausgewähltem Identitätstyp eine Liste mit Diensten angezeigt, ein Link zum Benutzerdienst ist jedoch nicht verfügbar.

Lösung. Kein

Zugriff auf den Server auf WebSphere nach Ausführung von reinstallRTM und der erneuten Bereitstellung von Webanwendungen nicht möglich (6460085)

Nach der Anwendung von Access Manager 7-Patch 3 in einer DEPLOY_LEVEL=1-Bereitstellung auf IBM WebSphere Application Server 5.1.1.6 unter Red Hat Linux AS 3.0 Update 4 wurde das Skript reinstallRTM ausgeführt, um die RTM-RPMs wiederherzustellen. Die Webanwendungen wurden anschließend erneut bereitgestellt, nachdem die vom Skript reinstallRTM generierte Datei amsilent bearbeitet wurde. WebSphere wurde dann mit den Skripten stopServer.sh und startServer.sh neu gestartet. Beim Zugriff auf die Anmeldeseite hat WebSphere jedoch einen 500-Fehler mit Verweis auf Filter amlcontroller angezeigt.

Dieses Problem trat auf, da die neue vom Skript reinstallRTM generierte Datei server.xml fehlerhaft war.

Lösung. Die vom Skript amconfig erstellte Kopie der Datei server.xml ist nach wie vor gültig. Verwenden Sie diese Kopie wie folgt:

  1. Halten Sie den Server an.

  2. Ersetzen Sie die fehlerhafte Datei server.xml durch die vom Skript amconfig erstellte Kopie der Datei.

    Die vom Skript amconfig erstellte Kopie der Datei server.xml hat den Namen server.xml-orig- pid, wobei pid die Prozess-ID des Skripts amwas51config ist. Die Datei befindet sich im folgenden Verzeichnis:

    WebSphere-home-directory/config/cells/WebSphere-cell
    /nodes/WebSphere-node/servers/server-name
    
  3. Starten Sie den Server neu.

Markerklasse sunISManagerOrganization muss vor dem Aufrüsten zu Organisationen hinzugefügt werden (6455757)

Organisationen in einem Access Manager-Informationsverzeichnisbaum (Directory Information Tree, DIT), der mit einer Vorgängerversion von Access Manager 7 erstellt wurde, verfügen möglicherweise nicht über die Objektklasse sunISManagerOrganization. Ebenso ist in der Definition von Organisationen, die von einem anderen Produkt als Access Manager erstellt wurden, die Objektklasse sunISManagerOrganization nicht enthalten.

Lösung. Stellen Sie vor dem Aufrüsten auf Access Manager 7 2005Q4 sicher, dass alle Organisation im DIT in ihrer Definition über die Objektklasse sunISManagerOrganization verfügen. Fügen Sie die Objektklasse vor dem Aufrüsten gegebenenfalls manuell hinzu.

Aufrüsten auf Access Manager 7 2005Q4-Patch 2 verursacht Fehler auf der Registerkarte "Aktuelle Sitzungen" der Konsole (6454489)

Das Aufrüsten hat folgenden Fehler auf der Registerkarte "Aktuelle Sitzungen" der Access Manager-Konsole verursacht:

Failed to get valid Sessions from the Specified server

Dieses Problem betrifft Bereitstellungen, die von Access Manager 6-Versionen aufgerüstet werden und ein Root-Suffix im Format o=orgname aufweisen.

Lösung. Wenden Sie nach der Installation von Access Manager 7 2005Q4 den Access Manager 7-Patch 3 an und führen Sie anschließend das Skript amupgrade aus, um die Daten zu migrieren. Gehen Sie wie folgt vor:

  1. Sichern Sie Ihren Access Manager 6-DIT.

  2. Führen Sie das Skript ampre70upgrade aus.

  3. Installieren Sie Access Manager 7 2005Q4 mit der Option "Später konfigurieren".

  4. Heben Sie die Bereitstellung der Access Manager-Webanwendungen auf.

  5. Stellen Sie die Access Manager-Webanwendungen bereit.

  6. Wenden Sie den Access Manager 7-Patch 3 an, ohne dabei die XML/LDIF-Änderungen anzuwenden. Die XML/LDIF-Änderungen müssen nach der Ausführung des Skripts amupgrade im nächsten Schritt angewendet werden.

  7. Führen Sie das Skript amupgrade aus.

  8. Stellen Sie die Access Manager-Webanwendungen erneut bereit. Dies ist aufgrund der Änderungen durch den Access Manager 7-Patch 3 erforderlich.

  9. Greifen Sie auf die Access Manager-Konsole zu.

Ausnahmefehler bei Verwendung der Abruffunktion zusammen mit dem Client-SDK (6452320)

Wenn Sie das Access Manager Client-SDK (amclientsdk.jar) bereitstellen und die Abruffunktion aktivieren, können beispielsweise folgende Fehler auftreten:

ERROR: Send Polling Error:
com.iplanet.am.util.ThreadPoolException: 
amSessionPoller thread pool's task queue is full.

Fehler dieser Art können auftreten, wenn Sie einen Server mit Verteilter Authentifizierungsbenutzeroberfläche oder J2EE-Agenten bereitstellen bzw. wenn Sie das Access Manager Client-SDK auf einem Client bereitstellen.

Lösung. Beschränkt sich die Anzahl der gleichzeitigen Sitzungen auf einige hundert Sitzungen, fügen Sie folgende Eigenschaften und deren Werte entweder der Datei AMConfig.properties oder der Datei AMAgents.properties hinzu:

com.sun.identity.session.polling.threadpool.size=10
com.sun.identity.session.polling.threadpool.threshold=10000

Handelt es sich um Tausende oder Zehntausende von Sitzungen, sollten die Werte mit den Werten für die Benachrichtigung in der Access Manager-Datei AMConfig.properties übereinstimmen, nachdem das Skript amtune-identity ausgeführt wurde. Für einen Rechner mit 4 GB RAM werden vom Access Manager-Skript amtune-identity beispielsweise folgende Werte festgelegt.

com.sun.identity.session.notification.threadpool.size=28
com.sun.identity.session.notification.threadpool.threshold=76288

Legen Sie ähnliche Werte auf Clientseite in der Datei AMAgent.properties oder AMConfig.properties fest, wenn der Server mit der "Verteilten Authentifizierungsoberfläche" oder das Access Manager Client-SDK auf einem Client-Rechner mit 4 GB RAM bereitgestellt wird.

SSOToken eines authentifizierten Benutzers wird ungewollt auf Rogue-Websites angezeigt (6442905)

Durch Klicken auf einen URL auf einer Rogue-Website ist es möglich, dass ein authentifizierter Access Manager-Benutzer ungewollt den SSOToken auf der Rogue-Website anzeigt.

Lösung. Erstellen Sie für alle teilnehmenden Richtlinienagenten immer ein eindeutiges Agent-Benutzerprofil in Access Manager, um sicherzustellen, dass die Website keine Rogue-Website ist. Stellen Sie außerdem sicher, dass keiner der eindeutigen Agent-Benutzer dasselbe Passwort als gemeinsames geheimes Passwort bzw. amldapuser -Passwort verwendet. Richtlinienagenten werden beim Access Manager-Anwendungsauthentifizierungsmodul standardmäßig als UrlAccessAgent-Benutzer authentifiziert.

Weitere Informationen zum Erstellen eines Agenten unter Verwendung der Access Manager Administration Console finden Sie unter Agents in Sun Java System Access Manager 7 2005Q4 Administration Guide.

Site-Überwachungsintervall und Eigenschaften der Zeitüberschreitung (6441918)

Access Manager-Sitefailover enthält folgende neue Eigenschaften:

com.sun.identity.sitemonitor.interval
com.sun.identity.sitemonitor.timeout 

Weitere Informationen finden Sie unter Neue Konfigurationseigenschaften für Siteüberwachung.

Die "Verteilte Authentifizierung" sollte nicht als amadmin-Benutzer ausgeführt werden (6440697)

Um einen anderen Administrator als den standardmäßigen Administrator (amadmin) der Anwendungsauthentifizierung für die verteilte Authentifizierung zu erstellen, gehen Sie wie folgt vor:

  1. Erstellen Sie einen LDAP-Benutzer für den Administrator der verteilten Authentifizierung. Beispiel:

    uid=DistAuthAdmin,ou=people,o=am
  2. Fügen Sie den Administrator der verteilten Authentifzierung der Liste der besonderen Benutzer hinzu. Beispiel:

    com.sun.identity.authentication.special.users=cn=dsameuser,
    ou=DSAME Users,o=am|cn=amService-UrlAccessAgent,ou=DSAME Users,
    o=am|uid=DistAuthAdmin,ou=People,o=am

    Fügen Sie diese Eigenschaft der Datei AMConfig.properties auf allen Access Manager-Servern hinzu, damit das AppSSOToken des Administrators der verteilten Authentifzierung bei Ablauf der Sitzung nicht abläuft.

Server mit Verteilter Authentfizierungsbenutzeroberfläche und Load Balancer (6440695)

Wenn in Ihrer Bereitstellung mehreren Servern mit verteilter Authentifizierungsbenutzeroberfläche ein Load Balancer vorgeschaltet ist, legen Sie nach Bereitstellung der WAR-Datei die folgenden Eigenschaften in der Datei AMConfig.properties fest.

com.iplanet.am.lbcookie.name=DistAuthLBCookieName
com.iplanet.am.lbcookie.value=DistAuthLBCookieValue

Cookie-Wiedergabe erfordert Eigenschaft com.sun.identity.session.resetLBCookie (6440651)

Damit die Cookie-Wiedergabe für das Access Manager-Sitzungsfailover ordnungsgemäß ausgeführt wird, fügen Sie die Eigenschaft com.sun.identity.session.resetLBCookie mit dem Wert true sowohl für den Richtlinienagenten als auch für den Access Manager-Server hinzu. Beispiel:

com.sun.identity.session.resetLBCookie='true'

Hinweis: Diese Eigenschaft ist nur erforderlich, wenn Sie das Access Manager-Sitzungsfailover implementiert haben.

com.iplanet.am.lbcookie.name-Eigenschaft übernimmt den Standardwert amlbcookie (6440648)

Der Richtlinienagent und der Access Manager-Server übernehmen standardmäßig den Load Balancer-Cookie-Namen amlbcookie. Wenn Sie den Cookie-Namen auf dem Back-End-Server ändern, müssen Sie denselben Namen in der Datei AMAgent.properties für den Richtlinienagenten verwenden. Ebenso müssen Sie denselben Cookie-Namen wie den vom Back-End-Server verwendeten Namen verwenden, wenn Sie das Access Manager Client-SDK verwenden.

Eigenschaft com.iplanet.am.lbcookie.value ist veraltet (6440641)

Access Manager unterstützt nicht mehr die Servereigenschaft com.iplanet.am.lbcookie.value zum Anpassen des Load Balancer-Cookies. Access Manager verwendet nun stattdessen für den vom Agenten wiedergegebenen Wert und Namen des Cookies die bei der Sitzungskonfiguration konfigurierte Server-ID.

SSO-Token im ID-FF-SSO-Anwendungsfall kann nicht erstellt werden (6429610)

Nach dem Einrichten von Liberty Identity Federation Framework (ID-FF) Beispiel 1 ist Federation erfolgreich, SSO schlägt jedoch fehl.

Lösung. Fügen Sie die uuid des Benutzers dsameuser der Eigenschaft com.sun.identity.authentication.special.users in der Datei AMConfig.properties hinzu. Für die Anwendungsauthentifzierung benötigt dsameuser ein nicht ablaufendes SSO-Token für den Access Manager-Server.

Wiederholte erfolgreiche Abfragen der Rollenmitgliedschaften eines Benutzers in einem LDAP v3-Datenspeicher bei Access Manager-Anmeldung (6389564)

Bei der Anmeldung eines Benutzers in Access Manager treten wiederholte LDAP-Suchabfragen des Benutzerattributs nsRoleDN auf.

Lösung. Führen Sie nach der Installation von Access Manager 7-Patch 3 den folgenden Befehl aus. Im folgenden Beispiel ist Access Manager im Standardverzeichnis für Solaris-Systeme installiert:

# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/idRepoServiceAddAttrSchemaRequest_Cache.xml

Das Authentifizierungsmodul muss in der Lage sein, den "goto"-URL zu überschreiben und einen anderen URL anzugeben (6385185)

Ein Authentifzierungsmodul kann den "goto"-URL überschreiben und die Umleitung zu einem anderen URL auf einer externen Website anfordern, um den Benutzerstatus zu bestätigen.

Um den "goto"-URL nach Abschluss der Authentifizierung zu überschreiben, legen Sie die im folgenden Beispiel gezeigte Eigenschaft im SSOToken. fest. Verwenden Sie zum Festlegen der Eigenschaft die onLoginSuccess-Methode der Klasse PostProcess, die das AMPostAuthProcessInterface implementiert. OverridingURL ist in diesem Beispiel der URL, der den "goto"-URL überschreibt:

public class <..> implements AMPostAuthProcessInterface {  
...
    public void onLoginSuccess(...) {
        try {
            ssoToken.setProperty("PostProcessSuccessURL", OverridingURL);
         } catch (Exception ...) {
         ...         }
...
}

Umleitung von einem benutzerdefinierten Authentifizierungsmodul aus bei noch ungültigem SSO-Token (6385184)

Die neue Funktion RedirectCallback für benutzerdefinierte Authentifizierungsmodule ermöglicht zum Überprüfen eines Benutzers die Umleitung auf eine externe Website über die Authentifizierungsbenutzeroberfläche. Bei erfolgreicher Authentifizierung wird der Benutzer zurück zum ursprünglichen Access Manager-Server-URL umgeleitet. Folgende Beispieldateien gehören dazu:

So implementieren Sie diese Funktion

  1. Erstellen Sie mithilfe des Beispiels LoginModuleSample.java ein benutzerdefiniertes Authentifizierungsmodul.

  2. Laden Sie das Modul auf einen Access Manager-Server.

  3. Erstellen Sie RedirectCallback in der XML-Datei mithilfe des Beispiels LoginModuleSample.xml.

  4. Um das Modul zu testen, verwenden Sie die Beispieldatei testExtWebSite.jsp als externe Website.

  5. Melden Sie sich unter Verwendung des folgenden URLs an:

    http://example.com/amserver/UI/Login?module=LoginModuleSample

Der Benutzername und das Passwort werden zur Überprüfung auf die externe Website umgeleitet. Wenn Name und Passwort gültig sind, ist die Authentifizierung erfolgreich und der Benutzer wird zurück zum ursprünglichen Access Manager-Server-URL umgeleitet.

Im folgenden Beispielszenario wird in der Bereitstellung ein benutzerdefiniertes Authentifizierungsmodul für den Zugriff auf eine Geld-/Kreditkarten-Website verwendet:

  1. Ein Benutzer ruft die Authentifizierungs-/Anmeldeseite für das benutzerdefinierte Authentifizierungsmodul auf.

  2. Der Benutzer gibt seine Anmeldedaten (Benutzername und Passwort) ein und übermittelt eine Anforderung an das benutzerdefinierte Authentitfizierungsmodul.

  3. Das benutzerdefinierte Authentifizierungsmodul leitet den Benutzer zusammen mit den erforderlichen Benutzerangaben und der Anforderung auf eine externe Geld-/Kreditkarten-Website um.

  4. Die externe Geld-/Kreditkarten-Website überprüft den Benutzerstatus und gibt die Anforderung entweder als erfolgreich oder als nicht erfolgreich zurück. Der Status ist in der zurückgegebenen Anforderung festgelegt.

  5. Das benutzerdefinierte Authentifizierungsmodul überprüft den Benutzer basierend auf dem in Schritt 4 zurückgegebenen Status und gibt den Status an den Authentifizierungsdienst zurück.

  6. Die Benutzerauthentifizierung wird als erfolgreich oder als nicht erfolgreich abgeschlossen.

Federation schlägt bei Verwendung des Artefaktprofils fehl (6324056)

Umgehung: Um dieses Problem zu beheben, wenden Sie die für Ihre Plattform enstprechende aktuelle Version des Patches "Core Mobile Access" an:

Starten Sie nach Anwendung des Patches den Webcontainer neu.