test

Sun OpenSSO Enterprise 8.0, Versionshinweise

OpenSSO Enterprise 8.0-Probleme

Für weitere Informationen über Probleme mit OpenSSO Enterprise siehe:

https://opensso.dev.java.net/servlets/ProjectIssues

Webcontainer- und Serverprobleme

4077: Für die Konfiguration von OpenSSO Enterprise auf WebLogic Server ist eine neue ldapjdk.jar erforderlich

Fehlschlag der Konfiguration von OpenSSO Enterprise auf WebLogic Server, weil weblogic.jar eine ältere ldapjdk.jar-datei bündelt.

Sun bietet eine neue ldapjdk.jar-Datei an, die sicherheits- und leistungsbezogene Fixes enthält. Für WebLogic Server 9.2 und WebLogic Server 10 muss das folgende Workaround bereitgestellt werden.

Workaround. Die Sun ldapjdk.jar wie folgt vor der weblogic.jar in dem CLASSPATH, positionieren:

  1. Die ldapjdk.jar von der opensso.war mit dem folgenden Befehl in ein temporäres Verzeichnis extrahieren:

    jar xvf opensso.war WEB-INF/lib/ldapjdk.jar

  2. Die oben extrahierte ldapjdk.jar in das WebLogic lib-Verzeichnis kopieren.

    Beispiel für WebLogic Server 10 auf Solaris- oder Linux-Systemen: BEA_HOME /weblogic_10.0/server/lib

    Oder für WebLogic Server 9.2 auf Windows:BEA_HOME\weblogic92\server\lib

  3. Stellen Sie die Pfadangabe dieser ldapjdk.jar dem vorhandenen Klassenpfad als Präfix voran. indem Sie den zum Starten des WebLogic Servers verwendeten Startskript bearbeiten. In den folgenden Beispielen ist BEA_HOME der Installationsort des WebLogic Servers.

    Bei WebLogic 9.2 auf Windows wie folgt bearbeiten:

    BEA_HOME\weblogic92\samples\domains\wl_server\bin\startWebLogic.cmd

    Verändern Sie eingestellten CLASSPATH=%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH% in:

    set CLASSPATH=BEA_HOME\weblogic92\server\lib\ldapjdk.jar;%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH%

    Bei WebLogic 10 auf Windows wie folgt bearbeiten:

    BEA_HOME \wlserver_10.0\samples\domains\wl_server\bin\startWebLogic.cmd

    Ändern Sie eingestellten CLASSPATH=%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH% in:

    set CLASSPATH=
BEA_HOME\wlserver_10.0\server\lib\ldapjdk.jar;%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH%

    Bei WebLogic 9.2 MP2 auf Solaris oder Linux wie folgt bearbeiten:

    /bea/weblogic92/samples/domains/wl_server/bin/ startWebLogic.sh

    oder

    /usr/local/bea/user_projects/domains/base_domain/bin/startWebLogic.sh

    Ändern Sie CLASSPATH="${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}" in:


    CLASSPATH=
"BEA_HOME/weblogic92/server/lib/ldapjdk.jar${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}"

    Bei WebLogic 10 auf Solaris oder Linux wie folgt bearbeiten:

    /bea/wlserver_10.0/samples/domains/wl_server/bin/startWebLogic.sh

    oder

    /bea/user_projects/domains/wl10_domain/bin/startWebLogic.sh

    Ändern Sie CLASSPATH="${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}" in:

    CLASSPATH=
"BEA_HOME/wlserver_10.0/server/lib/ldapjdk.jar${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}"

  4. Starten Sie den Server neu.

  5. Konfiguration von OpenSSO Enterprise.

WebLogic Server StuckThreadMaxTime value is exceeded during configuration

Wenn Sie WebLogic Server 9.2 MP2 oder 10 unter Verwendung des Konfigurators konfigurieren und länger als 600 Sekunden zur Fertigstellung der Konfiguration benötigen, wird der folgende Fehler an das Terminal und die WebLogic Server-Domäne und die Serverprotokolle gemeldet:

<Error> <WebLogicServer> <BEA-000337> <[STUCK] Exe 
cuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy 
for "681" seconds working on the request "Http Request: /opensso/setup/setSetup 
Progress", which is more than the configured time (StuckThreadMaxTime) of "600" 
seconds. Stack trace: ...

Dieser Fehler tritt auf, weil der WebLogic Server seinen “Stuck Thread Max Time:” Vorgabewert von 600 Sekunden überschritten hat.

