Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun Java System Access Manager 6 2005Q1 管理ガイド 

第 6 章
認証の管理

認証サービスは、Access Manager 配備にインストールされたすべての初期状態の認証モジュールへの、Web ベースのユーザーインタフェースを提供します。このインタフェースは、アクセスを要求するユーザーに対して、呼び出される認証モジュールに基づいたログイン条件画面を表示して認証クレデンシャルを収集する動的かつカスタマイズ可能な手段を提供します。このインタフェースは、開発者が実用的な Web アプリケーションを作成するのに役立つ Java 2 Enterprise Edition (J2EE) プレゼンテーションフレームワークである Sun Java SystemTM Application Framework (JATO と呼ばれることもある) を使用して作成されています。

ユ―ザーインタフェースのログイン URL

認証サービスユーザーインタフェースには、Web ブラウザの場所ツールバーにログイン URL を入力してアクセスします。この URL は次のとおりです。

http://identity_server_host.ドメイン名:ポート/サービス配備_URI/UI/Login

注

インストール時に、サービス配備_URI は amserver として設定されます。このマニュアル全体にわたり、このデフォルトのサービス配備 URI が使用されています。

特定の認証方法や、成功、失敗した認証の URL のリダイレクトを定義するために、ユーザーインタフェースのログイン URL にログイン URL パラメータを付加することもできます。URL のリダイレクトの詳細情報は「認証タイプ」を参照してください。

ログイン URL パラメータ

URL パラメータは、URL の終わりに付加される名前と値のペアです。このパラメータは疑問符 (?) で始まり、名前=値 の形式をとります。たとえば、次のようにいくつかのパラメータを 1 つのログイン URL に結合できます。

http://サーバー名.ドメイン名:ポート /amserver/UI/Login?module=LDAP&locale=ja&goto=http://www.sun.com

複数のパラメータを指定する場合は、アンパサンド (&) で区切ります。複数のパラメータを指定する場合は、次のガイドラインに従う必要があります。

次の節では、ユーザーインタフェースのログイン URL に付加され、Web ブラウザの場所ツールバーに入力されたときに、さまざまな認証機能を実現するパラメータについて説明します。

ヒント

組織全体に配布する認証 URL およびパラメータを単純なものにするには、管理者は単純な URL を持つ HTML ページを作成し、そのページにすべての設定された認証方法に対するより複雑なログイン URL へのリンクを含めることができます。

goto パラメータ

goto=successful_authentication_URL パラメータは、認証設定サービスの「ログイン成功 URL」に定義された値を置き換えます。このパラメータは、認証が成功すると指定された URL にリンクします。goto=logout_URL パラメータも、ユーザーのログアウト時に指定された URL にリンクするのに使用できます。次に認証成功 URL の例を示します。

http://サーバー名.ドメイン名:ポート /amserver/UI/Login?goto=http://www.sun.com/homepage.html

次に goto ログアウト URL の例を示します。

http://サーバー名.ドメイン名:ポート /amserver/UI/Logout?goto=http://www.sun.com/logout.html

注

Access Manager が認証成功リダイレクト URL を確認する優先順位が定められています。リダイレクト URL とそれらの順番は認証方法に基づいているので、この順番および関連情報については、「認証タイプ」で詳しく説明します。

gotoOnFail パラメータ

gotoOnFail=failed_authentication_URL パラメータは、認証設定サービスの「失敗ログイン URL」に定義された値を置き換えます。ユーザーが認証に失敗すると、指定された URL にリンクします。次に gotoOnFail URL の例を示します。http://サーバー名.ドメイン名:ポート/amserver/UI/Login?gotoOnFail=http://www.sun.com/auth_fail.html

注

Access Manager が認証失敗リダイレクト URL を確認する優先順位が定められています。リダイレクト URL とそれらの順番は認証方法に基づいているので、この順番および関連情報については、「認証タイプ」で詳しく説明します。

org パラメータ

org=orgName パラメータを使用すると、指定された組織のユーザーとしてユーザーを認証することができます。

ヒント

指定された組織のメンバーになっていないユーザーが、org パラメータで認証を試みると、エラーメッセージを受け取ります。ただし、次の条件をすべて満たせば、Directory Server に動的にユーザープロファイルを作成できます。

  • コア認証サービスの「ユーザープロファイル」属性に、「ダイナミック」または「ユーザーエイリアスを使用してダイナミックに」が設定されている。
  • ユーザーが、必要なモジュールに対する認証に成功している。
  • ユーザーのプロファイルは、まだ Directory Server にない。

このパラメータから、組織およびそのロケールの設定に基づいて、正しいログインページが表示されます。このパラメータが設定されない場合は、デフォルトは最上位の組織になります。たとえば、org URL は次のようになります。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?org=sun

user パラメータ

user=userName パラメータは、ユーザーのプロファイルの「ユーザー認証設定」属性に設定されたモジュールに基づいて、認証を強制します。たとえば、あるユーザーのプロファイルを、証明書モジュールを使用して認証し、別のユーザーを LDAP モジュールを使用して認証するように設定できます。このパラメータを追加すると、ユーザーはユーザーの組織に設定された認証方法ではなく、ユーザー用に設定された認証プロセスに送られます。次に例を示します。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?user=jsmith

role パラメータ

role=roleName パラメータは、ユーザーを指定されたロール用に設定された認証プロセスに送ります。指定されたロールのメンバーになっていないユーザーが、このパラメータで認証を試みると、エラーメッセージを受け取ります。次に例を示します。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?role=manager

locale パラメータ

Access Manager は、認証プロセスとコンソール自身について、ローカライズされた (英語以外の言語に翻訳された) 画面を表示することができます。locale=localeName パラメータは、指定されたロケールをその他の定義されたロケールよりも優先させることができます。ログインのロケールは、次の順序で次の場所から設定を検索したあとに、クライアントに表示されます。

  1. ログイン URL のロケールパラメータの値

    2. locale=localeName パラメータの値は、定義されたその他のすべてのロケールよりも優先されます。

  2. ユーザーのプロファイルに定義されたロケール

    3. URL パラメータがない場合は、ロケールはユーザープロファイルの「ユーザー設定言語」属性に設定された値に基づいて表示されます。

  3. HTTP ヘッダーに定義されたロケール

    4. このロケールは、Web ブラウザによって設定されます。

  4. コア認証サービスに定義されたロケール

    5. これは、コア認証モジュールの「デフォルト認証ロケール」属性の値です。

  5. プラットフォームサービスに定義されたロケール

    6. これは、プラットフォームサービスの「プラットフォームロケール」属性の値です。

  6. オペレーティングシステムのロケール

この優先順位から導き出されるロケールは、ユーザーのセッショントークンに格納され、Access Manager が、ローカライズされた認証モジュールのロードだけに使用します。認証に成功すると、ユーザーのプロファイルの「ユーザー設定言語」属性に定義されたロケールが使用されます。ロケールが設定されていない場合は、認証に使用されたロケールが引き続き使用されます。次に例を示します。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?locale=ja

注

画面のテキストおよびエラーメッセージのローカライズの方法については、『Access Manager Developer's Guide』を参照してください。

module パラメータ

module=moduleName パラメータを使用すると、指定した認証モジュールによって認証を行うことができます。どのモジュールでも指定できますが、まずユーザーが所属する組織に登録し、コア認証モジュールでその組織の認証モジュールの 1 つとして選択する必要があります。次に例を示します。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?module=Unix

注

認証モジュール名は、URL パラメータで使用する場合には大文字と小文字が区別されます。

service パラメータ

service=serviceName パラメータを使用すると、サービスの設定された認証スキームによってユーザーを認証できます。認証設定サービスを使用して、異なるサービスに異なる認証スキームを設定できます。たとえば、オンラインの給料支払いアプリケーションにはより安全な証明書認証モジュールを使用した認証が必要になり、組織の従業員のディレクトリアプリケーションには LDAP 認証モジュールのみが必要になるなどです。認証スキームを、それらの各サービスに設定および指定できます。次に例を示します。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?service=sv1

注

認証設定サービスを使用して、サービスに基づく認証のスキームを定義します。

arg パラメータ

arg=newsession パラメータを使用して、ユーザーの現在のセッションを終了し、新しいセッションを開始します。認証サービスは、1 回の要求でユーザーの既存のセッショントークンを破棄し、新しいログインを実行します。このオプションは、通常匿名の認証モジュールで使用されます。ユーザーは、まず匿名セッションで認証を受けてから、登録リンクまたはログインリンクをヒットします。次に例を示します。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?arg=newsession

