Datum der letzten Überarbeitung/Veröffentlichung;
SunTM OpenSSO Enterprise 8.0 ist Teil des OpenSSO-Projekts (http://opensso.org/) und ist die kommerzielle Version des OpenSSO Servers von Sun.
Diese Versionshinweise gelten auch für Sun OpenSSO Express. Bei OpenSSO Enterprise und OpenSSO Express handelt es sich im Wesentlichen um dasselbe Produkt, jedoch mit den folgenden Unterschieden:
Von OpenSSO Enterprise wird etwa alle 12 Monate eine neue Version herausgegeben, die von der Abteilung Sun QA Engineering intensiv automatisiert und manuell getestet wird, und wofür regelmäßig Patches und Hotfixes geliefert werden.
Von OpenSSO Express wird etwa alle drei Monate eine neue Version herausgegeben, die von der Abteilung Sun QA Engineering intensiv automatisiert und manuell getestet wird, wofür jedoch keine Patches und Hot Fixes geliefert werden. Für weitere Informationen siehe OpenSSO Express FAQs: https://opensso.dev.java.net/public/about/faqcenter/SupportFAQ.html.
Wenn Sie WebLogic Server als Webcontainer zur Bereitstellung des OpenSSO Enterprise-Servers verwenden, siehe 4077: Für die Konfiguration von OpenSSO Enterprise auf WebLogic Server ist eine neue ldapjdk.jar erforderlich.
Inhalt
Erforderliche Hardware und Software für OpenSSO Enterprise 8.0
Vorgehensweise bei der Mitteilung von Problemen und Bereitstellung von Feedbacks
Wenn Sie OpenSSO Enterprise bisher noch nicht installiert hatten, führen Sie folgende Grundschritte aus:
Wenn nötig, einen der Webcontainer mit Unterstützung für OpenSSO Enterprise 8.0, installieren, konfigurieren und ausführen.
Die Datei opensso_enterprise_80.zip von einer der folgenden Sites herunterladen:
Stellen Sie die Datei opensso.war für den Webcontainer bereit, indem Sie die Webcontainer-Administrationskonsole oder den Bereitstellungsbefehl verwenden.
Oder, wenn dies durch den Webcontainer unterstützt wird, einfach die WAR-Datei in das Autodeploy Directory des Containers kopieren.
Konfigurieren Sie OpenSSO Enterprise entweder unter Verwendung des GUI-Konfigurators oder des Befehlszeilen-Konfigurators.
Zum Starten des GUI-Konfigurators die folgende URL in Ihren Browser eingeben: protocol:// host.domain:port/ deploy_uri
Beispiel: http://openssohost.example.com:8080/opensso
Wenn OpenSSO Enterprise auf ein Access Manager 7.1-Schema (DIT) im Koexistenzmodus zugreift, siehe 3961: amadmin kann sich im Koexistenzmodus nicht bei OpenSSO Console anmelden.
Führen Sie jede zusätzliche Konfiguration entweder unter Verwendung der Administration Console oder des neuen ssoadm-Befehlszeilen-Dienstprogramms aus.
Zum Herunterladen eines Richtlinienagenten (Policy Agent) Version 3.0 siehe https://opensso.dev.java.net/public/use/index.html.
Die OpenSSO Enterprise 8.0-Dokumentation ist über die folgende Site erhältlich:
http://docs.sun.com/coll/1767.1
Schauen Sie von Zeit zu Zeit auf dieser Seite nach der neuesten Dokumentation.
OpenSSO Enterprise 8.0 enthält Funktionen wie z. B. Zugriffs-Management, Federation Management und Webdienstsicherheiten, die in früheren Versionen von Sun Java System Access Manager und Sun Java System Federation Manager zu finden sind. OpenSSO Enterprise enthält auch die in diesem Abschnitt beschriebenen neuen Funktionen.
Die neuen Funktionen in Version 3.0 der Richtlinienagenten finden Sie in einem dieser Handbücher:
Sun OpenSSO Enterprise Policy Agent 3.0 User’s Guide for J2EE Agents
oder
Sun OpenSSO Enterprise Policy Agent 3.0 User’s Guide for Web Agents
Einfache Installation und Konfiguration:
Zur Installation von OpenSSO Enterprise einfach die opensso.war -Datei unter Verwendung der jeweiligen Webcontainer-Administrationskonsole oder des Befehlszeilen-Dienstprogramms bereitstellen. Wenn Sie das erste Mal unter Verwendung der Bereitstellungs-URI (/opensso) auf den Server zugreifen, werden Sie zu dem Konfigurator weitergeleitet, der Ihnen die Ausführung der Erstinstallationsaufgaben wie z. B. der Angabe von Administratorpasswörtern und bei der Konfiguration und von Benutzerdatenspeichern ermöglicht.
Sie können auch WAR-Dateien für einen UI Server für verteilte Authentifizierung, nur Konsole, nur Server, und Identity Provider (IDP) Discovery Service-Bereitstellungen unter Verwendung der opensso.war-Datei erzeugen und bereitstellen.
Zentralisierte Server- und Agentkonfigurationsdaten:
Die Konfigurationsdaten von OpenSSO Enterprise und Richtlinienagent Version 3.0 sind in einem zentralisierten Konfigurationsdaten-Repository gespeichert. Sie geben Konfigurationswerte an, indem Sie entweder die OpenSSO Enterprise Administration Console oder das neue ssoadm-Befehlszeilen-Dienstprogramm verwenden. Es ist nicht mehr erforderlich, Eigenschaften in den AMConfig.properties oder AMAgent.properties -Dateien einzustellen.
Viele der Konfigurationseigenschaften sind nun "hot swappable" (im laufenden Betrieb austauschbar), was bedeutet, dass der Webcontainer nach Veränderung einer Eigenschaft nicht mehr neu gestartet werden muss.
Die Speicheroption für eingebettete Daten ermöglicht Ihnen eine transparente Speicherung der Konfigurationsdaten von OpenSSO Enterprise und Richtlinienagent Version 3.0, ohne Sun Java System Directory Server installieren zu müssen.
Der Command-line Configurator dient (zusätzlich zu dem GUI Configurator) zur Ausführung der Erstinstallation des OpenSSO Enterprise-Servers.
Allgemeine Aufgaben der OpenSSO Enterprise Administrationskonsole:
SAMLv2-Anbieter erstellen. Sie können leicht einen SAMLv2-gehosteten oder einen entfernten Identity Provider (IDP) oder Service Provider (SP) erstellen.
Ein Fedlet erstellen. Ein Fedlet ist eine Lightweight-Service Provider (SP)-Implementierung von SAMLv2 SSO-Protokollen. Ein Fedlet ermöglicht einem Identity Provider (IP) die Aktivierung eines SPs, der über keinen implementierten Verbund verfügt. Der SP fügt das Fedlet einfach einer Java-Webanwendung hinzu und stellt dann die Anwendung bereit.
Verbundkonnektivität testen. Sie können neue oder vorhandene, verbundene Bereitstellungen testen oder deren Probleme lösen um festzustellen, ob Verbindungen erfolgreich hergestellt werden, und um die Quelle von Problemen zu identifizieren.
Das Hinzufügen neuer Webcontainer erfolgt wie in Webcontainer mit Unterstützung für OpenSSO Enterprise 8.0 beschrieben.
Vereinfachte Webdienstsicherheits-Agenten können auf Glassfish und Sun Java System Application Server 9.1 unter Verwendung von Anbietern auf der Grundlage von JSR 196 SPI bereitgestellt werden.
WS-Federation unterstützt die Identity Federation-Spezifikation. OpenSSO Enterprise unterstützt insbesondere das WS-Federation Passive Requestor Profile.
Support für XACML Version 2.0-Support wird hinzugefügt, insbesondere für XACMLAuthzDecisionQuery und XACMLAuthzDecisionStatement , wie im SAML 2.0-Profil von XACML v2.0 angegeben.
Durch Secure Authentication und Attribute Exchange wird es einer Anwendung ermöglicht, Benutzerauthentifizierung und Attributinformationen mit sicheren Übertragungen zwischen IDP- und SP-Anwendungen bereitzustellen.
Durch das Multi-Federation Protocol Hub wird es einem OpenSSO Enterprise IDP ermöglicht, als Verteilungs-Hub zu agieren, um Single Logout unter unterschiedlichen Verteilungsprotokollen auszuführen (wie z. B. SAMLv2, ID-FF und WS-Federation).
SAMLv2-Profilunterstützung umfasst IDP-Bevollmächtigung, Affiliation, NameID-Zuordnung, ECP, Authentication Query und Attribute Query.
Security Token Service (STS) ist erhältlich über Webcontainer mit Unterstützung für OpenSSO Enterprise 8.0.
SAMLv2-Bestätigungsanweisungs-Failover wird unterstützt.
Das neue Befehlszeilen-Dienstprogramm (ssoadm) kann OpenSSO Enterprise-Server und Richtlinienagenten Version 3.0 konfigurieren.
Es wird eine Integration mit Sun Identity Manager, SiteMinder und Oracle Access Manager hinzugefügt.
Unterstützung für Service Tags. Siehe Verwendung von Service Tags mit Sun Inventory.
Der Distributed Authentication UI Server umfasst einen Konfigurator der es Ihnen ermöglicht, Erstinstallationsaufgaben wie z. B. die Angabe des OpenSSO Enterprise-Servers und die Bereitstellung des Distributed Authentication UI Serverbenutzers und des Passwortes auszuführen.
Ein Distributed Authentication UI Server bietet auch Unterstützung für Cross Domain Single Sign-On (CDSSO).
Internationalisierungs- und Lokalisierungsänderungen umfassen Folgendes:
Außer Englisch enthält OpenSSO Enterprise auch eine Unterstützung für Französisch, Spanisch, Deutsch, Japanisch, Koreanisch, Vereinfachtes Chinesisch und Traditionelles Chinesisch.
Lokalisierte Dateien sind standardmäßig in der opensso.war-Datei gepackt (anders als bei Access Manager 7 2005Q4 und Access Manager 7.1, wo lokalisierte Dateien in separaten lokalisierten Paketen resident sind.
Unix, SecurID und SafeWord Authentifizierungsmodule sind in OpenSSO Enterprise und Express Versionen verfügbar. SecurID ist nun ein Authentifizierungsmodul auf Java-Basis.
Upgrade-Support umfasst Folgendes:
Upgrade auf OpenSSO Enterprise 8.0 von Access Manager 6.3, 7.0 oder 7.1 und Federation Manager 7.0
Richtlinienagent, Upgrade auf Version 3.0 von Agenten der Version 2.2
OpenSSO 8.0 ist Service Tag-aktiviert, wodurch es Ihnen ermöglicht wird, Sun Inventory zur Verfolgung und Organisation Ihres OpenSSO-OProduktes zu verwenden (sowie andere Hardsware- und Softwareprodukte). Vor der Verwendung von Service Tags zuerst das Produkt registrieren. Sie können OpenSSO Enterprise, OpenSSO Express oder sogar ein Nightly Build registrieren.
Zur Registrierung benötigen Sie einen Sun Online Account (SOA) oder Sun Developer Network (SDN)-Konto. Wenn Sie über keines dieser Konten verfügen, können Sie während des Produktregistrierungsprozesses ein Konto eröffnen.
Zur Registrierung Ihres OpenSSO-Produktes und um mit der Verwendung von Service Tags zu beginnen, die folgenden Schritte ausführen:
Anmelden bei OpenSSO Admin Console als amadmin.
In der Konsole unter Allgemeine Aufgaben auf Dieses Produkt registrieren klicken.
Wenn Sie über kein SOA- oder SDN-Konto verfügen, stellen Sie die Informationen für ein neues Konto bereit.
Registrieren anklicken.
Service Tag-Registrierungsdateien sind in dem config-directory /deployuri/lib/registration-Verzeichnis gespeichert. Beispiel: opensso-config/opensso/lib/registration.
Weitere Informationen finden Sie unter:
Sun Inventory: https://inventory.sun.com/inventory/
Service Tags FAQs: http://servicetags.central/faq.html
Konsultieren Sie diese Sites um zu erfahren, ob Service Tags auf ihrer spezifischen Plattform unterstützt wird, oder ob zuerst ermittelt werden muss, ob ein bestimmter OpenSSO Server bereits registriert ist.
Bei der in diesem Abschnitt beschriebenen erforderlichen Hardware und Software für OpenSSO Enterprise 8.0 handelt es sich um die einzigen Umgebungen, worin sie mit vollem Support von Sun Microsystems bereitgestellt werden können. Für nicht mit den aufgeführten Anforderungen übereinstimmende Umgebungen ist keine Unterstützung verfügbar.
Sun Microsystems übernimmt keine Verantwortung oder Haftung für Umgebungen, die nicht der in der Dokumentation aufgeführten erforderlichen Hardware und Software für OpenSSO Enterprise 8.0 entsprechen. Sun empfiehlt Ihnen dringend, sich an die professionellen Dienste von Sun Professional wenden, bevor Sie mit dem Installations- und Bereitstellungsprozess beginnen. Dadurch können für Sie zusätzliche Kosten anfallen.
Plattform |
Unterstützte Webcontainer |
---|---|
Solaris 10 OS auf SPARC, x86 und Systemen auf x64-Basis Solaris 9 OS auf SPARC und x86-Systemen |
Alle Webcontainer mit Unterstützung für OpenSSO Enterprise 8.0 außer Geronimo Application Server 2.1.1 nur mit Tomcat |
OpenSolaris |
Glassfish Application Server V2 UR1 und UR2 Apache Tomcat 6.0.18 |
Red Hat Enterprise Linux 5 (Base und Advanced Platform, 64–Bit auf AMD Servern) Red Hat Enterprise Linux 4 Server (Base und Advanced Platform, 64–Bit auf AMD Servern) |
Alle Webcontainer mit Unterstützung für OpenSSO Enterprise 8.0 außer Geronimo |
Ubuntu 8.0.4 |
Glassfish Application Server V2 UR1 und UR2 Apache Tomcat 6.0.18 |
Windows Server 2003 Standard Edition Windows Server 2003 Enterprise Edition Windows Server 2003 Datacenter Edition |
Alle Webcontainer mit Unterstützung für OpenSSO Enterprise 8.0 außer Geronimo |
Windows Server 2003 R2 auf 64–Bit Servern |
Alle Webcontainer mit Unterstützung für OpenSSO Enterprise 8.0 |
Windows XP Windows Vista |
Alle Webcontainer mit Unterstützung für OpenSSO Enterprise 8.0 außer Oracle Server, JBoss Application Server und Geronimo |
Windows 2008 Server |
Glassfish Application Server V2 UR1 und UR2 Apache Tomcat 6.0.18 |
IBM AIX 5.3 |
IBM WebSphere Application Server 6.1 |
Hinweise:
|
Webcontainer |
Überlegungen |
---|---|
Sun Java System Application Server 9.1 Update 1 und Update 2 |
Download: http://www.sun.com/download/index.jsp |
Glassfish Application Server V2 UR1 und UR2 |
Glassfish Site: https://glassfish.dev.java.net/ Download-Standorte für Glassfish: Glassfish V2 UR1: https://glassfish.dev.java.net/downloads/v2ur1-b09d.html Glassfish V2 UR2: https://glassfish.dev.java.net/downloads/v2ur2-b04.html |
Sun Java System Web Server 7.0 Update 3 (32–Bit und 64–Bit) |
Download: http://www.sun.com/download/index.jsp Nur Update 3. Updates 1 und 2 werden nicht unterstützt. |
Apache Tomcat 5.5.27 und 6.0.18 und höher | |
BEA WebLogic Server 9.2 MP2 | |
BEA WebLogic Server 10 |
Siehe http://www.oracle.com/appserver/index.html Wird auf den Betriebssystemen unterstützt, die auf der folgenden Site aufgeführt sind: http://e-docs.bea.com/platform/suppconfigs/configs100/100_over/overview.html#1122259 |
Oracle Application Server 10g |
Siehe http://www.oracle.com/technology/products/database/oracle10g Version 10.1.3.1 wird unterstützt. |
IBM WebSphere Application Server 6.1 |
Siehe http://www-01.ibm.com/software/webservers/appserv/was/ |
Apache Geronimo Application Server 2.1.1 |
Siehe http://geronimo.apache.org/ Wird nur mit Tomcat auf Solaris-Systemen unterstützt. |
JBoss Application Server 4.x |
Siehe http://www.jboss.com/ |
Für weitere Informationen einschließlich Betrachtungen und Aufgaben vor der Bereitstellung für jeden Webcontainer siehe Kapitel 2, Deploying the OpenSSO Enterprise Web Container in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.
OpenSSO Enterprise 8.0 |
Unterstützte JDK Version |
---|---|
Server |
JDK 1.5.x oder 1.6.x 64-Bit JVM auf unterstützten Webcontainern Anforderungen von Solaris an den virtuellen Speicher. Für Solaris-Systeme mindestens das Doppelte an virtuellem Speicher wie die Größe der JVM-Heap konfigurieren, insbesondere dann, wenn die JVM im 64–Bit-Modus mit mehr als GB Heap-Größe konfiguriert ist. Deshalb ist es möglicherweise notwendig, den Swap-Speicher des Betriebssystems zu vergrößern. |
Client (OpenSSO SDK) |
JDK 1.4.x, 1.5.x. oder JDK 1.6.x |
Für weitere Informationen über Datenspeicher siehe Kapitel 2, Building the Deployment Architecture in Sun OpenSSO Enterprise 8.0 Deployment Planning Guide.
Komponente |
Anforderung |
---|---|
OpenSSO Enterprise 8.0 |
Zwei oder mehr Instanzen von OpenSSO Enterprise müssen auf unterschiedlichen Hostservern laufen und als eine Site hinter einem Lastausgleicher konfiguriert sein. Der Lastausgleicher hat keine besonderen Anforderungen. Ein Lastausgleicher mit Unterstützung für eine schwierige Konfiguration auf Cookie-Basis bietet jedoch gewöhnlich eine bessere Leistung. |
Sun Java System Message Queue 4.1 |
Message Queue-Broker müssen auf unterschiedlichen Servern im Cluster-Modus laufen. |
Oracle Berkeley DB 4.6.18 |
Der Berkeley DB-Client und die Datenbank müssen auf denselben Servern wie die Message Queue-Broker bereitgestellt werden. Sie können die Message Queue-Broker and Berkeley DB auf denselben Serven bereitstellen, auf denen die OpenSSO Enterprise-Instanzen ausgeführt werden. Um eine bessere Leistung zu erhalten, sollten Sie jedoch eine Installation der Broker auf unterschiedlichen Servern in Betracht ziehen. |
Für weitere Informationen siehe Kapitel 7, Implementing OpenSSO Enterprise Session Failover in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.
Richtlinienagent Version |
OpenSSO Enterprise, Unterstützung |
---|---|
Richtlinienagenten Version 3.0 |
OpenSSO Enterprise unterstützt die neue Version 3.0 J2EE und Web-Richtlinienagenten einschließlich der Funktionen der neuen Version 3.0. Für weitere Informationen einschließlich der Agents Version 3.0 siehe http://docs.sun.com/coll/1322.1. |
Richtlinienagenten Version 2.2 |
OpenSSO Enterprise unterstützt Version 2.2 J2EE und Web-Richtlinienagenten. Bei Bereitstellung mit OpenSSO Enterprise muss jedoch ein Richtlinienagent Version 2.2 weiterhin mit den Funktionen der Version 2.2 arbeiten. Der Agent muss z. B. seine Konfigurationsdaten lokal in seiner Datei AMAgent.properties speichern, und die zentralisierte Agent-Konfiguration von OpenSSO Enterprise wird nicht unterstützt. Für weitere Informationen einschließlich der Agents Version 2.2 siehe http://docs.sun.com/coll/1809.1. |
Richtlinienagenten Version 2.1 |
OpenSSO Enterprise bietet keine Unterstützung für Richtlinienagenten Version 2.1. |
Browser |
Plattform |
---|---|
Firefox 2.0.0.x und 3.0.x |
Windows Vista, Windows XP und Windows Server 2003 Solaris OS, Versionen 9 und 10 Red Hat Linux 4 und 5 |
Firefox 1.0.7 und 1.5 |
Windows XP Windows 2000 Solaris OS, Versionen 9 und 10 Red Hat Linux 4 und 5 |
Microsoft Internet Explorer 7 |
Windows Vista, Windows XP und Windows Server 2003 |
Microsoft Internet Explorer 6.0 SP1 |
Windows XP |
Microsoft Internet Explorer 6.0 SP1 |
Windows 2000 |
Mozilla 1.7.12 |
Solaris OS, Versionen 9 und 10 Windows XP Windows 2000 Red Hat Linux 4 und 5 |
Für weitere Informationen über Probleme mit OpenSSO Enterprise siehe:
https://opensso.dev.java.net/servlets/ProjectIssues
WebLogic Server StuckThreadMaxTime value is exceeded during configuration
4099: ID-WSF-Muster mit JDK 1.4 WAR führte zu Ausnahmefehlermeldung
4055: Beim Hinzufügen einer erweiterten Eigenschaft in der Konsole trat ein Fehler auf
3837: Fehlschlag der Konfiguration auf Oracle Application Server 10g
2222: Passwortzurücksetzungs- und Kontensperrungsdienst-Mitteilungsfehler
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:
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
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
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}"
Starten Sie den Server neu.
Konfiguration von OpenSSO Enterprise.
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.
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.
Dieses Problem tritt auf, wenn die folgenden Bedingungen erfüllt sind:
Ihr Konfigurationsdatenspeicher ist der Sun Java System Directory Server.
Sie versuchen, eine Installation von mehreren Servern durchzuführen.
Ihr amadmin-Passwort unterscheidet sich von dem Server-Verbindungs-dn-Passwort.
Workaround. Dieses Workaround besteht aus zwei Teilen:
Stellen Sie sicher, dass Ihr Konfigurations-Server-Verbindungs-dn-Passwort dasselbe wie Ihr amadmin-Passwort ist.
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.
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.
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
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:
Änderung in amPasswordResetModuleMsgs.propertiesvon fromAddress.label.
Änderung in amAuth.propertiesvon lockOutEmailFrom .
4102: TTL für die Konfiguration des Servicemanagements funktioniert nicht
4085: OpenSSO Enterprise kann die CRL nicht im LDAP-Verzeichnis speichern
3827: Replikationskonfiguration hängt in der zweiten Glassfish-Instanz
3350, 2867: LDAP Follows Referral sollte für Active Directory Data Store deaktiviert sein
Time to live (TTL) für die Konfiguration des Servicemanagements funktioniert nicht, weil die TTL-Eigenschaft nicht ordnungsgemäß initialisiert ist.
Nach dem Erhalt der Zertifikat-Widerrufliste (Certificate Revocation List) (CRL) von der CRL-Verteilungspunkterweiterung speichert OpenSSO Enterprise die CRL nicht im LDAP-Verzeichnis.
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
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:
Klicken Sie auf Zugriffssteuerung, Top-Level-Bereich , Datenspeicher, ActiveDirectory-Datenspeichername.
Aktiviert für LDAP Follows Referral deaktivieren.
Änderungen speichern.
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.
4100: Zertifikatauthentifizierung mit CRL-Prüfung fehlgeschlagen
4054: amadmin-Authentifizierung mit URL-org-Parameter nicht möglich
1781: amadmin-Anmeldung auf Grund von nicht erfolgter Data Store-Authentifizierung fehlgeschlagen
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.
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.
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).
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 .
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.
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.*";
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
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.
3910: setup.bat of ssoSessionTools.zip kann Tools nicht installieren
2827: Durch die Konfiguration einer Site wird der zweite Server nicht zu der Site hinzugefügt
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.
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.
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:
OpenSSO Enterprise unter Verwendung eines entfernten Sun Java System Directory Servers als Konfigurationsdatenspeicher konfigurieren.
Exportieren Sie die Dienst-XML-Datei unter Verwendung des ssoadm export-svc-cfg -Befehls.
Reimportieren Sie die erhaltenen Dienst-XML-Daten in Schritt 2 unter Verwendung des ssoadm import-svc-cfg-Befehls.
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.
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:
Bei OpenSSO Console als amadmin anmelden.
Verwenden Sie ssoadm.jsp get-svrcfg-xml, um die Serverkonfigurations-XML zu erhalten.
Verwenden Sie encode.jsp zur Codierung des amadmin-Passworts.
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>
Verwenden Sie ssoadm.jsp get-svrcfg-xml, um die abgeänderte Serverkonfigurations-XML zu setzen.
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.)
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.
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.
3065: Für alle Benutzer in den ID-FF-Protokolldatensätzen wird dieselbe Kontext-ID verwendet
2661: logout.jsp wurde auf dem WebSphere Application Server 6.1 nicht kompiliert
1977: SAMLv2 sample configure.jsp-Dateien auf WebSphere Application Server 6.1 fehlgeschlagen
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).
Alle ID-FF-Protokolldatensätze haben dieselbe Kontext- (oder Anmelde-) ID, auch wenn diese für verschiedene Benutzer sind.
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.
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:
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/
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 –>).
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.
Die ibm-web-ext.xmi-Datei speichern.
Die Anwendung neu starten.
Für weitere Informationen über den jdkSourceLevel-Parameter sowie weitere JSP-Engine-Konfigurationsparameter siehe:
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.
3961: amadmin kann sich im Koexistenzmodus nicht bei OpenSSO Console anmelden
2348: Document Distributed Authentication UI-Serverunterstützung
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.
Wechseln Sie in das config-Verzeichnis von OpenSSO Enterprise.
Ändern Sie den Chiffrierschlüssel in der AMConfig.properties-Datei mit dem korrekten Wert.
Kopieren Sie die Sicherungskopie von serverconfig.xml von der vorherigen Access Manager- oder Federation Manager-Instanz.
OpenSSO Enterprise-Server neu starten.
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
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
Die OpenSSO Enterprise Distributed Authentication UI-Serverkomponente funktioniert nur mit OpenSSO Enterprise. Die folgenden Szenarios werden nicht unterstützt:
Distributed Authentication UI-Server 7.0 oder 7.1 mit einem OpenSSO Enterprise-Server
OpenSSO Enterprise Distributed Authentication UI-Server mit einem Access Manager 7.0 oder 7.1 Server
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 .
4090: Nicht-Englische Berechtigungen werden unkenntlich gemacht
4051: Multibyte-Name eines vertrauenswürdigen Partners wird in Console unkenntlich gemacht
3993: Endbenutzerseite zeigt Fragezeichen für CCK- und JA-locales
3976: Onlinehilfe “Tipps zur Suche” hat einen 404-Fehler an einem Nicht-Englischen locale zur Folge
3713: Passwort-Zurücksetzungsseite wird für CCJK-locales nicht lokalisiert
1793: Authentifizierung schlägt mit Multibyte-Zeichen für org oder Modul in Abfrageparameter fehl
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:
Französisch (fr): ISO–8859-1
Spanisch (es): ISO–8859-1
Deutsch (de): ISO–8859-1
Vereinfachtes Chinesisch (zh_CN): UTF-8
Traditionelles Chinesisch (zh_TW): UTF-8
Koreanisch (ko): UTF-8
Japanisch (ja): EUC-JP
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.
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.
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
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.
Für CCJK-locales wird die Passwort-Rücksetzungsseite (http://host :port/deployuri/password ) nicht lokalisiert.
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
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.
4017: An spanischen locales wird “2.2 Agents” nur als Agentes in Console übersetzt
3971: An chinesischen (zh_CN) locales ist die Onlinehilfe auf Englisch
3802: Probleme im französischen Teil des Copyright-Hinweises
Wenn sich OpenSSO Console an einem spanischen locale befindet, fehlt 2.2 bei der Übersetzung von “2.2 Agents”.
Wenn sich OpenSSO Console an einem spanischen locale befindet, wird beim Klicken auf Konfiguration, Authentifizierung und dann Zertifikat eine Fehlermeldung angezeigt.
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.
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.
Ein Upgrade auf OpenSSO Enterprise 8.0 wird von den folgenden Versionen unterstützt:
Vorherige Version einschließlich Konfigurationsdaten in Sun Java System Directory Server |
Upgrades, die von dieser Plattform unterstützt werden |
---|---|
Sun Java System Access Manager 7.1Q Server Java Enterprise System-Installationsdateien und WAR-Dateibereitstellungen |
Solaris SPARC-, Solaris x86-, Linux- und Windows-Systeme |
Sun Java System Access Manager 7 2005Q4 Server |
Solaris SPARC-, Solaris x86-, Linux- und Windows-Systeme |
Sun Java System Access Manager 6 2005Q1 (6.3) Server |
Solaris SPARC-, Solaris x86-, Linux- und Windows-Systeme |
Sun Java System Federation Manager 7.0-Server |
Solaris SPARC-, Solaris x86-, Linux- und Windows-Systeme |
Der Upgrade-Prozess umfasst das Upgrade einer vorhandenen Access Manager- oder Federation Manager-Serverinstanz und die entsprechenden, in dem Sun Java System Directory Server gespeicherten Konfigurationsdaten.
Für die detaillierten Upgrade-Schritte siehe Sun OpenSSO Enterprise 8.0 Upgrade Guide .
Das Service Management Service (SMS) APIs (com.sun.identity.sm -Paket) und SMS-Modell werden in einer zukünftigen OpenSSO Enterprise-Version nicht enthalten sein.
Das Unix-Authentifizierungsmodul und der Unix-Authentifizierungshelfer (amunixd) werden in einer zukünftigen OpenSSO Enterprise-Version nicht enthalten sein.
Die Sun Java System Access Manager 7.1-Versionshinweise, die in dem Access Manager com.iplanet.am.sdk-Paket aufgeführt, und allgemein als Access Manager SDK (AMSDK) bekannt sind, sowie alle dazugehörigen APIs und XML-Vorlagen werden in einer zukünftigen OpenSSO Enterprise-Version nicht enthalten sein. Migrationsoptionen sind aktuell nicht verfügbar und es ist auch nicht zu erwarten, dass diese in Zukunft verfügbar sein werden. Sun Identity Manager bietet Bereitstellungslösungen, die Sie anstatt von AMSDK verwenden können. Für weitere Informationen über Identity Manager siehe http://www.sun.com/software/products/identity_mgr/index.jsp.
Wenden Sie sich bei Fragen zu oder Problemen mit OpenSSO Enterprise an Sun Support Resources (SunSolve) auf http://sunsolve.sun.com/.
Diese Site bietet Links zur Knowledge Base, zum Online Support Center und ProductTracker sowie zu Wartungsprogrammen und Supportkontaktnummern.
Wenn Sie Hilfe bei einem Problem benötigen, stellen Sie die folgenden Informationen bereit:
Beschreibung des Problems, u. a. der Situation, in der das Problem auftrat, und seiner Auswirkungen auf Ihren Betrieb
Rechnermodell, Version des Betriebssystems, Webcontainer und Version, JDK-Version und OpenSSO Enterprise-Version einschließlich Patches oder anderer Software, die einen Einfluss auf dieses Problem ausüben könnten
Schritte zur Reproduktion des Problems
Sämtliche Fehlerprotokolle oder Kernspeicher
Sun ist immer interessiert an Vorschlägen oder Kommentaren zur Dokumentationsverbesserung. Wechseln Sie zu http://docs.sun.com/, und klicken Sie auf Feedback.
Geben Sie in den entsprechenden Feldern den vollständigen Dokumenttitel sowie die Teilenummer ein. Die Teilenummer besteht aus einer sieben- oder neunstelligen Zahl, die sich auf der Titelseite des Buchs oder oben im Dokument befindet. Der Titel ist z. B. Sun OpenSSO Enterprise, Versionshinweise und die Teilenummber ist 820-3745.
Unter folgenden Adressen finden Sie nützliche Access Manager-Informationen und Ressourcen:
Sun-Dienste: http://www.sun.com/service/consulting/
Sun Software Products: http://wwws.sun.com/software/
Sun Support Resources http://sunsolve.sun.com/
Sun Developer Network (SDN): http://developers.sun.com/
Sun Developer Services: http://www.sun.com/developers/support/
Um Eingabehilfen zu erhalten, die seit der Veröffentlichung dieses Dokuments auf den Markt gekommen sind, lesen Sie Abschnitt 508 der Produktbewertungen, die Sie bei Sun anfordern können, um zu ermitteln, welche Versionen am besten geeignet sind.
Informationen zur Verfügbarkeitsverpflichtung von Sun erhalten Sie unter http://sun.com/access.
In der vorliegenden Dokumentation wird auf URLs von Drittanbietern verwiesen, über die zusätzliche relevante Informationen zur Verfügung gestellt werden.
Sun ist für die Verfügbarkeit von Drittanbieterwebsites, die in diesem Dokument erwähnt werden, nicht verantwortlich. Sun unterstützt keinen Inhalt, keine Werbung, Produkte oder andere Materialien, die auf oder über solche Websites oder Ressourcen zur Verfügung stehen, und ist dafür weder verwantwortlich noch haftbar. Sun ist für keinen tatsächlichen oder angeblichen Schaden oder Verlust verantwortlich oder haftbar, der verursacht wird durch oder in Verbindung steht mit der Verwendung oder der Verlässlichkeit auf solchen Inhalt, solche Waren oder Dienstleistungen, die auf oder über solche Websites oder Ressourcen zur Verfügung stehen.
Datum (Überarbeitung) |
Beschreibung der Änderungen |
---|---|
14. November 2008 (11) |
Hinzugefügte, späte Änderungen einschließlich neuer Themen und Änderungen bei Erforderliche Hardware und Software für OpenSSO Enterprise 8.0. |
11. November 2008 (10) |
Erstausgabe. |
26. August 2008 (05) |
Early Access (EA)-Versionsentwurf. |