Workaround. Wenn der Konfigurator nicht reagiert, diesen neu starten. Ziehen Sie auch in Betracht, den WebLogic Server “Stuck Thread Max Time”-Wert von seinen vorgegebenen 600 Sekunden auf einen größeren Wert wie z. B. 1200 Sekunden einzustellen. Verwenden Sie zur Änderung dieses Wertes ( base_domain > Umgebung > Server > Admin Server > Konfiguration/Tuning ) die WebLogic Console.

4099: ID-WSF-Muster mit JDK 1.4 WAR führte zu Ausnahmefehlermeldung

Auf dem WebLogic Server 8.1 führte die für ID-WSF konfigurierte opensso-client-jdk14.war auf der Suche nach Wartung zu einer Fehlermeldung.

Workaround. Fügen Sie die folgenden JAR-Dateien ein unter weblogic-home/jdk142_08/jre/lib/: jax-qname.jar, namespace.jar, relaxngDatatype.jar , xalan.jar und xsdlib.jar.

Die xalan.jar-Datei befindet sich im WEB-INF/lib-Verzeichnis in opensso.war. Die anderen Dateien befinden sich in dem WEB-INF/lib -Verzeichnis in opensso-client-jdk14.war.

4094: Fehlschlag beim Setup von mehreren Servern, wenn das amadmin-Passwort und das Directory-Manager-Passwort zur Konfiguration des Datenspeichers nicht gleich sind

Dieses Problem tritt auf, wenn die folgenden Bedingungen erfüllt sind:

Workaround. Dieses Workaround besteht aus zwei Teilen:

  1. Stellen Sie sicher, dass Ihr Konfigurations-Server-Verbindungs-dn-Passwort dasselbe wie Ihr amadmin-Passwort ist.

  2. Konfigurieren Sie den zweiten, und zusätzliche OpenSSO Enterprise-Server. Zur Durchführung der Installation des zweiten Servers und Hinweisen auf das Konfigurationsverzeichnis des ersten OpenSSO Enterprise-Servers greifen Sie einfach auf die Konfiguratorseite des zweiten OpenSSO Enterprise-Servers zu und geben das amadmin-Passwort, die Cookie-Domäne und weitere Details für Schritt 1 und Schritt 2 ein.

    Bei Schritt 3 Folgendes nicht auswählen: Zu vorhandener Bereitstellung hinzufügen. Stattdessen die Option der ersten Instanz auswählen und denselben Directory Server-Namen, Port, DN, Passwort und Chiffrierschlüssel Ihres ersten Servers angeben. Dann wie gewöhnlich mit der Konfiguration fortfahren.

4055: Beim Hinzufügen einer erweiterten Eigenschaft in der Konsole trat ein Fehler auf

Das Hinzufügen einer erweiterten Eigenschaft in der Konsole veranlasste den OpenSSO Enterprise-Server zu einer Fehlermeldung. Dieses Problem kann nach dem Hinzufügen einer beliebigen erweiterten Konfigurationseigenschaft auftreten.

Workaround. Wenn Sie die standardmäßige Serverkonfiguration in Console ändern, ist ein Neustart des Webcontainers des OpenSSO Enterprise-Servers erforderlich.

3837: Fehlschlag der Konfiguration auf Oracle Application Server 10g

Mit Oracle Application Server 10g Version 10.1.3.1 als Webcontainer schlug die OpenSSO Express-Konfiguration mit einem Ausnahmefehler fehl.

Workaround. Fügen Sie vor der Konfiguration von OpenSSO die folgende JVM-Option zu “Server Properties” für die Zielserverinstanz des Oracle Application Servers 10g hinzu:

-Doc4j.jmx.security.proxy.off=true

2222: Passwortzurücksetzungs- und Kontensperrungsdienst-Mitteilungsfehler

OpenSSO Enterprise übermittelt E-Mail-Benachrichtigungen unter Verwendung des nicht berechtigten Absendernamens Identity-Server, der Fehlermeldungen in die Protokolle einträgt.

Workaround. Ändern Sie den Absendernamen von Identity-Server in den folgenden Dateien in Identity-Server@hostname.domainname um:

Datenspeicherprobleme

4102: TTL für die Konfiguration des Servicemanagements funktioniert nicht

Time to live (TTL) für die Konfiguration des Servicemanagements funktioniert nicht, weil die TTL-Eigenschaft nicht ordnungsgemäß initialisiert ist.