authlevel パラメータ

authlevel=value パラメータは、指定された認証レベル値以上の認証レベルのモジュールを呼び出すように認証サービスに指示します。各認証モジュールは、固定整数の認証レベルで定義されます。次に例を示します。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?authlevel=1

注

認証レベルは、各モジュールの特定のプロファイルに設定されます。このモジュールについては、『Sun Java System Access Manager 管理ガイド』を参照してください。

domain パラメータ

このパラメータを使用すると、指定されたドメインとして識別される組織にユーザーがログインできます。指定するドメインは、組織のプロファイルの「ドメイン名」属性に定義された値に一致する必要があります。次に例を示します。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?domain=sun.com

ヒント

指定されたドメイン、つまり組織のメンバーになっていないユーザーが、org パラメータで認証を試みると、エラーメッセージを受け取ります。ただし、次の条件をすべて満たせば、Directory Server に動的にユーザープロファイルを作成できます。

  • コア認証サービスの「ユーザープロファイル」属性に、「ダイナミック」または「ユーザーエイリアスを使用してダイナミックに」が設定されている。
  • ユーザーが、必要なモジュールに対する認証に成功している。
  • ユーザーのプロファイルは、まだ Directory Server にない。

iPSPCookie パラメータ

iPSPCookie=yes パラメータを使用すると、ユーザーは持続 Cookie でログインできます。持続 Cookie とは、ブラウザウィンドウが閉じられたあとも存在し続ける Cookie のことです。このパラメータを使用するには、ユーザーがログインする組織のコア認証モジュールで「持続 Cookie」が有効になっている必要があります。ユーザーが認証されブラウザを閉じると、ユーザーは新しいブラウザセッションでログインすることが可能であり、再認証する必要なくコンソールにダイレクトされます。これは、コアサービスに指定された「Cookie の最大持続時間」属性の値まで有効です。次に例を示します。

http://サーバー名.ドメイン名:ポート /amserver/UI/Login?org=example&iPSPCookie=yes

IDTokenN パラメータ

このパラメータオプションを使用すると、ユーザーは URL または HTML 形式で認証クレデンシャルを渡すことができます。IDTokenN=value パラメータを使用すると、ユーザーは認証サービスユーザーインタフェースにアクセスせずに認証を受けることができます。この処理は、ゼロページログインと呼ばれます。ゼロページログインは、1 つのログインページを使用する認証モジュールの場合にのみ機能します。IDToken0、IDToken1、...、IDTokenN の値は、認証モジュールのログインページのフィールドにマッピングされます。たとえば、LDAP 認証モジュールは、userID 情報に IDToken1 を、パスワード情報に IDToken2 を使用できます。この場合、LDAP モジュールの IDTokenN URL は次のようになります。

http://サーバー名.ドメイン名:ポート /amserver/UI/Login?module=LDAP&IDToken1=userID&IDToken2=password

LDAP がデフォルトの認証モジュールである場合は、module=LDAP を省略できます。

匿名認証の場合は、ログイン URL パラメータは次のようになります。

http://サーバー名.ドメイン名:ポート /amserver/UI/Login?module=Anonymous&IDToken1=anonymousUserID

注

以前のリリースのトークン名 Login.Token0、Login.Token1、...、Login.TokenN は、現在はサポートされていますが今後のリリースではサポートされません。新しい IDTokenN パラメータを使用することをお勧めします。

認証タイプ

認証サービスは、さまざまな認証適用方法を提供します。それらの異なる認証方法には、ログイン URL パラメータを指定して、または認証プログラミングインタフェースを介してアクセスできます。認証モジュールを設定する前に、特定の認証モジュール名を含むように、コア認証サービス属性の組織認証モジュールを修正する必要があります。

認証設定サービスは、次の認証タイプ用の認証モジュールを定義するために使用します。

これらの認証タイプのいずれかで認証モジュールを定義すると、認証プロセスの成功または失敗に基づいて、リダイレクト URL、およびポストプロセス Java クラス仕様を提供するように設定できます。

認証タイプによってアクセスが決定される方法

各認証方法では、ユーザーは認証に成功するか失敗します。成功または失敗の決定後、各方法では次の手順を実行します。手順 1 〜 3 は認証が成功した場合に実行され、手順 4 は成功した認証と失敗した認証の両方で実行されます。

  1. Access Manager によって、認証されたユーザーが Directory Server データストアに定義されているかどうか、またプロファイルが有効であるかどうかが確認されます。

    2. コア認証モジュールの「ユーザープロファイル」属性は、「必須」、「ダイナミック」、「ユーザーエイリアスを使用してダイナミックに」、または「無視」として定義できます。認証に成功すると、Access Manager によって、認証されたユーザーが Directory Server データストアに定義されているかどうかが確認され、「ユーザープロファイル」の値が「必須」である場合は、プロファイルが有効であるとみなされます。これはデフォルトの場合です。「ユーザープロファイル」が「ダイナミックに設定」である場合、認証サービスはユーザープロファイルを Directory Server データストアに作成します。「ユーザープロファイル」が「無視」に設定されている場合は、ユーザーの検証は行われません。

  2. 認証ポストプロセス SPI が実行されます。

    3. コア認証モジュールには、値として認証ポストプロセスクラス名を含む「認証ポストプロセスクラス」属性が含まれています。AMPostAuthProcessInterface は、ポストプロセスインタフェースです。このインタフェースは、認証の成功または失敗時、またはログアウト時に実行できます。

  3. セッショントークンで次のプロパティが追加または更新され、ユーザーのセッションがアクティブになります。

    4. Organization: これは、ユーザーが所属する組織の DN です。

    Principal: ユーザーの DN です。

    Principals: ユーザーが認証を受けた名前のリストです。このプロパティは、パイプで区切られたリストとして定義された複数の値を持つことができます。

    UserId: モジュールが返すユーザーの DN であるか、LDAP またはメンバーシップ以外のモジュールの場合はユーザー名です。すべての Principal は、同じユーザーにマッピングされる必要があります。ユーザー ID は、ユーザーがマッピングされるユーザー DN です。

    注

    このプロパティは、DN 以外の値になることがあります。

    UserToken: ユーザー名です。すべての Principal は、同じユーザーにマッピングされる必要があります。UserToken は、ユーザーがマッピングされるユーザー DN です。

    Host: クライアント用のホスト名または IP アドレスです。

    authLevel: ユーザーが認証を受けた最高のレベルです。

    AuthType: ユーザーが認証を受けた認証モジュールのパイプで区切られたリストです (例、module1|module2|module3)。

    clientType: クライアントブラウザのデバイスタイプです。

    Locale: クライアントのロケールです。

    CharSet: クライアント用に定めらた文字セットです。

    Role: ロールに基づく認証にのみ適用可能であり、ユーザーが属すロールです。

    Service: サービスに基づく認証にのみ適用可能であり、ユーザーが属すサービスです。

    loginURL: クライアントのログイン URL です。

  4. Access Manager は、成功または失敗した認証のあとにユーザーをリダイレクトする場所についての情報を検索します。

    5. URL のリダイレクトは、Access Manager のページまたは URL のどちらかにすることができます。リダイレクトは、Access Manager が認証方法に基づいて、また認証が成功したか失敗したかによってリダイレクトを検索する優先順位のもとに行われます。この順序については、次の認証方法についての節の、URL のリダイレクトの部分で詳しく説明します。

URL のリダイレクト

認証設定サービスでは、成功または失敗した認証に対する URL のリダイレクトを割り当てることができます。その URL 自体は、認証設定サービスの「ログイン成功 URL」および「ログイン失敗 URL」属性で定義します。URL のリダイレクトを有効にするために、ロール、組織、またはユーザー用に設定するように、認証設定サービスを組織に追加し、利用可能にする必要があります。認証設定サービスの追加時は、LDAP で必須、というように認証モジュールを追加するようにしてください。詳細は、「認証設定」を参照してください。

組織に基づく認証

この認証方法では、ユーザーが組織またはサブ組織に対する認証を受けることができます。これは、Access Manager のデフォルトの認証方法です。組織の認証方法は、コア認証モジュールを組織に登録し、「組織認証設定」属性を定義することによって設定します。

組織に基づく認証のログイン URL

