Access Manager 7 2005Q4 パッチ 3 (Sun Java System Access Manager 7 2005Q4 リリースノート)

Sun Java System Access Manager 7 2005Q4 リリースノート

Access Manager 7 2005Q4 パッチ 3

Access Manager 7 パッチ 3 (リビジョン 03) により、いくつかの問題が修正されます。その一覧はパッチに含まれている README ファイルに記載されています。パッチ 3 には、次に示す新機能と既知の問題があります。

パッチ 3 での新機能

パッチ 3 での既知の問題点と制限事項

サイト監視の新しい設定プロパティー

Access Manager のサイト監視機能に、次に示す新しいプロパティーが追加されています。

プロパティー	説明
`com.sun.identity.sitemonitor.interval`	サイト監視の間隔です (ミリ秒単位)。サイト監視機能は、指定された間隔で各サイトの可用性をチェックします。デフォルト: 60000 ミリ秒 (1 分)。
`com.sun.identity.sitemonitor.timeout`	サイトの可用性チェックのタイムアウトです (ミリ秒単位)。サイト監視機能は、指定された時間だけサイトからの応答を待ちます。デフォルト: 5000 ミリ秒 (5 秒)。

パッチでは、これらのプロパティーは AMConfig.properties ファイルに追加されません。これらの新しいプロパティーをデフォルト値以外の値で使用するには、次の手順に従います。

各プロパティーとその値を AMConfig.properties ファイルに追加します。このファイルはプラットフォームによって次のディレクトリにあります。
- Solaris システム: /etc/opt/SUNWam/config
- Linux システム: /etc/opt/sun/identity/config
ポリシーエージェントの場合は、これらのプロパティーを AMAgents.properties ファイルに追加します。
Access Manager Web コンテナを再起動して、値を有効にします。

カスタム実装。また、com.sun.identity.sitemonitor.SiteStatusCheck クラスでは、次のインタフェースを使用して、サイトの可用性チェックに使用する独自の実装をカスタマイズすることもできます。

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

各実装クラスは doCheckSiteStatus メソッドを使用する必要があります。

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

Liberty Identity Web Services Framework (ID-WSF) 1.1 のサポート

Access Manager 7 パッチ 3 では、ID-WSF のデフォルトのバージョンは WSF1.1 です。ID-WSF をトリガーするために個別の設定を行う必要はありませんが、サンプルでは新しいセキュリティー機構を使用する必要があります。ID-WSF1.1 の新しいセキュリティー機構は次のとおりです。

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

Liberty ID-WSF サポートの新しいプロパティー

com.sun.identity.liberty.wsf.version プロパティーは、Access Manager が WSC として動作しているときに、受信メッセージやリソースオファリングから Liberty ID-WSF のフレームワークを判定できない場合に、そのフレームワークを決定します。指定できる値は 1.0 または 1.1 で、デフォルトは 1.1 です。