4085: OpenSSO Enterprise kann die CRL nicht im LDAP-Verzeichnis speichern

Nach dem Erhalt der Zertifikat-Widerrufliste (Certificate Revocation List) (CRL) von der CRL-Verteilungspunkterweiterung speichert OpenSSO Enterprise die CRL nicht im LDAP-Verzeichnis.

3827: Replikationskonfiguration hängt in der zweiten Glassfish-Instanz

Bei diesem Szenario wird OpenSSO Enterprise auf zwei Glassfish- (oder Application Server 9.1)-Instanzen auf Windows Vista Server bereitgestellt. Während der Konfiguration der zweiten OpenSSO Enterprise-Instanz hängt der Wiederruf der Konfiguration unter Verwendung der Option “Zu vorhandener Bereitstellung hinzufügen".

Workaround. Dieses Problem tritt weiterhin bei Windows Vista-Systemen auf. Bei anderen Windows-Systemen außer Vista fügen Sie die folgende Glassfish (oder Application Server 9.1) JVM-Option hinzu:

-Dcom.sun.enterprise.server.ss.ASQuickStartup=false

3350, 2867: LDAP Follows Referral sollte für Active Directory Data Store deaktiviert sein

Ein Active Directory-Datenspeicher führt manchmal zum Systemabsturz. Dieses Problem kann auch auftreten, wenn Sie einen neuen Active Directory-Datenspeicher erzeugen.

Workaround. In der OpenSSO Enterprise Admin Console LDAP Follows Referral für den Active Directory-Datenspeicher deaktivieren:

  1. Klicken Sie auf Zugriffssteuerung, Top-Level-Bereich , Datenspeicher, ActiveDirectory-Datenspeichername.

  2. Aktiviert für LDAP Follows Referral deaktivieren.

  3. Änderungen speichern.

Kein Failover beim Access Manager SDK (AMSDK) Plug-In

Wenn OpenSSO Enterprise mit dem AMSDK-Plug-In konfiguriert, und der Verzeichnisserver für MMR eingerichtet ist, tritt kein Failover ein, wenn eine Verzeichnisserverinstanz abstürzt.

Authentifizierungsprobleme

4103: Windows Desktop SSO-Authentifizierungsmodul gibt Fehlermeldung “Keine Konfiguration gefunden" aus

Wenn Sie ein Windows Desktop SSO-Authentifizierungsmodul konfigurieren, um eine Kerberos-Authentifizierung von Internet Explorer 6.0 auf Windows Server 2003 auszuführen, wird die Fehlermeldung “Keine Konfiguration gefunden" ausgegeben.

4100: Zertifikatauthentifizierung mit CRL-Prüfung fehlgeschlagen

Wenn Sie eine Zertifikatauthentifizierung konfigurieren und “Zertifikat mit CRL vergleichen" aktivieren, scheitert die Authentifizierung. Siehe auch das damit verwandte Problem 4085: OpenSSO Enterprise kann die CRL nicht im LDAP-Verzeichnis speichern.

4054: amadmin-Authentifizierung mit URL-org-Parameter nicht möglich

Wenn der OpenSSO Enterprise Admin (amadmin) einen neuen Bereich (wie z. B. myorg) erzeugt und später versucht, sich wie folgt in dem neuen Bereich anzumelden:

http://host:port/opensso/UI/Login?org=myorg

Gibt OpenSSO Enterprise eine Fehlermeldung Authentifizierung fehlgeschlagen aus.

Workaround. Als amadmin können Sie sich nur in dem Root-Bereich anmelden (und nur bei Data Store- oder Application-Modulen).

1781: amadmin-Anmeldung auf Grund von nicht erfolgter Data Store-Authentifizierung fehlgeschlagen

Wenn Sie das Authentifizierungsmodul für den Root-Bereich auf etwas außer 0DataStoreändern, kann sich amadmin nicht in der Console anzumelden.

Workaround. Anmeldung unter Verwendung von http://host.domain/deployurl/UI/Login?module=DataStore .

Richtlinienprobleme

3952: Richtlinienmusterverknüpfung für Servermuster fehlt

Die index.html unter host: port/uri/samples zeigt Folgendes an:

1. Authentication Samples
2. ID-FF Sample
3. SAMLv2 Sample
4. Multi-Federation Protocols Sample

Die folgende Verknüpfung zu den Richtlinienmustern fehlt jedoch in index.html : host:port/ uri/samples/policy/policy-plugins.html