認証の組織は、ユーザーインタフェースのログイン URL に org パラメータまたは domain パラメータを定義して指定できます。認証の要求の組織は、次の優先順位で判断されます。

  1. domain パラメータ。
  2. org パラメータ。
  3. 管理サービスの「DNS エイリアス名」 (組織のエイリアス名) 属性の値。

正しい組織を呼び出した後、ユーザーが認証を受ける認証モジュールは、コア認証サービスの「組織認証設定」属性から取得されます。組織に基づく認証を指定し、開始するログイン URL を次に示します。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?domain=ドメイン名

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?org=組織名

定義されたパラメータがない場合、組織はログイン URL に指定されたサーバーホストとドメインから判断されます。

組織に基づく認証のリダイレクト URL

組織に基づく認証が成功または失敗した時に、Access Manager はユーザーのリダイレクト先の情報を検索します。この情報をアプリケーションが検索する優先順位を次に示します。

組織に基づく認証が成功した場合のリダイレクト URL

組織に基づく認証が成功した場合のリダイレクト URL は、次の場所を次の優先順位で確認することによって判断されます。

  1. 認証モジュールで設定された URL。
  2. goto ログイン URL パラメータで設定された URL。
  3. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
  4. ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  5. ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  6. グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  7. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
  8. ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
  9. ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性に設定された URL。
  10. グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。
組織に基づく認証に失敗した場合のリダイレクト URL

組織に基づく認証が失敗した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

  1. 認証モジュールで設定された URL。
  2. gotoOnFail ログイン URL パラメータで設定された URL。
  3. ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性用に clientType カスタムファイルに設定された URL。
  4. ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  5. ユーザーの組織エントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  6. グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  7. ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性に設定された URL。
  8. ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
  9. ユーザーの組織エントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
  10. グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性に設定された URL。

組織に基づく認証を設定する

認証モジュールは、最初にコア認証サービスを組織に追加することで、組織用に設定できます。

組織の認証属性を設定するには、次の手順を実行します。

  1. 認証属性を設定する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. サービスのリスト表示で、「コア」をクリックします。

    4. コア認証属性がデータ区画に表示されます。

  4. 「管理者認証」属性の隣にある「編集」リンクをクリックします。これにより、管理者専用に認証サービスを定義できます。この属性は、管理者とエンドユーザーの認証モジュールを別々のものにする必要がある場合に使用できます。デフォルトの認証モジュールは LDAP です。

    5. 認証サービスを定義したら、「保存」をクリックして変更内容を保存します。次に「閉じる」をクリックし、組織の「コア認証」属性に戻ります。

  5. 「組織認証設定」属性の隣にある「編集」リンクをクリックします。これにより、組織内の全ユーザー用に認証モジュールを定義できます。デフォルトの認証モジュールは LDAP です。
  6. 認証サービスを定義したら、「保存」をクリックして変更内容を保存します。次に「閉じる」をクリックし、組織の「コア認証」属性に戻ります。

ロールに基づく認証

この認証方法では、ユーザーは組織またはサブ組織内の (スタティックまたはフィルタリングされた) ロールに対する認証を受けることができます。

注

認証設定サービスは、組織に登録してからでなければロールにインスタンスとして登録できません。

認証を成功させるには、ユーザーはロールに属し、そのロールに設定された認証設定サービスインスタンスに定義された各モジュールに対する認証を受ける必要があります。ロールに基づく認証の各インスタンスに対して、次の属性を指定できます。

「競合の解決レベル」: 同一のユーザーが含まれることがある 2 つの異なるロールに定義された認証設定サービスインスタンスに対する優先レベルを設定します。たとえば、User 1 が Role 1 および Role 2 に割り当てられている場合を想定します。ユーザーが認証を試みたときに、認証の成功または失敗時のリダイレクトや認証後プロセスに対して Role 1 の優先順位がより高くなるように、Role1 により高い競合解決レベルを設定することができます。

「認証設定」: ロールの認証プロセスに設定された認証モジュールを定義します。

「ログイン成功 URL」: 認証が成功した場合にユーザーがリダイレクトされる URL を定義します。

「ログイン失敗 URL」: 認証が失敗した場合にユーザーがリダイレクトされる URL を定義します。

「認証ポストプロセスクラス」: 認証後インタフェースを定義します。

ロールに基づく認証のログイン URL

ロールに基づく認証は、ユーザーインタフェースのログイン URL にロールパラメータを定義して指定できます。正しいロールを呼び出した後、ユーザーが認証を受ける認証モジュールは、そのロールに定義された認証設定サービスインスタンスから取得されます。

このロールに基づく認証を指定し開始するログイン URL を次に示します。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?role=ロール名

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?org=組織名 &role=ロール名

org パラメータが設定されていない場合、ロールが属す組織はログイン URL そのものに指定されたサーバーホストおよびドメインから判断されます。

ロールに基づく認証のリダイレクト URL

ロールに基づく認証が成功または失敗した時に、Access Manager はユーザーのリダイレクト先の情報を検索します。この情報をアプリケーションが検索する優先順位を次に示します。

ロールに基づく認証が成功した場合のリダイレクト URL

ロールに基づく認証が成功した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

  1. 認証モジュールで設定された URL。
  2. goto ログイン URL パラメータで設定された URL。
  3. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
  4. ユーザーが認証を受けたロールの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  5. 認証されたユーザーの別のロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。このオプションは、前のリダイレクト URL が失敗した場合の代替リダイレクト URL です。
  6. ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  7. グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  8. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
  9. ユーザーが認証されたロールの iplanet-am-auth-login-success-url 属性に設定された URL。
  10. 認証されたユーザーの別のロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。このオプションは、前のリダイレクト URL が失敗した場合の代替リダイレクト URL です。
  11. ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性に設定された URL。
  12. グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。
ロールに基づく認証が失敗した場合のリダイレクト URL

ロールに基づく認証が失敗した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

  1. 認証モジュールで設定された URL。
  2. goto ログイン URL パラメータで設定された URL。
  3. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-failure-url 属性用に clientType カスタムファイルに設定された URL。
  4. ユーザーが認証を受けたロールの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  5. 認証されたユーザーの別のロールエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。このオプションは、前のリダイレクト URL が失敗した場合の代替リダイレクト URL です。
  6. ユーザーの組織エントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  7. グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  8. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-failure-url 属性に設定された URL。
  9. ユーザーが認証されたロールの iplanet-am-auth-login-failure-url 属性に設定された URL。
  10. 認証されたユーザーの別のロールエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。このオプションは、前のリダイレクト URL が失敗した場合の代替リダイレクト URL です。
  11. ユーザーの組織エントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
  12. グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性に設定された URL。

ロールに基づく認証を設定する

認証モジュールは、認証設定サービスをロールレベルで追加すると、ロール用に設定されます。

  1. 認証属性を設定する組織に移動します。
  2. 「表示」メニューから「ロール」を選択します。
  3. 認証設定を設定するロールを選択し、「プロパティ」の矢印をクリックします。

    4. ロールのプロパティがデータ区画に表示されます。

  4. データ区画の「表示」メニューから「サービス」を選択します。
  5. 必要に応じて「認証設定」属性を修正します。これらの属性の説明については、第 33 章「認証設定サービス属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。
  6. 「保存」をクリックします。

    7. .

    注

    新しいロールを作成している場合、そのロールに認証設定サービスは自動的に割り当てられません。ロールを作成する前に、ロールプロファイルページの上部で認証設定サービスを選択していることを確認してください。

    ロールベースの認証を有効にするときは、LDAP 認証モジュールはデフォルトのままにでき、メンバーシップを設定する必要はありません。

サービスに基づく認証

この認証方法では、ユーザーは組織またはサブ組織に登録された特定のサービスまたはアプリケーションに対する認証を受けることできます。このサービスは、認証設定サービス内でサービスインスタンスとして設定され、インスタンス名が関連付けられます。認証を成功させるには、ユーザーはサービスに設定された認証設定サービスインスタンスに定義された各モジュールに対して認証を受ける必要があります。サービスに基づく認証の各インスタンスに対して、次の属性を指定できます。

「認証設定」: サービスの認証プロセスに設定された認証モジュールを定義します。

「ログイン成功 URL」: 認証が成功した場合にユーザーがリダイレクトされる URL を定義します。

「ログイン失敗 URL」: 認証が失敗した場合にユーザーがリダイレクトされる URL を定義します。