注パッチのインストールでは、com.sun.identity.liberty.wsf.version プロパティーは AMConfig.properties ファイルに追加されません (CR# 6458184)。この新しいプロパティーを使用するには、パッチのインストール後、このプロパティーを AMConfig.properties ファイルに追加して適切な値を設定し、Access Manager Web コンテナを再起動します。

Access Manager 7 パッチ 3 のインストール後、次のコマンドを実行してスキーマの変更を読み込みます (Access Manager が Solaris システムのデフォルトディレクトリにインストールされている場合の例)。

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

ID-WSF 検索登録では、登録時にこれらの新しいセキュリティー機構を使用できます。また、WSC は WSP との通信中に、使用するバージョンを自動的に検出できます。ID-WSF1.1 を設定するには、製品に含まれている Liberty ID-FF sample1 および ID-WSF のサンプルの Readme ファイルに従ってください。

CR# 6463779 分散認証の `amProfile_Client` ログと Access Manager サーバーの `amProfile_Server` ログが無害な例外でいっぱいになる

分散認証 UI を介して Access Manager サーバーに要求があると、distAuth/amProfile_Client ログと Access Manager サーバーの debug/amProfile_Server ログに例外が記録されます。多くのセッションのあとでは、amProfile_Client ログは数ギガバイト、Access Manager サーバーの amProfile_Server ログは数メガバイトになる場合があります。このような例外がログに記録されることによって機能が失われることはありませんが、ユーザーに誤ったアラームが発生したり、ハードディスク容量がログでいっぱいになったりする原因になります。

回避方法: ログファイルの内容を null にする cron ジョブを実行します。次に例を示します。

分散認証 UI クライアントマシンで、トラフィック量に応じて数時間ごとに "cat /dev/null > distAuth/amProfile_Client" を実行します。
Access Manager サーバーで、数時間ごとではなく数日ごとに "cat /dev/null > /var/opt/SUNWam/debug/amProfile_Server" を実行します。

CR# 6460974 デフォルトの分散認証アプリケーションユーザーは `amadmin` にしないようにする

分散認証 UI サーバーを配備する場合は、分散認証の管理者を amadmin にするべきではありません。デフォルトの分散認証アプリケーションユーザーは、Makefile.distAuthUI ファイルでは amadmin であり、クライアント側で distAuth.war ファイルが配備されたあと AMConfig.properties ファイルでも同様になります。amadmin ユーザーは AppSSOToken を持っていますが、これは amadmin セッションがタイムアウトすると期限切れになり、それによって amSecurity ログファイル (デフォルトでは /tmp/distAuth ディレクトリにある) に FATAL ERROR が記録されることがあります。

回避方法: 分散認証アプリケーションユーザーとして UrlAccessAgent を指定します。次に例を示します。

クライアントの Web コンテナに distAuth.war ファイルを配備する前に、Makefile.distAuthUI ファイルで次のパラメータを変更します。

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

または

クライアントの Web コンテナに distAuth.war ファイルを配備したあとで、各 Access Manager サーバーの AMConfig.properties ファイルで次のプロパティーを変更します。

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

「CR# 6440697: 分散認証は amadmin ユーザー以外のユーザーで実行するようにする」も参照してください。

CR# 6460576 コンソールのオンラインヘルプの「フィルタを適用したロール」にユーザーサービスへのリンクがない

Access Manager コンソールのオンラインヘルプには、「フィルタを適用したロール」の下にユーザーサービスへのリンクがありません。オンラインヘルプで、「目次」、「フィルタを適用したロール」、「フィルタを作成する」の順に移動します。ページの下へ移動すると、選択したアイデンティティーの種類に応じてサービスの一覧が表示されますが、ユーザーサービスへのリンクは用意されていません。

回避方法: なし

CR# 6460085 `reinstallRTM` を実行して Web アプリケーションを再配備すると、WebSphere 上のサーバーにアクセスできなくなる

Red Hat Linux AS 3.0 Update 4 で IBM WebSphere Application Server 5.1.1.6 上の DEPLOY_LEVEL=1 配備に Access Manager 7 パッチ 3 を適用したあと、reinstallRTM スクリプトを実行して RTM RPM を復元します。次に、reinstallRTM スクリプトによって生成された amsilent ファイルを編集してから、Web アプリケーションを再配備します。stopServer.sh スクリプトと startServer.sh スクリプトを使用して WebSphere を再起動します。しかし、ログインページにアクセスすると、amlcontroller フィルタに関連する 500 エラーが WebSphere で表示されます。

この問題は、reinstallRTM スクリプトによって生成される新しい server.xml ファイルが破損しているために発生します。

回避方法: amconfig スクリプトでバックアップした server.xml ファイルは有効です。この以前のコピーを次の手順で使用します。

サーバーを停止します。
破損している server.xml を、amconfig スクリプトでバックアップしておいたコピーで置き換えます。

amconfig スクリプトでバックアップされた server.xml ファイルの名前は server.xml-orig-pid になります。ここで、pid は amwas51config スクリプトのプロセス ID です。このファイルは、次のディレクトリにあります。
```
WebSphere-home-directory/config/cells/WebSphere-cell
/nodes/WebSphere-node/servers/server-name
```
サーバーを再起動します。

CR# 6455757: アップグレードの前に `sunISManagerOrganization` マーカークラスを組織に追加する必要がある

Access Manager 7 リリースより前に作成された Access Manager DIT 内の組織は、sunISManagerOrganization オブジェクトクラスを持たない場合があります。また、Access Manager 以外の製品で作成された組織も、その定義に sunISManagerOrganization オブジェクトクラスを持ちません。

回避方法: Access Manager 7 2005Q4 にアップグレードする前に、DIT 内のすべての組織の定義に sunISManagerOrganization オブジェクトクラスが含まれていることを確認します。アップグレードの前に、必要に応じてこのオブジェクトクラスを手動で追加します。

CR# 6454489: Access Manager 7 2005Q4 パッチ 2 のアップグレードによってコンソールの「現在のセッション」タブにエラーが表示される

アップグレードによって、Access Manager コンソールの「現在のセッション」タブに次のエラーが表示されます。

Failed to get valid Sessions from the Specified server

この問題は、o=orgname という形式のルートサフィックスを持つ Access Manager 6 バージョンからアップグレードする配備で発生します。

回避方法: Access Manager 7 2005Q4 のインストール後、Access Manager 7 パッチ 3 を適用してから amupgrade スクリプトを実行して、次のようにデータを移行します。

Access Manager 6 DIT をバックアップします。
ampre70upgrade スクリプトを実行します。
「あとで設定」オプションを指定して Access Manager 7 2005Q4 をインストールします。
Access Manager Web アプリケーションの配備を取り消します。
Access Manager Web アプリケーションを配備します。
Access Manager 7 パッチ 3 を適用します。ただし、XML/LDIF の変更は適用しないでください。XML/LDIF の変更は、次の手順で amupgrade スクリプトを実行したあとで適用する必要があります。
amupgrade スクリプトを実行します。
Access Manager 7 パッチ 3 の変更のため、Access Manager Web アプリケーションを再配備します。
Access Manager コンソールにアクセスします。

CR# 6452320: クライアント SDK でポーリングを使用すると例外がスローされる

Access Manager クライアント SDK (amclientsdk.jar) を配備してポーリングを有効にすると、次のようなエラーが発生することがあります。

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

このようなエラーは、クライアントマシンに分散認証 UI サーバーまたは J2EE エージェントを配備したあと、あるいは、Access Manager クライアント SDK を配備する任意の状況で発生することがあります。

回避方法: 並行セッションの数が数百程度であれば、次のプロパティーと値を AMConfig.properties ファイルまたは AMAgents.properties ファイルに追加します。

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

数千または数万のセッションがある場合は、amtune-identity スクリプト実行後の Access Manager AMConfig.properties ファイル内の通知用の値と同じ値を設定するようにしてください。たとえば、マシンに 4G バイトの RAM がある場合、Access Manager の amtune-identity スクリプトでは次の値が設定されます。

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

4G バイトの RAM を備えたクライアントマシンに分散認証 UI サーバーまたは Access Manager クライアント SDK を配備するときは、AMAgent.properties ファイルまたは AMConfig.properties ファイルで、類似の値をクライアント側に設定します。

CR# 6442905 認証されたユーザーの `SSOToken` が不正なサイトに公開される可能性がある

認証された Access Manager ユーザーが不正なサイトの URL をクリックすると、その不正なサイトに SSOToken が公開されてしまう可能性があります。

回避方法: 参加しているすべてのポリシーエージェントについて、常に一意のエージェントユーザープロファイルを Access Manger に作成し、サイトが不正でないことを確認します。また、これらの一意のエージェントユーザーで使用されるパスワードが、共有シークレットパスワードまたは amldapuser パスワードと同じでないことを確認します。デフォルトでは、ポリシーエージェントは Access Manager アプリケーション認証モジュールに対して UrlAccessAgent ユーザーとして認証されます。

Access Manager 管理コンソールを使用してエージェントを作成する方法については、『Sun Java System Access Manager 7 2005Q4 管理ガイド』の「エージェント」を参照してください。

CR# 6441918: サイト監視の間隔およびタイムアウトのプロパティー

Access Manager のサイトフェイルオーバーに、次に示す新しいプロパティーが追加されています。

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

詳細については、「サイト監視の新しい設定プロパティー」を参照してください。

CR# 6440697: 分散認証は amadmin ユーザー以外のユーザーで実行するようにする

デフォルトの管理ユーザー (amadmin) 以外の、分散認証アプリケーションの認証に使用する分散認証管理者を作成するには、次の手順に従います。

分散認証管理者の LDAP ユーザーを作成します。次に例を示します。
```
uid=DistAuthAdmin,ou=people,o=am
```
分散認証管理者を特殊ユーザーのリストに追加します。次に例を示します。
```
com.sun.identity.authentication.special.users=cn=dsameuser,
ou=DSAME Users,o=am|cn=amService-UrlAccessAgent,ou=DSAME Users,
o=am|uid=DistAuthAdmin,ou=People,o=am
```
このプロパティーをすべての Access Manager サーバーの AMConfig.properties ファイルに追加して、セッションのタイムアウトによって分散認証管理者の AppSSOToken が期限切れにならないようにします。

CR# 6440695: 分散認証 UI サーバーとロードバランサ

複数の分散認証 UI サーバーの前でロードバランサを使用する配備の場合は、WAR ファイルを配備したあと、次のプロパティーを AMConfig.properties ファイルに設定します。

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

CR# 6440651: Cookie 応答には `com.sun.identity.session.resetLBCookie` プロパティーが必要

Access Manager のセッションフェイルオーバーで Cookie 応答を正しく動作させるには、値を true に設定した com.sun.identity.session.resetLBCookie プロパティーをポリシーエージェントと Access Manager サーバーの両方に追加します。次に例を示します。

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

ポリシーエージェントの場合は、このプロパティーを AMAgents.properties ファイルに追加します。
Access Manager サーバーの場合は、このプロパティーを AMConfig.properties ファイルに追加します。

注: このプロパティーは、Access Manager のセッションフェイルオーバーを実装した場合にのみ必要です。

CR# 6440648: `com.iplanet.am.lbcookie.name` プロパティーのデフォルト値は `amlbcookie` と仮定される

デフォルトでは、ポリシーエージェントと Access Manager サーバーではロードバランサの cookie 名は amlbcookie と仮定されます。バックエンドサーバーで cookie 名を変更する場合は、ポリシーエージェントの AMAgent.properties ファイル内でも同じ名前を使用する必要があります。また、Access Manager クライアント SDK を使用している場合は、バックエンドサーバーで使用されているものと同じ cookie 名を使用する必要があります。

CR# 6440641: `com.iplanet.am.lbcookie.value` プロパティーは推奨されなくなった

Access Manager では、ロードバランサ cookie をカスタマイズするためのサーバーの com.iplanet.am.lbcookie.value プロパティーはサポートされなくなりました。代わりに、エージェントによって再生される cookie の値と名前に、セッション設定の一部として設定されるサーバー ID を使用するようになりました。

CR# 6429610: ID-FF SSO ユースケースで SSO トークンを作成できない

Liberty Identity Federation Framework (ID-FF) サンプル 1 を設定したあと、連携は成功するが、SSO が失敗します。

回避方法: dsameuser の uuid を AMConfig.properties ファイル内の com.sun.identity.authentication.special.users プロパティーに追加します。アプリケーション認証には、Access Manager サーバーの dsameuser ユーザーの SSO トークンが無期限である必要があります。

CR# 6389564: Access Manager のログイン時に、LDAP v3 データストア内のユーザーのロールメンバーシップに関するクエリーが繰り返し発生する

ユーザーが Access Manager にログインするとき、ユーザーの nsRoleDN 属性に関する LDAP 検索が繰り返し発生します。

回避方法: Access Manager 7 パッチ 3 のインストール後、次のコマンドを実行します (Access Manager が Solaris システムのデフォルトディレクトリにインストールされている場合の例)。

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

CR# 6385185: 認証モジュールで "goto" URL を上書きして別の URL を指定できる必要がある

認証モジュールでは、"goto" URL を上書きして、ユーザーステータスを検証するために外部 Web サイトの別の URL にリダイレクトするよう要求できます。

認証の完了後に "goto" URL を上書きするには、次の例に示すプロパティーを SSOToken に設定します。このプロパティーを設定するには、AMPostAuthProcessInterface を実装して PostProcess クラスの onLoginSuccess メソッドを使用します。たとえば、"goto" URL を上書きする URL が OverridingURL の場合は、次のように指定します。

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

CR# 6385184: SSO トークンがまだ無効な状態での、カスタム認証モジュール内からのリダイレクト

カスタム認証モジュールの新しい RedirectCallback を使用すると、ユーザーを検証するために、認証 UI を介して外部 Web サイトにリダイレクトできます。正常に認証された場合、ユーザーは元の Access Manager サーバーの URL に再びリダイレクトされます。サンプルファイルは次のとおりです。

LoginModuleSample.java
LoginModuleSample.xml
testExtWebSite.jsp

この機能を実装するには、次の手順に従います。

サンプル LoginModuleSample.java を使用して、カスタム認証モジュールを作成します。
このモジュールを Access Manager サーバーに読み込みます。
サンプル LoginModuleSample.xml を使用して、XML ファイルに RedirectCallback を構築します。
モジュールをテストするために、外部 Web サイトとしてサンプル testExtWebSite.jsp ファイルを使用します。

次の URL を使用してログインします。

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

検証のためにユーザー名とパスワードが外部 Web サイトにリダイレクトされます。ユーザー名とパスワードが有効な場合、ユーザーは正常に認証され、元の Access Manager サーバーの URL に再びリダイレクトされます。

たとえば、配備でカスタム認証モジュールを使用してプロビジョニング/クレジットカードサイトにアクセスする、次のようなシナリオが考えられます。

ユーザーがカスタム認証モジュールの認証プロセス/ログインページを呼び出します。
ユーザーは資格情報 (ユーザー名とパスワード) を入力し、カスタム認証モジュールに要求を送信します。
カスタム認証モジュールは、外部のプロビジョニング/クレジットカードサイトにユーザーをリダイレクトして、必要なユーザー情報とともに要求を送信します。
外部のプロビジョニング/クレジットカードサイトは、ユーザーのステータスを確認し、要求を返します。返送される要求には、成功または失敗の情報が設定されます。
カスタム認証モジュールは、手順 4 で返されたステータスに基づいてユーザーを検証し、対応するステータスを認証サービスに返します。
ユーザーの認証は成功または失敗で完了します。

CR# 6324056: アーティファクトプロファイルを使用したときに連携が失敗する

回避方法: この問題を修正するには、「Core Mobile Access」パッチの最新バージョンを適用します。このバージョンは、プラットフォームに応じて次のようになります。

SPARC ベースシステム上の Solaris OS: 119527
x86 プラットフォーム上の Solaris OS: 119528
Linux システム: 119529

パッチを適用したあと、Web コンテナを再起動します。