Workaround: Öffnen Sie die host:port/uri/samples/policy/policy-plugins.html -Datei in Ihrem Browser.

3949: Für die OCSP-Prüfung ist das Hinzufügen einer Berechtigung für die server.policy-Datei notwendig

Zur Aktivierung der OCSP-Prüfung für einen OpenSSO-Webcontainer mit aktiviertem Java Security Manager die folgende Berechtigung zu der server.policy (oder gleichwertigen) Datei hinzufügen:

permission java.security.SecurityPermission "getProperty.ocsp.*";

3796: Erzeugung von Fedlet in der Konsole in einem Console Only Deployment fehlgeschlagen

Bei der Erzeugung eines Console Only Deployment ist die Erzeugung eines Fedlets unter Verwendung der Console Common Tasks mit einer Fehlermeldung fehlgeschlagen, dass keine solche Datei oder Verzeichnis für sp-extended.xml vorhanden war. Die com.iplanet.services.configpath -Eigenschaft wurde nicht durch den Nur-Konsolen-Konfigurator eingestellt.

Workaround. Die AMConfig.properties -Datei bearbeiten und die com.iplanet.services.configpath-Eigenschaft auf das Konfigurationsverzeichnis einstellen. Beispiel:

com.iplanet.services.configpath=/consoleonly

2381: Access Manager Roles-Richtliniensubjekt wird nur mit Access Manager-Repository-Datenspeicher unterstützt

Access Manager Roles-Richtliniensubjekt wird nur mit Access Manager-Repository (AMSDK)-Datenspeicher unterstützt Dieses Subjekt ist in der Richtlinienkonfiguration standardmäßig deaktiviert. Deshalb das Access Manager Roles-Richtliniensubjekt nur aktivieren, wenn der Datenspeichertyp zur Verwendung mit dem AMSDK-Plug-In konfiguriert ist.

Für weitere Informationen siehe Kapitel 14, Enabling the Access Manager SDK (AMSDK) Identity Repository Plug-in in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.

Sitzungsprobleme

3910: setup.bat of ssoSessionTools.zip kann Tools nicht installieren

Nach dem Entpacken von ssoSessionTools.zip, dem Ausführen der setup.bat kann das Skript die Sitzungsskripts nicht installieren und gibt folgende Fehlermeldung aus:

Keine die Spezifikation "1.4+" erfüllende JRE auffindbar

Workaround. In dem setup.bat -Skript -version:"1.4+" von dem java.exe-Befehl entfernen und das Skript erneut ausführen.

2827: Durch die Konfiguration einer Site wird der zweite Server nicht zu der Site hinzugefügt

Sitzungs-Failover-Konfiguration fügt die zweite OpenSSO Enterprise-Instanz nicht zu der Liste der zugewiesenen Server hinzu.

Workaround. Die OpenSSO Enterprise Console oder das ssoadm-Dienstprogramm verwenden, um die zweite Serverinstanz manuell zu der Serverliste hinzuzufügen.

Probleme mit den Befehlszeilendienstprogrammen

4079: ssoadm import-svc-cfg-Befehl nicht möglich, wenn Directory Server als Konfigurationsdatenspeicher verwendet wird

Manchmal schlägt der import-svc-cfg-Unterbefehl fehl, weil OpenSSO Enterprise Knoten im Service Manager-Datenspeicher nicht löschen kann. Dieses Problem kann durch die folgenden Szenarios verursacht werden:

  1. OpenSSO Enterprise unter Verwendung eines entfernten Sun Java System Directory Servers als Konfigurationsdatenspeicher konfigurieren.

  2. Exportieren Sie die Dienst-XML-Datei unter Verwendung des ssoadm export-svc-cfg -Befehls.

  3. Reimportieren Sie die erhaltenen Dienst-XML-Daten in Schritt 2 unter Verwendung des ssoadm import-svc-cfg-Befehls.

  4. Bei Aufforderung zum Löschen der vorhandenen Daten "Ja" auswählen.

    Die folgende Fehlermeldung wird angezeigt: Unerwarteter LDAP-Ausnahmefehler.

Workaround. Den ssoadm import-svc-cfg-Befehl erneut ausführen, bis die Ausführung erfolgreich ist.

3955: ssoadm-Befehl nicht ausführbar

Sie können den ssoadm-Befehl mit get-realm auf Grund dieses Ausnahmefehlers nicht ausführen.