「認証ポストプロセスクラス」: 認証後インタフェースを定義します。

サービスに基づく認証のログイン URL

サービスに基づく認証は、ユーザーインタフェースのログイン URL にサービスパラメータを定義して指定できます。サービスを呼び出した後、ユーザーが認証を受ける認証モジュールは、そのサービスに定義された認証設定サービスインスタンスから取得されます。

このサービスに基づく認証を指定し開始するログイン URL を次に示します。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?service=サービス 名

および

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?org=組織名 &service=サービス名

org パラメータが設定されていない場合、組織はログイン URL そのものに指定されたサーバーホストとドメインから判断されます。

サービスに基づく認証のリダイレクト URL

サービスに基づく認証が成功または失敗した時に、Access Manager はユーザーのリダイレクト先の情報を検索します。この情報をアプリケーションが検索する優先順位を次に示します。

サービスに基づく認証が成功した場合のリダイレクト URL

サービスに基づく認証が成功した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

  1. 認証モジュールで設定された URL。
  2. goto ログイン URL パラメータで設定された URL。
  3. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
  4. ユーザーが認証を受けたサービスの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  5. ユーザーのロールエントリの iplanet-am-auth-login-sucess-url 属性用に clientType カスタムファイルに設定された URL。
  6. ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  7. グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  8. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
  9. ユーザーが認証されたサービスの iplanet-am-auth-login-success-url 属性に設定された URL。
  10. ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
  11. ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性に設定された URL。
  12. グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。
サービスに基づく認証が失敗した場合のリダイレクト URL

サービスに基づく認証が失敗した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

  1. 認証モジュールで設定された URL。
  2. goto ログイン URL パラメータで設定された URL。
  3. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-failure-url 属性用に clientType カスタムファイルに設定された URL。
  4. ユーザーが認証を受けたサービスの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  5. ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  6. ユーザーの組織エントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  7. グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  8. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-failure-url 属性に設定された URL。
  9. ユーザーが認証されたサービスの iplanet-am-auth-login-failure-url 属性に設定された URL。
  10. ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
  11. ユーザーの組織エントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
  12. グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性に設定された URL。

サービスに基づく認証を設定する

認証モジュールは、認証設定サービスを追加すると、サービス用に設定されます。そのためには、次の手順を実行します。

  1. アイデンティティ (識別情報) 管理モジュールの「表示」メニューから、「サービス」を選択します。

    2. 追加済みのサービスのリストが表示されます。認証設定サービスを追加していない場合は、次の手順に進みます。サービスを追加済みの場合は、手順 4 に進みます。

  2. ナビゲーション区画で「追加」をクリックします。

    3. 利用可能なサービスのリストがデータ区画に表示されます。

  3. 「認証設定」のチェックボックスを選択し、「了解」をクリックします。

    4. 認証設定サービスがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  4. 「認証設定」の矢印をクリックします。

    5. 「サービスインスタンスリスト」がデータ区画に表示されます。

  5. 認証モジュールを設定するサービスインスタンスをクリックします。
  6. 「認証設定」属性を修正し、「保存」をクリックします。これらの属性の説明については、第 33 章「認証設定サービス属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

ユーザーに基づく認証

この認証方法では、ユーザーはユーザー専用に設定された認証プロセスに対する認証を受けることができます。このプロセスは、ユーザーのプロファイルの「ユーザー認証設定」属性の値として設定されます。認証を成功させるには、ユーザーは定義された各モジュールに対して認証する必要があります。

ユーザーに基づく認証のログイン URL

ユーザーに基づく認証は、ユーザーインタフェースのログイン URL にユーザーパラメータを定義して指定できます。正しいユーザーを呼び出した後、ユーザーが認証を受ける認証モジュールは、そのユーザーに定義されたユーザー認証インスタンスから取得されます。

このロールに基づく認証を指定し開始するログイン URL を次に示します。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?user=ユーザー名

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?org=組織名 &user=ユーザー名

org パラメータが設定されていない場合、ロールが属す組織はログイン URL そのものに指定されたサーバーホストおよびドメインから判断されます。

ユーザーエイリアスリスト属性

ユーザーに基づく認証の要求を受け取ると、認証サービスはまずユーザーが有効なユーザーであることを確認してから、ユーザーの認証設定データを取得します。ユーザーログイン URL パラメータの値に複数の有効なユーザープロファイルが関連付けられている場合は、すべてのプロファイルを指定されたユーザーにマップする必要があります。ユーザープロファイルのユーザーエイリアス属性 (iplanet-am-user-alias-list) には、ユーザーに属すその他のプロファイルを定義できます。マッピングが失敗すると、ユーザーは有効なセッションを拒否されます。ユーザーの 1 人がユーザーのマッピングの検証が行われない最上位の管理者であり、そのユーザーにスーパー管理者権限が与えられている場合は、例外です。

ユーザーに基づく認証のリダイレクト URL

ユーザーに基づく認証が成功または失敗した時に、Access Manager はユーザーのリダイレクト先の情報を検索します。この情報をアプリケーションが検索する優先順位を次に示します。

ユーザーに基づく認証が成功した場合のリダイレクト URL

ユーザーに基づく認証が成功した場合のリダイレクト URL は、次の場所を次の優先順位で確認することによって判断されます。

  1. 認証モジュールで設定された URL。
  2. goto ログイン URL パラメータで設定された URL。
  3. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
  4. ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  5. ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  6. グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  7. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
  8. ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
  9. ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性に設定された URL。
  10. グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーに基づく認証に失敗した場合のリダイレクト URL

ユーザーに基づく認証が失敗した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

  1. 認証モジュールで設定された URL。
  2. gotoOnFail ログイン URL パラメータで設定された URL。
  3. ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性用に clientType カスタムファイルに設定された URL。
  4. ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  5. ユーザーの組織エントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  6. グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  7. ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性に設定された URL。
  8. ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
  9. ユーザーの組織エントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
  10. グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性に設定された URL。

ユーザーに基づく認証を設定する

  1. アイデンティティ (識別情報) 管理モジュールの「表示」メニューから、「ユーザー」を選択します。

    2. ユーザーのリストがナビゲーション区画に表示されます。

  2. 修正したいユーザーを選択し、「プロパティ」の矢印をクリックします。

    3. ユーザープロファイルがデータ区画に表示されます。

    .

    注

    新しいユーザーを作成している場合、そのユーザーに認証設定サービスは自動的に割り当てられません。ユーザーを作成する前に、ユーザープロファイルページの上部で認証設定サービスを選択していることを確認してください。このオプションを選択しないと、ユーザーはロールに定義された認証設定を継承しません。

  3. 認証設定サービスがユーザーに割り当てられていることを確認するには、「表示」メニューで「サービス」を選択します。割り当てられている場合は、認証設定サービスが割り当て済みサービスとして表示されます。
  4. データ区画の「表示」メニューから「ユーザー」を選択します。
  5. 「ユーザー認証設定」属性の隣にある「編集」リンクをクリックして、ユーザー用の認証モジュールを定義します。
  6. 「保存」をクリックします。

認証レベルに基づく認証

それぞれの認証モジュールは、その認証レベルに整数値が関連付けられています。認証レベルを割り当てるには、「サービス設定」で認証モジュールの「プロパティ」矢印をクリックし、モジュールの認証レベル属性で対応する値を変更します。認証レベルが高いということは、1 つ以上の認証モジュールで認証を受けたそのユーザーの信頼性のレベルが高いということです。

ユーザーがそのモジュールに対する認証に成功すると、認証レベルがユーザーの SSO トークンに設定されます。複数の認証モジュールに対して認証を受ける必要があり、認証に成功した場合は、最高の認証レベルの値がユーザーの SSO トークンに設定されます。

ユーザーがサービスへのアクセスを試みる場合、サービスでは、そのユーザーの SSO トークンの認証レベルを確認することで、ユーザーがアクセスを許可されているかどうかを判別できます。次に、設定された認証レベルで認証モジュールにパスするように、ユーザーをリダイレクトします。

ユーザーは特定の認証レベルで認証モジュールにアクセスすることもできます。たとえばユーザーが次の構文でログインします。

認証レベルが認証レベル値以上であるすべてのモジュールが、ユーザーが選択するための認証メニューとして表示されます。一致するモジュールが 1 つしかなかった場合は、その認証モジュールのログインページが直接表示されます。

