OpenSSO Enterprise の問題の詳細については、次のサイトを参照してください。
https://opensso.dev.java.net/servlets/ProjectIssues
「4077: WebLogic Server 上の OpenSSO Enterprise の設定に新しい ldapjdk.jar が必要になる」
「4094: amadmin パスワードと設定データストア用ディレクトリマネージャーのパスワードが異なる場合にマルチサーバー設定が失敗する」
weblogic.jar に古い ldapjdk.jar ファイルがバンドルされているため、WebLogic Server 上で OpenSSO Enterprise の設定が失敗します。
Sun は、セキュリティーおよびパフォーマンス関連の修正を含む、新しい ldapjdk.jar ファイルを提供しています。WebLogic Server 9.2 および WebLogic Server 10 では、次の回避方法を実行します。
回避方法: 次のように、CLASSPATH 内で Sun の ldapjdk.jar を weblogic.jar の前に指定します。
次のコマンドを実行して、opensso.war から ldapjdk.jar を一時ディレクトリに抽出します。
jar xvf opensso.war WEB-INF/lib/ldapjdk.jar
抽出した ldapjdk.jar を WebLogic の lib ディレクトリにコピーします。
たとえば、Solaris または Linux システム上の WebLogic Server 10 では、BEA_HOME/weblogic_10.0/server/lib ディレクトリになります。
Windows 上の WebLogic Server 9.2 では、BEA_HOME\weblogic92\server\lib ディレクトリになります。
この ldapjdk.jar のパスを既存のクラスパスの先頭に付加します。これは、WebLogic Server の起動に使用する起動スクリプトを編集して行います。次の例では、BEA_HOME に WebLogic Server がインストールされているものとします。
Windows 上の WebLogic 9.2 の場合、次のファイルを編集します。
BEA_HOME\weblogic92\samples\domains\wl_server\bin\startWebLogic.cmd
set CLASSPATH=%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH% を次のように変更します。
set CLASSPATH=BEA_HOME\weblogic92\server\lib\ldapjdk.jar;%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH%
Windows 上の WebLogic 10 の場合、次のファイルを編集します。
BEA_HOME\wlserver_10.0\samples\domains\wl_server\bin\startWebLogic.cmd
set CLASSPATH=%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH% を次のように変更します。
set CLASSPATH= BEA_HOME\wlserver_10.0\server\lib\ldapjdk.jar;%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH%
Solaris または Linux 上の WebLogic 9.2 MP2 の場合、次のファイルを編集します。
/bea/weblogic92/samples/domains/wl_server/bin/startWebLogic.sh
または
/usr/local/bea/user_projects/domains/base_domain/bin/startWebLogic.sh
CLASSPATH="${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}" を次のように変更します。
CLASSPATH=
"BEA_HOME/weblogic92/server/lib/ldapjdk.jar${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}"
|
Solaris または Linux 上の WebLogic 10 の場合、次のファイルを編集します。
/bea/wlserver_10.0/samples/domains/wl_server/bin/startWebLogic.sh
または
/bea/user_projects/domains/wl10_domain/bin/startWebLogic.sh
CLASSPATH="${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}" を次のように変更します。
CLASSPATH=
"BEA_HOME/wlserver_10.0/server/lib/ldapjdk.jar${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}"
サーバーを再起動します。
OpenSSO Enterprise を設定します。
コンフィギュレータを使用した WebLogic Server 9.2 MP2 または 10 の設定時に、600 秒を過ぎても設定作業が完了しなかった場合、端末、WebLogic Server ドメイン、およびサーバーログに次のエラーが返されます。
<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: ...
このエラーは、WebLogic Server で「Stuck Thread Max Time:」のデフォルト値 600 秒を超過したために発生します。
回避方法: コンフィギュレータが応答しない場合は、再起動します。WebLogic Server の「Stuck Thread Max Time」値をデフォルトの 600 秒から 1200 秒などもっと大きい値に変更することも検討してください。この値は WebLogic コンソールを使用して変更します (base_domain > 「Environment」 > 「Servers」 > 「Admin Server」 > 「Configuration/Tuning」)。
WebLogic Server 8.1 で、ID-WSF 用に設定された opensso-client-jdk14.war からサービス検索中にエラーが返されます。
回避方法: weblogic-home/jdk142_08/jre/lib/ に、次の JAR ファイルを追加します: jax-qname.jar、namespace.jar、relaxngDatatype.jar、xalan.jar、および xsdlib.jar。
xalan.jar ファイルは、opensso.war の WEB-INF/lib ディレクトリにあります。そのほかのファイルは、opensso-client-jdk14.war の WEB-INF/lib ディレクトリにあります。
この問題は、次の条件が成立したときにのみ発生します。
使用している設定データストアが Sun Java System Directory Server である。
マルチサーバーインストールを実行しようとしている。
amadmin パスワードが Directory Server のバインド dn パスワードと異なっている。
回避方法: この回避方法には 2 つの部分があります。
設定 Directory Server のバインド dn パスワードが amadmin パスワードと同じであることを確かめます。
2 つ目以降の追加 OpenSSO Enterprise サーバーを設定します。2 つ目のサーバーのインストールを実行し、最初の OpenSSO Enterprise サーバーの設定ディレクトリを指すようにするには、2 つ目の OpenSSO Enterprise サーバーの「コンフィギュレータ」ページにアクセスして、amadmin パスワード、cookie ドメイン、および手順 1 と手順 2 に必要なその他の詳細情報を入力します。
手順 3 では、「既存の配備に追加」を選択しません。その代わりに、最初のインスタンスオプションを選択し、同じ Directory Server 名、ポート、DN、パスワード、最初のサーバーの暗号化鍵を入力します。その後、通常どおりに設定を続行します。
コンソールで拡張プロパティーを追加すると、OpenSSO Enterprise サーバーからエラーが返されます。この問題は、どの拡張設定プロパティーを追加しても発生する可能性があります。
回避方法: コンソールでデフォルトのサーバー設定を変更した場合は、OpenSSO Enterprise サーバーの Web コンテナを再起動してください。
Web コンテナとして Oracle Application Server 10g version 10.1.3.1 を使用すると、OpenSSO Express の設定が例外エラーで失敗します。
回避方法: OpenSSO を設定する前に、ターゲットの Oracle Application Server 10g サーバーインスタンスの「Server Properties」に次の JVM オプションを追加します。
-Doc4j.jmx.security.proxy.off=true
OpenSSO Enterprise から、修飾されていない送信者名 Identity-Server を使用した電子メール通知が送信され、ログにエラーエントリが返されます。
回避方法: 次のファイルで、送信者名を Identity-Server から Identity-Server@hostname.domainname に変更します。
amPasswordResetModuleMsgs.properties で fromAddress.label を変更します。
amAuth.properties で lockOutEmailFrom を変更します。
サービス管理設定の有効期間 (TTL) が、TTL プロパティーが初期化されていないために、正常に機能していません。
破棄証明書リスト (CRL) を CRL 配布ポイント拡張から取得したあと、その CRL が OpenSSO Enterprise から LDAP ディレクトリに格納されません。
この問題は、OpenSSO Enterprise が Windows Vista サーバー上の 2 つの Glassfish (または Application Server 9.1) インスタンスに配備されるシナリオで発生します。2 つ目の OpenSSO Enterprise インスタンスの設定中に、「既存の配備に追加」オプションを使用した設定の複製がハングアップします。
回避方法: この問題は、Windows Vista システムでは現在回避できません。Vista 以外の Windows システムでは、次の Glassfish (または Application Server 9.1) JVM オプションを追加してください。
-Dcom.sun.enterprise.server.ss.ASQuickStartup=false
Active Directory データストアが原因でシステムがハングアップすることがあります。この問題は、新規 Active Directory データストアの作成時に発生する可能性もあります。
回避方法: OpenSSO Enterprise 管理コンソールで、当該 Active Directory データストアの「LDAP がリフェラルに従う」を無効にします。
「アクセス制御」、top-level-realm 、「データストア」、 ActiveDirectory-data-store-name の順にクリックします。
「LDAP がリフェラルに従う」の「有効」のチェックを外します。
変更を保存します。
OpenSSO Enterprise が AMSDK プラグインで設定され、ディレクトリサーバーが MMR に設定されている場合、ディレクトリサーバーインスタンスがダウンしてもフェイルオーバーが機能しません。
Windows Server 2003 上の Internet Explorer 6.0 から Kerberos 認証を実行するように Windows デスクトップ SSO 認証モジュールを設定すると、「設定が見つかりません」エラーが返されます。
証明書認証を設定して「証明書を CRL と照合」を有効にすると、認証が失敗します。関連する問題である 「4085: OpenSSO Enterprise で CRL を LDAP ディレクトリに格納できない」も参照してください。
OpenSSO Enterprise の管理者 (amadmin) が新規レルム (たとえば myorg) を作成し、その後次のように入力してその新しいレルムにログインを試みたとします。
http://host:port/opensso/UI/Login?org=myorg
OpenSSO Enteprise から「認証できませんでした」エラーが返されます。
回避方法: amadmin としてログインできるのは、ルートレルム (かつデータストアモジュールかアプリケーションモジュール) だけです。
ルートレルムの認証モジュールを DataStore 以外に変更すると、amadmin でコンソールにログインできなくなります。
回避方法: http://host.domain/deployurl/UI/Login?module=DataStore を使用してログインします。
host: port/uri/samples の index.html で次のものが表示されます。
1. Authentication Samples 2. ID-FF Sample 3. SAMLv2 Sample 4. Multi-Federation Protocols Sample
ただし、ポリシーサンプルへの次のリンクが index.html にありません: host:port/ uri/samples/policy/policy-plugins.html
回避方法: host:port/uri/samples/policy/policy-plugins.html ファイルをブラウザで開きます。
Java Security Manager を有効にした OpenSSO Web コンテナで OCSP チェックを有効にするには、server.policy (またはそれに相当する) ファイルに次のアクセス権を追加します。
permission java.security.SecurityPermission "getProperty.ocsp.*";
コンソールのみの配備を生成し、「コンソールでの共通作業」ページから Fedlet を作成すると、「sp-extended.xml 用のファイルまたはディレクトリがありませんでした」という意味のエラーメッセージが表示されて失敗します。コンソールのみのコンフィギュレータでは、com.iplanet.services.configpath プロパティーが設定されません。
回避方法: AMConfig.properties ファイルを編集して、com.iplanet.services.configpath プロパティーを設定ディレクトリに設定します。次のような形式になります。
com.iplanet.services.configpath=/consoleonly
Access Manager ロールポリシーサブジェクトは、Access Manager リポジトリ (AMSDK) データストアでのみサポートされます。デフォルトでは、このサブジェクトはポリシー設定で無効になります。そのため、データストアの種類が AMSDK プラグインを使用する設定になっている場合にのみ、Access Manager ロールポリシーサブジェクトを有効にしてください。
詳細については、『Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide』の第 15 章「Enabling the Access Manager SDK (AMSDK) Identity Repository Plug-in」を参照してください。
ssoSessionTools.zip を解凍したあと setup.bat スクリプトを実行すると、セッションスクリプトのインストールが失敗し、次のエラーが返されます。
1.4 以降の仕様に適合する JRE が見つかりません
回避方法: setup.bat スクリプトにある java.exe コマンドから -version:"1.4+" を削除し、スクリプトを再実行します。
セッションフェイルオーバー設定で、割り当てたサーバーリストに 2 つ目の OpenSSO Enterprise インスタンスが追加されません。
回避方法: OpenSSO Enterprise コンソールまたは ssoadm ユーティリティーを使用して、サーバーリストに 2 つ目のサーバーインスタンスを手動で追加します。
OpenSSO Enterprise でサービスマネージャーデータストア内のノードを削除できないために、import-svc-cfg サブコマンドが失敗することがあります。この問題が発生する可能性があるのは、次のようなシナリオです。
リモート Sun Java System Directory Server を設定データストアとして使用して、OpenSSO Enterprise を設定します。
ssoadm export-svc-cfg コマンドを実行して、サービス XML ファイルをエクスポートします。
手順 2 で取得したサービス XML データを ssoadm import-svc-cfg コマンドを実行して再インポートします。
既存のデータの削除を確認されたら、「はい」を選択します。
次のエラーメッセージが返されます: 予期しない LDAP 例外が発生しました。
回避方法: ssoadm import-svc-cfg コマンドを、正常終了するまで繰り返し実行します。
次の例外が発生するため、get-realm を使用して ssoadm コマンドを実行できません。
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
amadmin パスワードが、サービス管理データストア用のディレクトリマネージャーのパスワードと異なっているかどうかチェックしてください。異なっている場合は、次の回避方法を適用します。
回避方法: サーバー設定 XML を次のように変更します。
OpenSSO コンソールに amadmin としてログインします。
ssoadm.jsp get-svrcfg-xml を使用して、サーバー設定 XML を取得します。
encode.jsp を使用して、amadmin パスワードをエンコードします。
エンコードしたパスワードを XML 内の amadmin-password によって表されている 2 つの場所に設定します。次のような形式になります。
<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>
ssoadm.jsp set-svrcfg-xml を使用して、変更したサーバー設定 XML を設定します。
ssoadm ユーティリティーの setup スクリプトを実行したあと、ssoadm を実行しようとすると、NoClassDefFoundError エラーが返されます。この問題は、アップグレードした OpenSSO Enterprise インスタンスで発生します。
回避方法: JSS を使用するには、jss4.jar を classpath に追加し、LD_LIBRARY_PATH 環境変数を設定します。(デフォルトの JCE を使用する場合は、jss4.jar を classpath に入れる必要はありません。)
クライアント SDK のインストールで、サービス管理サービス (SMS) のキャッシュがデフォルトで無効になります。
回避方法: Web サービスセキュリティー (WSS) アプリケーションの場合は、AMConfig.properties ファイルで com.sun.identity.sm.cache.enabled=false と設定します。そうしないと、問題 3171 の修正が機能しません。
ほかのすべてのクライアント SDK アプリケーションの場合は、AMConfig.properties ファイルで com.sun.identity.sm.cache.enabled=true と設定して SMS キャッシュを有効にします。これによって、パフォーマンスの問題を防止できます。
クライアント SDK の WAR ファイルコンフィギュレータが、AMConfig.properties ファイルに間違った共有シークレットを設定します。
回避方法: 共有シークレット値とパスワードの暗号化鍵を OpenSSO Enterprise サーバーから、$HOME/OpenSSOCLient ディレクトリにあるクライアント SDK の AMConfig.properties ファイルにコピーします。
「3923: Oracle Application Server 上で「コンソールでの共通作業」ページからのエンティティー (IDP または SP) の作成が失敗する」
「2661: WebSphere Application Server 6.1 上で logout.jsp がコンパイルできない」
「1977: WebSphere Application Server 6.1 上で SAMLv2 サンプルの configure.jsp ファイルが動作しない」
OpenSSO Enterprise を Oracle Application Server 上に配備している場合、「コンソールでの共通作業」ページでエンティティー (IDP または SP) を作成すると、例外が発生します。
回避方法: opensso.war が Oracle Application Server 上に配備されている場合は、配備計画表示で oracle.xml ファイルのインポートオプションを無効にします (「配備: 配備設定」 > 「クラスロードの設定」 > oracle.xml)。
すべての ID-FF ログレコードのコンテキスト (またはログイン) ID が、ユーザーが異なる場合でも同じになります。
logout.jsp ファイルには JDK 1.5 が必要ですが、IBM WebSphere Application Server 6.1 では JSP ファイルの JDK ソースレベルが JDK 1.3 に設定されます。
回避方法: 「1977: WebSphere Application Server 6.1 上で SAMLv2 サンプルの configure.jsp ファイルが動作しない」の回避方法を参照してください。
WebSphere Application Server 6.1 インスタンスで、/sample/saml2/sp/configure.jsp ファイルと /sample/saml2/idp/configure.jsp ファイルがコンパイルできません。configure.jsp ファイルには JDK 1.5 が必要ですが、WebSphere Application Server 6.1 では JSP ファイルの JDK ソースレベルが JDK 1.3 に設定されます。
回避方法: 次の手順に従い、JSP エンジン設定パラメータを編集して、JDK ソースレベルを 1.5 に設定します。
WEB-INF/ibm-web-ext.xmi ファイルを開きます。
JSP エンジン設定パラメータは、Web モジュールの設定ディレクトリまたは Web モジュールのバイナリディレクトリのいずれかにある、WEB-INF/ibm-web-ext.xmi ファイルに格納されています。
設定ディレクトリの例を示します。
{WAS_ROOT}/profiles/profilename/config/cells/cellname/applications/
enterpriseappname/deployments/deployedname/webmodulename/
アプリケーションが、「Use Binary Configuration」フラグを true に設定して WebSphere Application Server に配備された場合は、バイナリディレクトリとなります。次のような形式になります。
{WAS_ROOT}/profiles/profilename/installedApps/nodename/
enterpriseappname/webmodulename/
compileWithAssert パラメータを、ファイルから文を削除するかコメントタグ (<!— と –>) で文を囲むかして、削除します。
jdkSourceLevel パラメータを追加し、値として 15 を設定します。次のような形式になります。
<jspAttributes xmi:id="JSPAttribute_1" name="jdkSourceLevel" value="15"/>
注: JSPAttribute_1 の整数部分 (_1) は、ファイル内で一意にしてください。
ibm-web-ext.xmi ファイルを保存します。
アプリケーションを再起動します。
jdkSourceLevel パラメータやそのほかの JSP エンジン設定パラメータの詳細については、次のページを参照してください。
Web サービスセキュリティー (WSS) のローンサンプルに基づいてプロキシユースケースを設定し、wsp 以外のプロファイル名を使って 2 つの Web サービスプロバイダ (WSP) を作成すると、エラーが発生します。
回避方法: JAX-WS/Web アプリケーションベースの Web サービスの場合は、複数の Web サービスをサポートする WSP 名として、静的エンドポイントを使用します。EJB ベースの Web サービスの場合は、デフォルトの WSP 設定を使用します。
既存スキーマ (DIT) に合わせて OpenSSO Enterprise を設定すると、設定中に入力した暗号化鍵 (古い Access Manager または Federation Manager インスタンスからのもの) が使用されないために、設定後にコンソールにログインできません。その代わりに間違った新しい暗号化鍵が生成されるので、正しくない serverconfig.xml ファイルが作成されます。
回避方法:
OpenSSO Enterprise 設定ディレクトリに移動します。
AMConfig.properties ファイルにある暗号化鍵を正しい値に変更します。
以前の Access Manager または Federation Manager インスタンスから serverconfig.xml のバックアップコピーを取得します。
OpenSSO Enterprise サーバーを再起動します。
OpenSSO が Access Manager 7.1 Directory Server スキーマ (DIT) を使用して共存モードに設定されている場合、管理者以外のユーザーが OpenSSO コンソールにログインすると、正しくない URL に転送されます。次のような形式になります。
http://ssohost.example.com:8080/amserver/..amserver/base/AMAdminFrame
回避方法: URL を次のように編集します。
protocol://host. domain:port/deploy_uri/idm/EndUser
次のような形式になります。
http://ssohost.example.com:8080/amserver/idm/EndUser
OpenSSO が Access Manager 7.1 Directory Server スキーマ (DIT) を使用して共存モードに設定されている場合、LDAP 認証を使って amadmin としてコンソールにログインしようとすると、失敗します。
回避方法: amadmin として共存モードの OpenSSO コンソールにログインするには、module=DataStore クエリーパラメータを追加します。次のような形式になります。
protocol://host. domain:port/deploy_uri/UI/Login/?module=DataStore
次のような形式になります。
http://ssohost.example.com:8080/amserver/UI/Login/?module=DataStore
OpenSSO Enterprise の Distributed Authentication UI Server コンポーネントは、OpenSSO Enterprise でのみ動作します。次のようなシナリオはサポートされていません。
Distributed Authentication UI Server 7.0 または 7.1 と OpenSSO Enterprise サーバーの組み合わせ
OpenSSO Enterprise Distributed Authentication UI Server と Access Manager 7.0 または 7.1 サーバーの組み合わせ
以前のリリースの Access Manager または Federation Manager から OpenSSO Enterprise 8.0 にアップグレードする場合、Access Manager または Federation Manager スキーマもアップグレードしないかぎり、ID-FF プロファイルが機能しません。
回避方法: ID-FF プロファイルを試す前に、Access Manager または Federation Manager スキーマをアップグレードします。スキーマのアップグレードの詳細については、『Sun OpenSSO Enterprise 8.0 Upgrade Guide 』を参照してください。
回避方法: .txt 形式で提供されるローカライズされた権利書を表示するには、ブラウザでロケールごとに次のエンコーディングを指定してください。
フランス語 (fr): ISO–8859-1
スペイン語 (es): ISO–8859-1
ドイツ語 (de): ISO–8859-1
簡体字中国語 (zh_CN): UTF-8
繁体字中国語 (zh_TW): UTF-8
韓国語 (ko): UTF-8
日本語 (ja): EUC-JP
OpenSSO コンソールで「連携」 > 「SAML1.x 設定」と選択し、「共通設定」セクションで複数バイト名を持つ信頼できるパートナーを新規作成すると、信頼できるパートナー名が文字化けします。
CCK および JA ロケールの Geronimo Web コンテナ上で amadmin 以外のユーザーとしてログインすると、「アクセス制御」 > realm > 「全般」 > 「エンドユーザー」ページ (http://host:port/deployuri/idm/EndUser) に疑問符 (?) が表示されます。
OpenSSO コンソールにフランス語など英語以外のロケールでログインし、「ヘルプ」をクリックしてから「検索のヒント」をクリックすると、右側のヘルプパネルに 404 エラーが表示されます。
回避方法: ブラウザの言語を英語に設定し、オンラインヘルプウィンドウを更新すると、英語の「検索のヒント」を表示できます。
C ロケールで Web コンテナを起動しブラウザをフランス語などの言語に設定すると、管理コンソールにログイン後、一部の文字が文字化けします。
CCJK ロケールで、パスワードリセットページ (http://host :port/deployuri/password ) がローカライズされません。
UNIX 認証モジュールは将来の OpenSSO Enterprise リリースには含まれなくなるため、UNIX 認証モジュール用の dounix_msgs.po ファイルは翻訳されていません。「非推奨事項の通知」を参照してください。
UTF-8 以外の文字を使った org または module パラメータを使用して OpenSSO コンソールにログインしようとすると、失敗します。例: http://host:port/deployuri/UI/Login?module=Japanese-string&gx_charset=UTF-8
回避方法: ネイティブな文字の代わりに %E3%81%A6 などの UTF-8 URL エンコーディング文字を使用します。
スペイン語ロケールの OpenSSO コンソールで、「2.2 Agents」の訳から 2.2 が抜けています。
スペイン語ロケールの OpenSSO コンソールで「設定」 > 「認証」 > 「証明書」とクリックすると、エラーが返されます。
中国語 (zh_CN) ロケールで、コンソールのオンラインヘルプテキストが中国語ではなく英語で表示されます。ブラウザの優先言語を zh_CN に設定すると、左側のツリーのオンラインヘルプテキストのみ英語になります。ブラウザの優先言語を zh に設定すると、すべてのオンラインヘルプテキストが英語になります。
回避方法: zh_CN のオンラインヘルプの内容を Web コンテナの webapps ディレクトリ内の新規 zh ディレクトリにコピーし、Web コンテナを再起動します。
たとえば、Apache Tomcat の場合は、/Tomcat6.0.18/webapps/opensso/html/zh_CN/* を /Tomcat6.0.18/webapps/opensso/html/zh/ という名前の新規ディレクトリにコピーします。その後、Tomcat コンテナを再起動します。
英語の著作権表示内のフランス語の部分で、「Etats-unis」にアクセントがなく、「armes nucléaires,des missiles」のコンマの後ろに空白がなく、「Etats - Unis」の空白は不要です。