Logging configuration class "com.sun.identity.log.s1is.LogConfigReader" failed
com.sun.identity.security.AMSecurityPropertiesException: AdminTokenAction:
FATAL ERROR: Cannot obtain Application SSO token.
Check AMConfig.properties for the following properties
       com.sun.identity.agents.app.username
       com.iplanet.am.service.password
Logging configuration class "com.sun.identity.log.s1is.LogConfigReader" failed
com.sun.identity.security.AMSecurityPropertiesException: AdminTokenAction:
FATAL ERROR: Cannot obtain Application SSO token.
Check AMConfig.properties for the following properties
       com.sun.identity.agents.app.username
       com.iplanet.am.service.password
AdminTokenAction:  FATAL ERROR: Cannot obtain Application SSO token.
Check AMConfig.properties for the following properties
       com.sun.identity.agents.app.username
       com.iplanet.am.service.password

Prüfen, ob sich das amadmin-Passwort von dem Directory-Manager-Passwort für den Service Management-Datenspeicher unterscheidet. Wenn ja, das folgende Workaround anwenden.

Workaround. Die Serverkonfigurations-XML wie folgt ändern:

  1. Bei OpenSSO Console als amadmin anmelden.

  2. Verwenden Sie ssoadm.jsp get-svrcfg-xml, um die Serverkonfigurations-XML zu erhalten.

  3. Verwenden Sie encode.jsp zur Codierung des amadmin-Passworts.

  4. Setzen Sie das codierte Passwort in die zwei Orte ein, die durch amadmin-password im XML dargestellt werden. Beispiel:

    <User name="User1" type="proxy">
            <DirDN>
                cn=puser,ou=DSAME Users,dc=opensso,dc=java,dc=net
            </DirDN>
            <DirPassword>
               amadmin-password
            </DirPassword>
        </User>
        <User name="User2" type="admin">
            <DirDN>
                cn=dsameuser,ou=DSAME Users,dc=opensso,dc=java,dc=net
            </DirDN>
            <DirPassword>
               amadmin-password
            </DirPassword>
        </User>
        <BaseDN>
            dc=opensso,dc=java,dc=net
        </BaseDN>
    </ServerGroup>

  5. Verwenden Sie ssoadm.jsp get-svrcfg-xml, um die abgeänderte Serverkonfigurations-XML zu setzen.

2905: jss4.jar-Eintrag fehlt im ssoadm Klassenpfad

Nach dem Ausführen des Setup-Skripts für das ssoadm-Dienstprogramm wird bei dem Versuch, ssoadm auszuführen, eine NoClassDefFoundError-Fehlermeldung angezeigt. Dieses Problem tritt bei einer aktualisierten OpenSSO Enterprise-Instanz auf.

Workaround. Zur Verwendung von JSS fügen Sie jss4.jar zu dem Klassenpfad hinzu und setzen Sie die LD_LIBRARY_PATH -Umgebungsvariable. (Bei Verwendung der standardmäßigen JCE muss sich die jss4.jar nicht im Klassenpfad befinden.)

Client-SDK-Probleme

4081: SMS-Cache auf dem Client SDK standardmäßig deaktiviert

Für eine Client SDK-Installation ist der Service Management Service (SMS)-Cache standardmäßig deaktiviert.

Workaround: Für Web Services Security (WSS)-Anwendungen com.sun.identity.sm.cache.enabled=false in der AMConfig.properties-Datei einstellen, da das Fix für Problem 3171 sonst nicht funktioniert.

Für alle weiteren SDK-Anwendungen com.sun.identity.sm.cache.enabled=true in der AMConfig.properties-Datei einstellen, um SMS-Zwischenspeicherung zu aktivieren, wodurch Leistungsprobleme vermieden werden können.

4080: Der Client SDK-Konfigurator positioniert das falsche gemeinsame Geheimnis in der AMConfig.properties-Datei

Der Client SDK-Konfigurator positioniert das falsche gemeinsame Geheimnis in der AMConfig.properties-Datei

Workaround. Kopieren Sie den gemeinsamen geheimen Wert und den Passwortverschlüsselungsschlüssel von dem OpenSSO Enterprise-Server zu der SDKAMConfig.properties-Datei in dem $HOME/OpenSSOCLient-Verzeichnis.

Verbund- und SAML-Probleme

3923: Erzeugung einer Entity (IDP oder SP) der Seite Allgemeine Konsolenaufgaben schlägt auf dem Oracle Application Server fehl