この認証の方法では、ID が認証を受けられるモジュールのセキュリティレベルを、管理者が指定できます。各認証モジュールには、それぞれの「認証レベル」属性があり、この属性の値は任意の有効な整数として定義できます。認証レベルに基づく認証では、認証サービスは、ログイン URL パラメータに指定された値以上の認証レベルを持つ認証モジュールを含むメニューを持つモジュールログインページを表示します。ユーザーは、提示されたリストからモジュールを選択します。ユーザーがモジュールを選択すると、以降のプロセスはモジュールに基づく認証に基づきます。

認証レベルに基づく認証のログイン URL

認証レベルに基づく認証は、ユーザーインタフェースのログイン URL に authlevel パラメータを定義して指定できます。関連するモジュールのリストを示すログイン画面を呼び出した後、ユーザーは認証を受けるモジュールを選択する必要があります。認証レベルに基づく認証を指定し開始するログイン URL を次に示します。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?authlevel=認証レ ベル

および

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?org=組織名 &authlevel=認証レベル

org パラメータが設定されていない場合、ユーザーが属す組織はログイン URL そのものに指定されたサーバーホストおよびドメインから判断されます。

認証レベルに基づく認証のリダイレクト URL

認証レベルに基づく認証が成功または失敗した時に、Access Manager はユーザーのリダイレクト先の情報を検索します。この情報をアプリケーションが検索する優先順位を次に示します。

認証レベルに基づく認証が成功した場合のリダイレクト URL

認証レベルに基づく認証が成功した場合のリダイレクト URL は、次の場所を次の優先順位で確認することによって判断されます。

  1. 認証モジュールで設定された URL。
  2. goto ログイン URL パラメータで設定された URL。
  3. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
  4. ユーザーのロールエントリの iplanet-am-auth-login-sucess-url 属性用に clientType カスタムファイルに設定された URL。
  5. ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  6. グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  7. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
  8. ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
  9. ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性に設定された URL。
  10. グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。
認証レベルに基づく認証が失敗した場合のリダイレクト URL

認証レベルに基づく認証が失敗した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

  1. 認証モジュールで設定された URL。
  2. gotoOnFail ログイン URL パラメータで設定された URL。
  3. ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性用に clientType カスタムファイルに設定された URL。
  4. ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  5. ユーザーの組織エントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  6. グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  7. ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性に設定された URL。
  8. ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
  9. ユーザーの組織エントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
  10. グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性に設定された URL。

モジュールに基づく認証

ユーザーは次の構文を使用して、特定の認証モジュールにアクセスできます。

http://ホスト名:ポート/配備_URI/UI/Login?module=モジュール名

認証モジュールにアクセスする前に、その認証モジュール名を含むように、コア認証サービス属性の組織認証モジュールを修正する必要があります。認証モジュール名がこの属性に含まれていない場合、ユーザーが認証を試みると「認証モジュールが拒否されました」ページが表示されます。

この認証の方法では、ユーザーは認証を受けるモジュールを指定できます。指定するモジュールは、ユーザーがアクセスする組織またはサブ組織に登録する必要があります。これは、組織のコア認証サービスの「組織認証モジュール」属性に設定されます。モジュールに基づく認証の要求を受け取ると、認証サービスは、モジュールが指定されたように正しく設定されていることを確認し、モジュールが定義されていない場合は、ユーザーはアクセスを拒否されます。

注

Access Manager コンソールを使用して認証モジュールを登録する方法については、第 7 章「認証オプション」を参照してください。

モジュールに基づく認証のログイン URL

モジュールパラメータを定義して、ユーザーインタフェースのログイン URL にモジュールに基づく認証を指定できます。モジュールに基づく認証を指定し開始するログイン URL を次に示します。

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?module=認証モ ジュール名

http://サーバー名.ドメイン名:ポート/amserver/UI/Login?org=組織名 &module=認証モジュール名

org パラメータが設定されていない場合、ユーザーが属す組織はログイン URL そのものに指定されたサーバーホストおよびドメインから判断されます。

モジュールに基づく認証のリダイレクト URL

モジュールに基づく認証が成功または失敗した時に、Access Manager はユーザーのリダイレクト先の情報を検索します。この情報をアプリケーションが検索する優先順位を次に示します。

モジュールに基づく認証が成功した場合のリダイレクト URL

モジュールに基づく認証が成功した場合のリダイレクト URL は、次の場所を次の優先順位で確認することによって判断されます。

  1. 認証モジュールで設定された URL。
  2. goto ログイン URL パラメータで設定された URL。
  3. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
  4. ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  5. ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  6. グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
  7. ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
  8. ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
  9. ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性に設定された URL。
  10. グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。
モジュールに基づく認証に失敗した場合のリダイレクト URL

モジュールに基づく認証が失敗した場合のリダイレクト URL は、次の場所を次の順序で確認することによって判断されます。

  1. 認証モジュールで設定された URL。
  2. gotoOnFail ログイン URL パラメータで設定された URL。
  3. ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性用に clientType カスタムファイルに設定された URL。
  4. ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  5. ユーザーの組織エントリの iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  6. グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性用に clientType カスタムファイルに設定された URL。
  7. ユーザーのエントリ (amUser.xml) の iplanet-am-user-failure-url 属性に設定された URL。
  8. ユーザーのロールエントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
  9. ユーザーの組織エントリの iplanet-am-auth-login-failure-url 属性に設定された URL。
  10. グローバルデフォルトとして iplanet-am-auth-login-failure-url 属性に設定された URL。

認証設定

認証設定サービスは、次の認証タイプ用の認証モジュールを定義するために使用します。

これらの認証タイプのいずれかで認証モジュールを定義すると、認証プロセスの成功または失敗に基づいて、リダイレクト URL、およびポストプロセス Java クラス仕様を提供するように設定できます。

認証モジュールを設定する前に、特定の認証モジュール名を含むように、コア認証サービス属性の組織認証モジュールを修正する必要があります。

認証設定のユーザーインタフェース

認証設定サービスでは、ユーザーがコンソール、または Access Manager 内でセキュリティ保護されたリソースにアクセスできるようになる前にパスしなければならない 1 つ以上の認証サービス (モジュール) を定義できます。組織、ロール、サービス、およびユーザーを基にした認証では、共通のユーザーインタフェースを使用して、認証モジュールを定義します。特定のオブジェクトタイプの認証設定インタフェースにアクセスする手順は、後続の節で説明します。

  1. オブジェクトの「認証設定」属性の隣にある「編集」リンクをクリックして、「モジュールリスト」ウィンドウを表示します。
  2. このウィンドウには、そのオブジェクトに割り当ててある認証モジュールのリストが表示されます。モジュールが存在しない場合は、「追加」をクリックして「モジュールを追加」ウィンドウを表示します。

    3. 「モジュールを追加」ウィンドウには、定義するファイルが 3 つあります。

    モジュール名: このプルダウンリストでは、コア認証モジュールの「組織認証モジュール」属性で有効になっている認証モジュール (追加されている可能性があるカスタムモジュールも含む) を選択できます。

    フラグ: プルダウンメニューで認証モジュールの要件を次のいずれかに指定できます。必須 - 認証には認証モジュールが必要です。

    • 必須 - 認証には認証モジュールが必要です。認証に成功または失敗すると、認証モジュールリストの次のモジュールへと認証が進行します。
    • 必要 - 認証には認証モジュールが必要です。認証に成功すると、認証モジュールリストの次のモジュールへと認証が進行します。認証に失敗すると、制御がアプリケーションに返されます。認証モジュールリストの次のモジュールには認証が進行しません。
    • 十分 - 認証に認証モジュールは不要です。認証に成功するとすぐに、制御がアプリケーションに返されます。この場合、認証モジュールリストの次のモジュールには認証が進行しません。認証に失敗すると、リストの次のモジュールへと認証が進行します。
    • オプション - 認証に認証モジュールは不要です。認証に成功または失敗しても、認証モジュールリストの次のモジュールへと認証が進行します。

      • 以上のフラグによって、認証モジュールの適用条件が確立されます。適用条件には上下関係があり、「必須」がもっとも高く、「オプション」がもっとも低くなります。

      たとえば、管理者が LDAP モジュールに「必須」フラグを設定している場合、ユーザーが特定のリソースにアクセスするためには、ユーザーの資格情報が LDAP の認証条件にパスすることが必要です。

      複数の認証モジュールを追加して各モジュールのフラグを「必須」に設定した場合、ユーザーがアクセスするためにはすべての認証条件にパスする必要があります。

      フラグの定義の詳細については、次のサイトの JAAS (Java Authentication and Authorization Service) を参照してください。

      http://java.sun.com/security/jaas/doc/module.html

      オプション: モジュールの追加オプションをキー=値のペアとして指定できます。複数のオプションを指定するときは、スペースで区切ります。

      図 6-1 ユーザー用の「モジュールを追加」ウィンドウ
      Identity Server コンソール - 認証設定、ユーザー用のモジュールリストの追加

  3. フィールドを選択したら、「OK」をクリックして「モジュールリスト」ウィンドウに戻ります。定義した認証モジュールがこのウィンドウに表示されます。「保存」をクリックします。

    4. このリストには必要なだけ多くの認証モジュールを追加できます。複数の認証モジュールを追加することを認証連鎖と言います。認証モジュールを連鎖している場合は、リストに表示される順番で、適用される階層の順序が決まります。認証連鎖については、「認証モジュール連鎖」を参照してください。

    認証モジュールの順番を変更するには、次の手順を実行します。

    1. 「並べ換え」ボタンをクリックします。
    2. 並べ換えるモジュールを選択します。
    3. 「上」および「下」のボタンを使用して、希望する位置に移動します。

  4. リストから認証モジュールを削除するには、認証モジュールの隣にあるチェックボックスを選択して「削除」をクリックします。

    5. 注

    連鎖内の任意のモジュールで amadmin クレデンシャルを入力した場合は、amadmin プロファイルを受信します。この場合は、認証でエイリアスのマッピングや連鎖内のモジュールは確認されません。

認証モジュール連鎖

1 つ以上の認証モジュールが設定できるので、ユーザーは認証クレデンシャルをすべての認証モジュールに渡す必要があります。これは、認証連鎖と呼ばれます。Access Manager での認証連鎖は、認証サービスに統合された JAAS フレームワークを使用して実現されます。モジュール連鎖は、認証設定サービスの下に設定されます。登録された各モジュールには、次の 4 つの値の 1 つが割り当てられます。

フラグによって定義されている、連鎖のモジュールの認証が成功すると、JAAS フレームワークから認証サービスに制御が戻り、認証サービスでは認証に使用したすべてのユーザー ID を検証し、それらの ID を 1 人のユーザーにマッピングします。マッピングは、ユーザーのプロファイルで「ユーザーエイリアスリスト」属性を設定して行います。すべてのマップが正しい場合は有効なセッショントークンがユーザーに発行され、そうでない場合は、ユーザーは有効なセッショントークンを拒否されます。次のプロパティは、ほかのユーザーがこのユーザーに対してエイリアス化される 1 人の認証済みユーザーを表します。

すべてのユーザー ID が同一ユーザーにマップされず、ユーザー ID の 1 つがローカルディレクトリサーバーに存在する場合は、プロファイルの動的な作成を有効にすると、その他のユーザー ID が既存のユーザーの「ユーザーエイリアスリスト」属性に追加されます。

注

  • 認証連鎖で、すべてのユーザー ID が同一ユーザーにマップされない場合、失敗のリダイレクト URL は、最後に失敗した認証モジュールから選択されるか、すべての個々のモジュールが (異なるユーザー ID で) 成功する場合はなしになります。ユーザーに基づく認証の場合、認証ページでどのユーザー ID が与えられようと、失敗のリダイレクト URL は常にログイン URL のユーザーパラメータから選択されます。
  • すべてのユーザー ID が同一ユーザーにマップされず、ユーザー ID の 1 つがローカルディレクトリサーバーに存在する場合は、プロファイルの動的な作成を有効にすると、その他のユーザー ID が既存のユーザーのユーザーエイリアスリスト属性に追加されます。

組織用の認証設定

認証モジュールは、最初にコア認証サービスを組織に追加することで、組織用に設定できます。

組織の認証属性を設定するには、次の手順を実行します。

  1. 認証属性を設定する組織に移動します。
  2. 「表示」メニューから「サービス」を選択します。
  3. サービスのリスト表示で、「コア」をクリックします。

    4. コア認証属性がデータ区画に表示されます。

  4. 管理者認証属性の隣にある「編集」リンクをクリックします。これにより、管理者専用に認証サービスを定義できます。この属性は、管理者とエンドユーザーの認証モジュールを別々のものにする必要がある場合に使用できます。デフォルトの認証モジュールは LDAP です。

    5. 認証サービスを定義したら、「保存」をクリックして変更内容を保存します。次に「閉じる」をクリックし、組織の「コア認証」属性に戻ります。

  5. 「組織認証設定」属性の隣にある「編集」リンクをクリックします。これにより、組織内の全ユーザー用に認証モジュールを定義できます。デフォルトの認証モジュールは LDAP です。
  6. 認証サービスを定義したら、「保存」をクリックして変更内容を保存します。次に「閉じる」をクリックし、組織の「コア認証」属性に戻ります。

ロール用の認証設定

認証モジュールは、認証設定サービスをロールレベルで追加すると、ロール用に設定されます。

  1. 認証属性を設定する組織に移動します。
  2. 「表示」メニューから「ロール」を選択します。
  3. 認証設定を設定するロールを選択し、「プロパティ」の矢印をクリックします。

    4. ロールのプロパティがデータ区画に表示されます。

  4. データ区画の「表示」メニューから「サービス」を選択します。
  5. 必要に応じて「認証設定」属性を修正します。これらの属性の説明については、第 33 章「認証設定サービス属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。
  6. 「保存」をクリックします。

    7. .

    注

    新しいロールを作成している場合、そのロールに認証設定サービスは自動的に割り当てられません。ロールを作成する前に、ロールプロファイルページの上部で認証設定サービスを選択していることを確認してください。

    ロールベースの認証を有効にするときは、LDAP 認証モジュールはデフォルトのままにでき、メンバーシップを設定する必要はありません。

サービス用の認証設定

認証モジュールは、認証設定サービスを追加すると、サービス用に設定されます。そのためには、次の手順を実行します。

  1. アイデンティティ (識別情報) 管理モジュールの「表示」メニューから、「サービス」を選択します。

    2. 追加済みのサービスのリストが表示されます。認証設定サービスを追加していない場合は、次の手順に進みます。サービスを追加済みの場合は、手順 4 に進みます。

  2. ナビゲーション区画で「追加」をクリックします。

    3. 利用可能なサービスのリストがデータ区画に表示されます。

  3. 「認証設定」のチェックボックスを選択し、「了解」をクリックします。

    4. 認証設定サービスがナビゲーション区画に表示され、追加されたことが管理者に示されます。

  4. 「認証設定」の矢印をクリックします。

    5. 「サービスインスタンスリスト」がデータ区画に表示されます。

  5. 認証モジュールを設定するサービスインスタンスをクリックします。
  6. 「認証設定」属性を修正し、「保存」をクリックします。これらの属性の説明については、第 33 章「認証設定サービス属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

ユーザー用の認証設定

  1. アイデンティティ (識別情報) 管理モジュールの「表示」メニューから、「ユーザー」を選択します。

    2. ユーザーのリストがナビゲーション区画に表示されます。

  2. 修正したいユーザーを選択し、「プロパティ」の矢印をクリックします。

    3. ユーザープロファイルがデータ区画に表示されます。

    .

    注

    新しいユーザーを作成している場合、そのユーザーに認証設定サービスは自動的に割り当てられません。ユーザーを作成する前に、ユーザープロファイルページの上部で認証設定サービスを選択していることを確認してください。このオプションを選択しないと、ユーザーはロールに定義された認証設定を継承しません。

  3. 認証設定サービスがユーザーに割り当てられていることを確認するには、「表示」メニューで「サービス」を選択します。割り当てられている場合は、認証設定サービスが割り当て済みサービスとして表示されます。
  4. データ区画の「表示」メニューから「ユーザー」を選択します。
  5. 「ユーザー認証設定」属性の隣にある「編集」リンクをクリックして、ユーザー用の認証モジュールを定義します。
  6. 「保存」をクリックします。

アカウントのロック

認証サービスには、n 回失敗すると、ユーザーが認証からロックアウトされる機能があります。この機能はデフォルトではオフになっていますが、Access Manager コンソールを使用して有効にできます。