Mit einem auf Oracle Application Server bereitgestellten OpenSSO Enterprise verursacht die Erzeugung einer Entity (IDP oder SP) in der Seite Allgemeine Konsolenaufgaben einen Ausnahmefehler.

Workaround. Bei Bereitstellung von opensso.war auf Oracle Application Server die Importoption für die oracle.xml-Datei in der Bereitstellungsplanansicht deaktivieren (Bereitstellen: Bereitstellungseinstellungen > Laden von Klassen konfigurieren > oracle.xml).

3065: Für alle Benutzer in den ID-FF-Protokolldatensätzen wird dieselbe Kontext-ID verwendet

Alle ID-FF-Protokolldatensätze haben dieselbe Kontext- (oder Anmelde-) ID, auch wenn diese für verschiedene Benutzer sind.

2661: logout.jsp wurde auf dem WebSphere Application Server 6.1 nicht kompiliert

Die logout.jsp-Datei erfordert JDK 1.5, doch die JDK-Quellenebene für JSP-Dateien ist auf dem IBM WebSphere Application Server 6.1 auf JDK 1.3 eingestellt.

Workaround. Siehe Workaround für 1977: SAMLv2 sample configure.jsp-Dateien auf WebSphere Application Server 6.1 fehlgeschlagen.

1977: SAMLv2 sample configure.jsp-Dateien auf WebSphere Application Server 6.1 fehlgeschlagen

Auf einer WebSphere Application Server 6.1-Instanz ist bei den /sample/saml2/sp/configure.jsp und /sample/saml2/idp/configure.jsp-Dateien die Kompilierung fehlgeschlagen. Die logout.jsp-Dateien erfordern JDK 1.5, doch die JDK-Quellenebene für JSP-Dateien ist auf dem WebSphere Application Server 6.1 auf JDK 1.3 eingestellt.

Workaround: Die JSP-Engine-Konfigurationsparameter bearbeiten, um die JDK-Quellenebene auf 1.5 einzustellen:

  1. Die WEB-INF/ibm-web-ext.xmi-Datei öffnen.

    Die JSP-Engine-Konfigurationsparameter werden entweder im Konfigurationsverzeichnis eines Webmoduls oder in dem Binärdateienverzeichnis eines Webmoduls in der WEB-INF/ibm-web-ext.xmi-Datei gespeichert:

    Konfigurationsverzeichnis. Beispiel:

    {WAS_ROOT}/profiles/profilename/config/cells/cellname/applications/
enterpriseappname/deployments/deployedname/webmodulename/

    Binärdateienverzeichnis, wenn eine Anwendung in dem WebSphere Application Server bereitgestellt wurde, und das Flag “Binärkonfiguration verwenden" auf true eingestellt war. Beispiel:

    {WAS_ROOT}/profiles/profilename/installedApps/nodename/
enterpriseappname/webmodulename/

  2. Den compileWithAssert-Parameter löschen, indem entweder die Anweisung aus der Datei gelöscht wird, oder durch Einschließen der Anweisung mit Comment Tags (<!— und –>).

  3. Den jdkSourceLevel-Parameter mit dem Wert 15 hinzufügen. Beispiel:

    <jspAttributes xmi:id="JSPAttribute_1" name="jdkSourceLevel" value="15"/>

    Hinweis: Die Ganzzahl (_1) in JSPAttribute_1 muss innerhalb der Datei einmalig sein.

  4. Die ibm-web-ext.xmi-Datei speichern.

  5. Die Anwendung neu starten.

Für weitere Informationen über den jdkSourceLevel-Parameter sowie weitere JSP-Engine-Konfigurationsparameter siehe:

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/rweb_jspengine.html

Web Services Security (WSS)-Probleme

4057: Dynamische Webdienstanbieterkonfiguration mit Endpunkt ist nicht wirksam

Wenn Sie das Proxy-Fallbeispiel auf der Grundlage der Loan-Musteranwendung für Web Services Security (WSS) einrichten und zwei Web Service Provider (WSP) mit anderen Profilnamen als wsp erzeugen, tritt ein Fehler auf.

Workaround. Für JAX-WS/Webanwendungen, die auf Webdiensten basieren, das statische Punktende als WSP-Namen zur Unterstützung mehrerer Webdienste verwenden. Für Webdienste auf EJB-Basis die standardmäßige WSP-Konfiguration verwenden.