注

無効なパスワード例外をスローするモジュールのみが、アカウントロック機能を利用できます。

コア認証サービスには、この機能を有効化およびカスタマイズするための次の属性 (ただし、これらに限定されない) が含まれています。

アカウントのロックアウトに関する電子メールの通知が、管理者に送信されます。アカウントロックのアクティビティはログにも記録されます。アカウントロックの属性については、第 20 章「コア認証属性」を参照してください。

注

Microsoft® Windows 2000 オペレーティングシステムでこの機能を使用する場合の特別な指示については、『Access Manager Developer's Guide』の付録 A、「AMConfig.properties File」の「Simple Mail Transfer Protocol (SMTP)」を参照してください。

Access Manager では、 物理ロックとメモリロックの 2 つのタイプのアカウントロックがサポートされます。次の節では、この 2 つについて説明します。

物理ロック

物理ロックは、Access Manager のデフォルトのロック動作です。ロックは、ユーザーのプロファイルの LDAP 属性の状態を非アクティブに変更することによって開始されます。「ロックアウト属性名」属性は、ロックの目的で使用する LDAP 属性を定義します。物理ロックの設定については、『Sun Java System Access Manager 管理ガイド』を参照してください。

注

エイリアス化されたユーザーとは、LDAP プロファイルで「ユーザーエイリアスリスト」属性 (amUser.xml の iplanet-am-user-alias-list) を設定して既存の LDAP ユーザープロファイルにマッピングされるユーザーのことです。エイリアス化されたユーザーは、コア認証サービスの「エイリアス検索属性名」フィールドに iplanet-am-user-alias-list を追加することによって確認できます。つまり、エイリアス化されたユーザーがロックアウトされると、ユーザーがエイリアス化された実際の LDAP プロファイルがロックされます。これは、LDAP およびメンバーシップ以外の認証モジュールの物理ロックアウトにのみ関係します。

メモリロック

メモリロックは、「ログイン失敗時のロックアウト持続時間」属性の値を 0 よりも大きな値に変更すると有効になります。有効にすると、ユーザーのアカウントは指定された時間メモリにロックされます。指定された期間が過ぎると、このアカウントはロック解除されます。メモリロック機能を使用する場合の考慮事項を次に示します。

認証サービスのフェイルオーバー

プライマリサーバーにハードウェアまたはソフトウェア上の問題で障害が発生した場合、または一時的にシャットダウンした場合には、認証サービスのフェイルオーバーにより、認証要求はセカンダリサーバーへ自動的にリダイレクトされます。

認証コンテキストは認証サービスが使用可能な Access Manager のインスタンス上でまず作成されなければなりません。Access Manager のこのインスタンスが使用できない場合は、認証フェイルオーバーメカニズムにより Access Manager の別のインスタンス上に認証コンテキストが作成されます。認証コンテキストは次のような順序でサーバーが使用可能かどうか確認します。

  1. 認証サービス URL を AutoContext API に送ります。次に例を示します。

    2. AuthContext(orgName, url)

    この API を使う場合は、URL で参照されたサーバーのみを使用します。この場合、そのサーバー上で認証サービスが使用可能であっても、フェイルオーバーは起きません。

  2. 認証コンテキストが AMConfig.properties ファイルの com.iplanet.am.server* 属性に定義されたサーバーをチェックします。
  3. 手順 2 で失敗すると、認証コンテキストはネーミングサービスが利用可能なサーバーからのプラットフォームリストを照会します。ディレクトリサーバーの 1 つのインスタンスを共有する複数のインスタンスが、(主にフェイルオーバーを目的として) Access Manager 上にインストールされたときに、このプラットフォームリストが自動的に作成されます。

    4. たとえば、プラットフォームリストに Server1、Server2、および Server3 の URL が含まれていると、認証コンテキストは Server1、Server2、および Server3 のいずれかで認証が成功するまでループします。

プラットフォームリストは、ネーミングサービスの有無に依存しているので、常に同一のサーバーから得られるわけではありません。さらに、ネーミングサービスのフェイルオーバーが最初に起こります。複数ネーミングサービス URL は AMConfing.properties の com.iplanet.am.naming.url プロパティに定義されます。利用可能な最初のネーミングサービス URL は、認証フェイルオーバーが発生する (プラットフォームサーバーリスト中の) サーバーのリストを持つサーバーを特定するのに使われます。

完全修飾ドメイン名のマッピング

完全修飾ドメイン名 (FQDN) のマッピングは、ユーザーが誤った URL を入力した (保護されたリソースにアクセスするために部分的なホスト名または IP アドレスを指定したなど) 場合に認証サービスが訂正を行うことができるようにします。FQDN のマッピングは、AMConfig.properties ファイルで com.sun.identity.server.fqdnMap 属性を変更することによって可能になります。このプロパティは次の形式で指定します。

com.sun.identity.server.fqdnMap[invalid-name]=valid-name

invalid-name の値はユーザーが入力する可能性がある無効な FQDN ホスト名であり、valid-name はフィルタがユーザーをリダイレクトする実際のホスト名です。定められた要件に準拠するかぎり、コード例 1-1 に示すようにいくつでもマッピングを指定できます。このプロパティを設定しない場合は、ユーザーは com.iplanet.am.server.host=server_name プロパティに設定されたデフォルトのサーバー名に送信されます。このプロパティも AMConfig.properties ファイルにあります。

コード例 6-1 AMConfig.propertiesの FQDN マッピング属性

com.sun.identity.server.fqdnMap[isserver]=isserver.mydomain.com

com.sun.identity.server.fqdnMap[isserver.mydomain]=isserver.mydomain.com

com.sun.identity.server.fqdnMap[IP address]=isserver.mydomain.com

FQDN のマッピングの使用例

このプロパティは、サーバーにホストされたアプリケーションが複数のホスト名でアクセス可能な場合に、複数のホスト名のマッピングを作成するために使用できます。このプロパティを使用して、特定の URL について Access Manager が訂正を行わないように設定することもできます。たとえば、IP アドレスを使用してアプリケーションにアクセスするユーザーにリダイレクトが必要ない場合は、この機能は次のようなマップエントリを指定して実現できます。

com.sun.identity.server.fqdnMap[IP アドレス]=IP アドレス

警告

複数のマッピングを定義する場合は、無効な FQDN 名で値が重複しないようにします。そのようにしないと、アプリケーショににアクセスできなくなる場合があります。

持続 Cookie

持続 Cookie とは、Web ブラウザを閉じたあとも存在する Cookie のことであり、ユーザーが再認証なしに新しいブラウザセッションにログインすることを可能にします。Cookie の名前は、AMConfig.properties の com.iplanet.am.pcookie.name プロパティに定義されます。デフォルト値は、DProPCookie です。Cookie の値は、3DES で暗号化された文字列であり、この文字列には、ユーザー DN、組織名、認証モジュール名、最大セッション時間、アイドル時間、およびキャッシュ時間が含まれます。持続 Cookie を有効にするには、次のようにします。

  1. コア認証モジュールで「持続 Cookie モード」をオンにします。
  2. コア認証モジュールで「Cookie の最大持続時間」属性の時間値を設定します。
  3. ユーザーインタフェースのログイン URL に yes の値で iPSPCookie パラメータを付加します。

    4. ユーザーがこの URL を使用して認証を受けると、ブラウザを閉じた場合、新しいブラウザウィンドウを開くことができ、再認証なしにコンソールにリダイレクトされます。手順 2 で定義された時間が経過するまでこのようになります。

持続 Cookie モードは、次の認証 SPI メソッドを使用してオンにできます。

AMLoginModule.setPersistentCookieOn()

複数 LDAP 認証モジュールの設定

フェイルオーバーの形式として、あるいは、Access Manager コンソールで値フィールドが 1 つだけ提供されている場合に、属性に複数の値を設定するために、管理者は 1 つの組織に複数の LDAP 認証モジュール設定を定義できます。これら追加の設定はコンソールに表示されませんが、要求を行っているユーザーの承認が初期検索で見つからない場合に、主設定とともに機能します。たとえば、1 つの組織で 2 つの異なるドメインでの認証に LDAP サーバーを介した検索を定義したり、あるいは 1 つのドメインに複数のユーザーネーミング属性を設定できます。後者の場合、コンソールにはテキストフィールドが 1 つのみあり、第 1 の検索基準でユーザーが見つからない場合は、LDAP モジュールは第 2 の検索範囲で検索します。追加の LDAP 構成を設定する手順を次に示します。

追加の LDAP 構成を設定する

  1. 2 番目 (または 3 番目の) LDAP 認証設定に必要な属性および新しい値の完全なセットを含めた XML ファイルを作成します。

    2. 利用可能な属性は、etc/opt/SUNWam/config/xml にある amAuthLDAP.xml で参照できます。この手順で作成された XML ファイルは、amAuthLDAP.xml とは異なり、amadmin.dtd の構造に基づいています。このファイルには、任意のまたはすべての属性を定義できます。コード例 6-2 は、LDAP 認証設定に利用できるすべての属性の値が含まれる副設定ファイルの例です。

    コード例 6-2 LDAP の副設定を追加するための XML ファイルの例 

    <?xml version="1.0" encoding="ISO-8859-1"?>

    <!--

      Copyright (c) 2002 Sun Microsystems, Inc. All rights reserved.

      Use is subject to license terms.

    -->

    <!DOCTYPE Requests

        PUBLIC "-//iPlanet//Sun ONE Identity Server 6.0 Admin CLI DTD//EN"

        "jar://com/iplanet/am/admin/cli/amAdmin.dtd"

    >

    <!--

      Before adding subConfiguration load the schema with

    GlobalConfiguration defined and replace corresponding

    serviceName and subConfigID in this sample file OR load

    serviceConfigurationRequests.xml before loading this sample

    -->

    <Requests>

    <OrganizationRequests DN="dc=iplanet,dc=com">

        <AddSubConfiguration subConfigName = "ssc"

            subConfigId = "serverconfig"

            priority = "0" serviceName="iPlanetAMAuthLDAPService">

            <AttributeValuePair>

                <Attribute name="iplanet-am-auth-ldap-server"/>

                <Value>newvalue</Value>

            </AttributeValuePair>

            <AttributeValuePair>

                <Attribute name="iplanet-am-auth-ldap-server"/>

                <Value>vbrao.red.iplanet.com:389</Value>

            </AttributeValuePair>

            <AttributeValuePair>

                <Attribute name="iplanet-am-auth-ldap-base-dn"/>

                <Value>dc=iplanet,dc=com</Value>

            </AttributeValuePair>

            <AttributeValuePair>

                <Attribute name="planet-am-auth-ldap-bind-dn"/>

                <Value>cn=amldapuser,ou=DSAME Users,dc=iplanet,dc=com</Value>

            </AttributeValuePair>

            <AttributeValuePair>

                <Attribute name="iplanet-am-auth-ldap-bind-passwd"/>

                <Value>プレーンテキストのパスワード</Value>

            </AttributeValuePair>

            <AttributeValuePair>

                <Attribute name="iplanet-am-auth-ldap-user-naming-attribute"/>

                <Value>uid</Value>

            </AttributeValuePair>

            <AttributeValuePair>

                <Attribute name="iplanet-am-auth-ldap-user-search-attributes"/>

                <Value>uid</Value>

            </AttributeValuePair>

            <AttributeValuePair>

                <Attribute name="iplanet-am-auth-ldap-search-scope"/>

                <Value>SUBTREE</Value>

            </AttributeValuePair>

            <AttributeValuePair>

                <Attribute name="iplanet-am-auth-ldap-ssl-enabled"/>

                <Value>false</Value>

            </AttributeValuePair>

            <AttributeValuePair>

                <Attribute name="iplanet-am-auth-ldap-return-user-dn"/>

                <Value>true</Value>

            </AttributeValuePair>

            <AttributeValuePair>

                <Attribute name="iplanet-am-auth-ldap-auth-level"/>

                <Value>0</Value>

            </AttributeValuePair>

            <AttributeValuePair>

                <Attribute name="iplanet-am-auth-ldap-server-check"/>

                <Value>15</Value>

            </AttributeValuePair>

        </AddSubConfiguration>

    </OrganizationRequests>

    </Requests>

  2. 手順 1 で作成した XML ファイルで iplanet-am-auth-ldap-bind-passwd の値としてプレーンテキストのパスワードをコピーします。

    3. この属性の値は、41 ページのコード例 1-2 に太字で示されています。

  3. amadmin コマンド行ツールを使用して、XML ファイルをロードします。

    4. ./amadmin -u amadmin -w administrator_password -v -t name_of_XML_file.

この 2 番目の LDAP 設定は、Access Manager コンソールを使用して表示も変更もできません。

ヒント

複数 LDAP 設定に利用できるサンプルが用意されています。/AcessManager-base/SUNWam/samples/admin/cli/bulk-ops/ にある serviceAddMultipleLDAPConfigurationRequests.xml コマンド行テンプレートを参照してください。手順については、/AcessManager-base/SUNWam/samples/admin/cli/ にある Readme.html を参照してください。

セッションのアップグレード

認証サービスでは、1 つの組織に対して同一ユーザーが実行した 2 回目の成功した認証に基づいて有効なセッショントークンのアップグレードを行うことができます。有効なセッショントークンを持つユーザーが、現在の組織によってセキュリティ保護されているリソースに対して認証を試み、この 2 回目の認証が成功すると、セッションは新しい認証に基づく新しいプロパティで更新されます。認証が失敗すると、ユーザーの現在のセッションがアップグレードなしに戻されます。有効なセッショントークンを持つユーザーが別の組織によってセキュリティ保護されているリソースに対して認証を試みると、新しい組織の認証を受けるどうかを尋ねるメッセージを受け取ります。この時点では、ユーザーは、現在のセッションを維持するか、または新しい組織の認証を受けることができます。認証が成功すると、古いセッションは破棄され、新しいセッションが作成されます。

セッションのアップグレード時に、ログインページの時間切れになると、元の成功 URL へのリダイレクトが発生します。タイムアウト値は、次の条件に基づいて判断されます。

com.iplanet.am.invalidMaxSessionTimeout と iplanet-am-max-session-time の値は、ページタイムアウト値よりも大きい必要があり、そうでない場合はセッションアップグレード時に有効なセッション情報が失われ、前回の成功 URL へのリダイレクトは失敗します。

検証プラグインインタフェース

管理者は、組織に適したユーザー名またはパスワード検証ロジックを作成し、そのロジックを認証サービスにプラグインできます。この機能は、LDAP およびメンバーシップの認証モジュールのみでサポートされます。ユーザーを認証したりパスワードを変更する前に、Access Manager はこのプラグインを呼び出します。検証が成功すると、認証が継続され、失敗すると、認証失敗ページがスローされます。プラグインは、サービス管理 SDK の一部である com.iplanet.am.sdk.AMUserPasswordValidation クラスを拡張します。SDK についての情報は、Access Manager Javadocs の com.iplanet.am.sdk パッケージを参照してください。次の手順は、Access Manager 用の検証プラグインを作成および設定する方法を示しています。

  1. 新しいプラグインクラスは、com.iplanet.am.sdk.AMUserPasswordValidation クラスを拡張し、validateUserID() および validatePassword() メソッドを実装します。検証が失敗した場合は、AMException がスローされます。
  2. プラグインクラスをコンパイルし、.class ファイルを必要な場所に配置します。実行時に Access Manager がプラグインにアクセスできるように、クラスパスを更新します。
  3. 最上位の管理者として Access Manager コンソールにログインします。「サービス管理」タブをクリックし、管理サービスの属性にアクセスします。「ユーザー ID とパスワードの検証プラグインクラス」フィールドにパッケージ名を含むプラグインクラスの名前を入力します。
  4. ログアウトし、ログインし直します。

JAAS 共有状態

JAAS 共有状態は、認証モジュール間でユーザー ID とパスワードの両方の共有を実現します。各認証モジュールに対して次のオプションを定義します。

失敗した場合、モジュールは必要なクレデンシャルを要求します。認証の失敗後、モジュールが停止するか、ログアウト共有状態がクリアされます。

JAAS 共有状態の有効化

JAAS 共有状態を設定するには、次のようにします。

失敗すると、認証モジュールは、JAAS の仕様で提案される tryFirstPass オプションの動作ごとに必要なクレデンシャルを要求します。

JAAS 共有状態ストアオプション

「JAAS 共有状態ストア」オプションを設定するには、次のようにします。

コミット、中断、またはログアウト後に、共有状態はクリアされます。



前へ      目次      索引      次へ     

Part No: 819-1938.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.