Upgrade-, Kompatibilitäts- und Koexistenzprobleme

4108: Nach der Konfiguration von OpenSSO Enterprise wurde ein inkorrekter Chiffrierschlüssel entgegen dem vorhandenen Schema (DIT) verwendet

Nach der Konfiguration von OpenSSO Enterprise entgegen dem vorhandenen Schema (DIT) können Sie sich nicht bei der Konsole anmelden, da der während der Konfiguration eingegebene Chiffrierschlüssel (derjenige von der alten Access Manager- oder Federation Manager-Instanz) nicht verwendet wird. Stattdessen wird ein neuer Chiffrierschlüssel erzeugt, der eine inkorrekte serverconfig.xml-Datei generiert.

Workaround.

  1. Wechseln Sie in das config-Verzeichnis von OpenSSO Enterprise.

  2. Ändern Sie den Chiffrierschlüssel in der AMConfig.properties-Datei mit dem korrekten Wert.

  3. Kopieren Sie die Sicherungskopie von serverconfig.xml von der vorherigen Access Manager- oder Federation Manager-Instanz.

  4. OpenSSO Enterprise-Server neu starten.

3962: Nach Authentifizierung für Nicht-Administrator-Benutzer wurde eine inkorrekte Console URL zurückgegeben

Wenn OpenSSO mit einem Access Manager 7.1 Directory Server-Schema (DIT) im Koexistenzmodus konfiguriert ist, und sich ein Nicht-Administrator-Benutzer an der OpenSSO Console anmeldet, wird der Benutzer zu einer ungültigen URL weitergeleitet. Beispiel:

http://ssohost.example.com:8080/amserver/..amserver/base/AMAdminFrame .

Workaround. URL wie folgt bearbeiten:

protocol://host. domain:port/deploy_uri/idm/EndUser

Beispiel:

http://ssohost.example.com:8080/amserver/idm/EndUser

3961: amadmin kann sich im Koexistenzmodus nicht bei OpenSSO Console anmelden

Wenn OpenSSO mit einem Access Manager 7.1 Directory Server-Schema (DIT) im Koexistenzmodus konfiguriert ist, schlägt ein Anmeldeversuch als amadmin bei der Console unter Verwendung der LDAP-Authentifizierung fehl.

Workaround. Beim Anmelden als amadmin bei der OpenSSO Console im Koexistenzmodus fügen Sie den module=DataStore -Abfrageparameter hinzu. Beispiel:

protocol://host. domain:port/deploy_uri/UI/Login/?module=DataStore

Beispiel:

http://ssohost.example.com:8080/amserver/UI/Login/?module=DataStore

2348: Document Distributed Authentication UI-Serverunterstützung

Die OpenSSO Enterprise Distributed Authentication UI-Serverkomponente funktioniert nur mit OpenSSO Enterprise. Die folgenden Szenarios werden nicht unterstützt:

830: ID-FF-Schema-Metadaten sind nicht abwärtskompatibel

Wenn Sie ein Upgrade von einer früheren Version von Access Manager oder Federation Manager auf OpenSSO Enterprise 8.0 durchführen, funktionieren ID-FF-Profile nur dann, wenn Sie auch ein Upgrade für das Access Manager- oder Federation Manager-Schema durchführen.

Workaround. Führen Sie vor dem Ausprobieren der ID-FF-Profile ein Upgrade des Access Manager- oder Federation Manager-Schemas durch. Für weitere Informationen über ein Upgrade des Schemas siehe Sun OpenSSO Enterprise 8.0 Upgrade Guide .

Internationalisierungsprobleme

4090: Nicht-Englische Berechtigungen werden unkenntlich gemacht

Workaround: Verwenden Sie zum Anzeigen der lokalisierten Berechtigungen, die im .txt-Format vorliegen, einen Browser, wobei die die Verschlüsselung in dem Browser für jeden locale wie folgt angegeben ist:

4051: Multibyte-Name eines vertrauenswürdigen Partners wird in Console unkenntlich gemacht

Wenn Sie in OpenSSO Console zu Federation > SAML1.x-Konfiguration gehen und dann einen neuen Trusted Partner mit einem Multibyte-Namen im Abschnitt Common Settings gehen, wird der Name des vertrauenswürdigen Partners unkenntlich gemacht.

3993: Endbenutzerseite zeigt Fragezeichen für CCK- und JA-locales

Wenn Sie sich am Geronimo Webcontainer in CCK- und JA-locales als ein anderer Benutzer als amadmin anmelden, zeigen Access Control, realm, General, EndUser page (http:// host:port/deployuri/idm/EndUser ) Fragezeichen an.

3976: Onlinehilfe “Tipps zur Suche” hat einen 404-Fehler an einem Nicht-Englischen locale zur Folge

Wenn Sie sich bei OpenSSO Console an einem Nicht-Englischen locale wie z. B. bei Französisch anmelden, auf Hilfe und dann auf “Tipps zur Suche” klicken, zeigt das rechte Hilfefeld eine 404-Fehlermeldung an.

Workaround. Zur Anzeige von “Tipps zur Suche” auf Englisch legen Sie als Browsersprache Englisch fest und aktualisieren Sie das Fenster der Onlinehilfe

3763: Einige Nicht-ASCII-Zeichen werden verschlüsselt, wenn sich der Webcontainer am C-locale befindet

Wenn Sie den Webcontainer am C-locale starten und in Ihrem Browser eine Sprache wie z. B. Französisch festlegen, werden nach Ihrer Anmeldung bei der Admin Console einige Zeichen unkenntlich gemacht.

3713: Passwort-Zurücksetzungsseite wird für CCJK-locales nicht lokalisiert

Für CCJK-locales wird die Passwort-Rücksetzungsseite (http://host :port/deployuri/password ) nicht lokalisiert.

3590: Standort für dounix_msgs.po-Dateien ändern

Die dounix_msgs.po-Dateien für das Unix-Authentifizierungsmodul wurden nicht übersetzt, da das Unix-Authentifizierungsmodul in einer zukünftigen OpenSSO Enterprise-Version nicht enthalten sein wird. Siehe Überarbeitungsmitteilungen und -ankündigungen

1793: Authentifizierung schlägt mit Multibyte-Zeichen für org oder Modul in Abfrageparameter fehl

Wenn Sie versuchen, sich bei OpenSSO Console unter Verwendng der org oder Modul -Parameter mit Zeichen anzumelden, die nicht UTF-8 entsprechen, schlägt die Anmeldung fehl. Beispiel: http://host:port/ deployuri/UI/Login?module=Japanese-string&gx_charset=UTF-8

Workaround. Verwenden Sie UTF-8 URL-Verschlüsselungszeichen wie z. B. %E3%81%A6 anstatt nativer Zeichen.

Lokalisierungsprobleme

4017: An spanischen locales wird “2.2 Agents” nur als Agentes in Console übersetzt

Wenn sich OpenSSO Console an einem spanischen locale befindet, fehlt 2.2 bei der Übersetzung von “2.2 Agents”.

3994: An spanischen locales ist der Zugriff auf Zertifikat für Konfiguration > Authentifizierung nicht möglich

Wenn sich OpenSSO Console an einem spanischen locale befindet, wird beim Klicken auf Konfiguration, Authentifizierung und dann Zertifikat eine Fehlermeldung angezeigt.

3971: An chinesischen (zh_CN) locales ist die Onlinehilfe auf Englisch

An dem chinesischen (zh_CN) locale. wird der Console-Onlinehilfetext auf Englisch, und nicht auf Chinesisch angezeigt. Wenn Sie als Ihre bevorzugte Browsersprache zh_CN festlegen, wird nur der Onlinehilfetext im linken Strukturbaum auf Englisch angezeigt. Wenn Sie als Ihre bevorzugte Browsersprache zh festlegen, wird der gesamte Onlinehilfetext auf Englisch angezeigt.

Workaround. Kopieren Sie die zh_CN Onlinehilfeinhalte in ein neues zh-Verzeichnis im webapps-Verzeichnis des Webcontainers und führen Sie einen Neustart des Webcontainers durch.

Kopieren Sie z. B. für Tomcat /Tomcat6.0.18/webapps/opensso/html/zh_CN/* in ein neues Verzeichnis mit der Bezeichnung /Tomcat6.0.18/webapps/opensso/html/zh/ . Und führen Sie dann einen Neustart des Tomcat-Containers durch.

3802: Probleme im französischen Teil des Copyright-Hinweises

Im französischen Teil des englischen Copyright-Hinweises fehlt bei “Etats-unis” ein Akzent, ein Leerzeichen fehlt nach dem Komma bei “armes nucléaires,des missiles”, und innerhalb von “Etats - Unis” sollte sich kein Leerzeichen befinden.