第 8 章認証オプション

Sun Java^TM System Identity Server 2004Q2 では、認証のフレームワークを備えています。認証とは、エンタープライズ内のアプリケーションにアクセスするユーザーのアイデンティティを確認するためのプロセスです。ユーザーは、Identity Server コンソールまたは Identity Server で保護されたリソースにアクセスする前に、認証プロセスにパスする必要があります。認証は、ユーザーのアイデンティティを検証するプラグインによって実装されます。このプラグインアーキテクチャの詳細については、『Identity Server Developer's Guide』で説明します。

Identity Server コンソールは、デフォルト値の設定、認証サービスの追加、認証テンプレートの作成、およびサービスの有効化のために使用されます。この章では、認証サービスの概要と追加手順について説明します。この章は、次の節で構成されています。

コア認証

Identity Server では、コア認証サービスばかりではなく、デフォルトで 11 種類の認証サービスを提供しています。コア認証サービスでは、認証サービスに対する全体的な設定を行います。匿名、証明書に基づく、HTTP 基本、LDAP、メンバーシップ、NT、RADIUS、SafeWord、SecurID、Windows デスクトップ SSO および UNIX 認証を追加して有効にする前に、コア認証サービスを追加して有効にする必要があります。コア認証サービスおよび LDAP 認証サービスは両方とも、デフォルトの組織に対して自動的に有効になります。第 20 章「コア認証属性」に、コア属性の詳細な一覧を示します。

コアサービスを追加し、有効にする

コアサービスを追加する組織に移動します。

「表示」メニューから「サービス」を選択します。

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

利用可能なサービスの一覧がデータ区画に表示されます。

「認証」「コア」のチェックボックスを選択し、「了解」をクリックします。

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

「認証」「コア」の矢印をクリックします。

「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

「はい」をクリックします。

コア属性がデータ区画に表示されます。必要に応じて属性を修正します。コア属性の説明については、第 20 章「コア認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

匿名認証

デフォルトでは、このモジュールを有効にすると、ユーザーは anonymous ユーザーとして Identity Server にログインできるようになります。「有効な匿名ユーザーリスト」属性 (237 ページ参照) を設定して、このモジュールに匿名ユーザーの一覧を定義することもできます。匿名アクセスを許可するということは、パスワードなしでアクセスさせるということです。匿名アクセスは、特定の種類のアクセス (読み取りのためのアクセスや検索のためのアクセスなど)、特定のサブツリー、またはディレクトリ内の個別のエントリに制限されます。

匿名認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Identity Server にログインする必要があります。

匿名認証を追加する組織に移動します。

「表示」メニューから「サービス」を選択します。

コアサービスが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、匿名認証サービスとともに追加されます。

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

利用可能なサービスの一覧がデータ区画に表示されます。

「匿名認証」のチェックボックスを選択し、「了解」をクリックします。

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

「認証」「匿名」の矢印をクリックします。

「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

「はい」をクリックします。

匿名認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 18 章「匿名認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

「保存」をクリックします。

匿名認証サービスが有効になります。

匿名認証を使用してログインする

匿名認証を使用してログインするには、「組織認証モジュール」というコア認証サービス属性で、匿名認証を有効にして選択するように修正する必要があります。そうすると、ユーザーが http(s)://ホスト名:ポート/サーバー_配備_URI//UI/Login?module=Anonymous&org=組織名を使用してログインするときに、匿名認証のログインウィンドウが表示されます。匿名認証のログインウィンドウを表示せずにログインするには、次の構文を使用します。

http(s)://ホスト名:ポート/サーバー_配備_URI/UI/Login?module=Anonymous&org=組織名&Login.Token1=user_id

使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。



注	匿名認証サービスのデフォルトの匿名ユーザー名属性値は anonymous です。ユーザーがログインするときは、この名前が使用されます。デフォルトの匿名ユーザーを組織内に作成する必要があります。そのユーザー ID は、匿名認証属性で指定されているユーザー名と同一にする必要があります。大文字と小文字を区別するようにもできます。

証明書に基づく認証

証明書に基づく認証では、個人用デジタル証明書 (PDC) を使用してユーザーを特定し、認証します。Directory Server に格納された PDC に一致すること、また証明書失効リスト (CRL) で確認されていることを求めるように、PDC を設定できます。

証明書に基づく認証サービスを組織に追加する前に、行う必要のある作業があります。まず、Identity Server とともにインストールした Web コンテナを保護し、証明書に基づく認証で使用できるように設定する必要があります。証明書に基づくサービスを有効にする前に、Web Server に対するこれらの初期設定手順について、『Sun ONE Web Server 6.1 管理者ガイド』の第 6 章「証明書と鍵の使用」を参照してください。このマニュアルは、次の場所にあります。

または、次の場所にある『Sun ONE Application Sever Administrator's Guide to Security』を参照してください。

http://docs.sun.com/db/prod/entsys?l=ja



注	証明書に基づくサービスを使用して認証されるユーザーは、ブラウザ用に PDC を要求する必要があります。使用しているブラウザによって、手順が異なります。詳細は、お使いのブラウザのマニュアルを参照してください。

証明書に基づく認証を追加し、有効にする

組織管理者として、Identity Server にログインする必要があります。

証明書に基づく認証を追加する組織に移動します。

「表示」メニューから「サービス」を選択します。

コアサービスが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、証明書に基づく認証サービスとともに追加されます。

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

利用可能なサービスの一覧がデータ区画に表示されます。

「証明書」のチェックボックスを選択し、「了解」をクリックします。

証明書に基づく認証サービスがナビゲーション区画に表示され、追加されたことが管理者に示されます。

「認証」「証明書」の矢印をクリックします。

「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

「はい」をクリックします。

証明書に基づく認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 19 章「証明書認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

「保存」をクリックします。

証明書に基づく認証のプラットフォームサーバーリストにサーバー URL を追加する

このサービスを追加するためには、Identity Server に組織管理者としてログインし、Identity Server と Web コンテナに対して SSL を設定し、クライアント認証を有効化しておく必要があります。詳細は、「Identity Server を SSL モードに設定する」を参照してください。

証明書に基づく認証を使用してログインする

証明書に基づく認証をデフォルトの認証方法として設定するには、コア認証サービス属性である「組織認証モジュール」 (250 ページ参照) を修正する必要があります。そうすると、ユーザーが https://ホスト名:ポート/配備_URI/UI/Login?module=Cert を使用してログインするときに、証明書に基づく認証のログインウィンドウが表示されます。使用している認証タイプ (ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。

HTTP 基本認証

HTTP プロトコルのビルトイン認証サポートである基本認証を使用します。Web サーバーはユーザー名とパスワードを求めるクライアント要求を発行し、その情報を認証済み要求の一部としてサーバーに返します。Identity Server ではユーザー名とパスワードを受信し、LDAP 認証モジュールに対してユーザーを内部的に認証します。HTTP 基本認証が正常に機能するために、LDAP 認証モジュールを追加する必要があります (HTTP 基本モジュールを単独で追加しても機能しない)。詳細は、「LDAP 認証を追加し、有効にする」を参照してください。いったん認証に成功したユーザーには、以降の認証でユーザー名とパスワードの入力は要求されません。

HTTP 基本認証を追加し、有効にする

組織管理者または最上位レベル管理者としてIdentity Serverにログインし、LDAP 認証サービスを前もって登録しておきます。

HTTP 基本認証を追加する組織に移動します。

「表示」メニューから「サービス」を選択します。

コアサービスが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、HTTP 基本認証サービスとともに追加されます。

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

利用可能なサービスの一覧がデータ区画に表示されます。

「HTTP 基本」のチェックボックスを選択し、「了解」をクリックします。

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

「認証」「HTTP 基本」の矢印をクリックします。

「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

「はい」をクリックします。

HTTP 基本認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 21 章「HTTP 基本認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

「保存」をクリックします。

HTTP 基本認証サービスが有効になります。

HTTP 基本認証を使用してログインする

HTTP 基本認証を使用してログインするには、「組織認証モジュール」というコア認証サービス属性で、HTTP 基本認証を有効にして選択するように修正する必要があります。そうすると、ユーザーが http://ホスト名:ポート/サーバー_配備_URI/UI/Login?module=HTTPBasic を使用してログインするときに、HTTP 基本認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。認証に失敗した場合、ユーザーは新しいインスタンスを開いてログインし直す必要があります。HTTP 基本認証を使用したあとに完全にログアウトするには、存在するすべてのブラウザインスタンスを閉じて、新しいブラウザインスタンスを開始する必要があります。

LDAP ディレクトリ認証

LDAP 認証サービスを使用すると、ユーザーがログインするときに、特定のユーザー DN およびパスワードを使用して、LDAP Directory Server にバインドする必要があります。すべての組織ベースの認証では、デフォルトの認証モジュールです。ユーザーが Directory Server に存在するユーザー ID およびパスワードを指定すると、ユーザーは有効な Identity Server セッションへのアクセスが許可され、セットアップされます。コア認証サービスおよび LDAP 認証サービスは両方とも、デフォルトの組織に対して自動的に有効になります。このサービスが無効である場合の手順を次に示します。

LDAP 認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Identity Server にログインする必要があります。

LDAP 認証を追加する組織に移動します。

「表示」メニューから「サービス」を選択します。

コアサービスが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、LDAP 認証サービスとともに追加されます。

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

利用可能なサービスの一覧がデータ区画に表示されます。

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

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

「認証」「LDAP」の矢印をクリックします。

「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

「はい」をクリックします。

LDAP 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 22 章「LDAP 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

パスワードを「root ユーザーバインドパスワード」属性に入力します。デフォルトで、インストール中に入力した amldapuser パスワードが、バインドユーザーとして使用されます。匿名アクセスでのユーザーエントリ読み出しを Directory Server が許可する場合は、この手順はスキップできます。

別のバインドユーザーを使用するには、「root ユーザーバインド DN」でユーザーの DN を変更し、そのユーザーのパスワードを「root ユーザーバインドパスワード」に入力します。

「保存」をクリックします。

LDAP 認証サービスが有効になります。

LDAP 認証を使用してログインする

LDAP 認証を使用してログインするには、「組織認証モジュール」というコア認証サービス属性で、LDAP 認証を有効にして選択するように修正する必要があります。そうすると、ユーザーが http://ホスト名:ポート/サーバー_配備_URI/UI/Login?module=LDAP を使用してログインするときに、LDAP 認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。

LDAP 認証のフェイルオーバーを有効にする

LDAP 認証属性には、プライマリとセカンダリ両方の Directory Server の値フィールドがあります。プライマリサーバーが利用できなくなると、Identity Server では、認証を行うために、セカンダリサーバーを使用します。詳細は、「プライマリ LDAP サーバー」および「セカンダリ LDAP サーバー」の LDAP 属性を参照してください。

複数の LDAP 設定

フェイルオーバーの形式として、あるいは、Identity Server コンソールで値フィールドが 1 つだけ提供されている場合に、属性に複数の値を設定するために、管理者は 1 つの組織に複数の LDAP 設定を定義できます。これら追加の設定はコンソールに表示されませんが、要求を行っているユーザーの承認が初期検索で見つからない場合に、主設定とともに機能します。複数の LDAP 設定については、『Identity Server Developer's Guide』の「Multi LDAP Configuration」を参照してください。

メンバーシップ認証

メンバーシップ認証は、my.site.com または mysun.sun.com のように、パーソナライズされたサイトのように実装されます。サービスが有効なときに、ユーザーは管理者の支援なしでアカウントを作成し、パーソナライズします。ユーザーは作成したアカウントを使用し、追加済みユーザーとしてアクセスできます。また、ユーザーはビューアのインタフェースにアクセスできます。ビューアのインタフェースは、認証データおよびユーザー設定として、ユーザープロファイルデータベースに保存されています。

メンバーシップ認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Identity Server にログインする必要があります。

メンバーシップ認証を追加する組織に移動します。

「表示」メニューから「サービス」を選択します。

コアサービスが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、メンバーシップ認証サービスとともに追加されます。

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

利用可能なサービスの一覧がデータ区画に表示されます。

「メンバーシップ認証」のチェックボックスを選択し、「了解」をクリックします。

メンバーシップ認証サービスがナビゲーション区画に表示され、追加されたことが管理者に示されます。

「認証」「メンバーシップ」の矢印をクリックします。

「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

「はい」をクリックします。

メンバーシップ認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 23 章「メンバーシップ認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

パスワードを「root ユーザーバインドパスワード」に入力します。デフォルトで、インストール中に入力した amldapuser パスワードが、バインドユーザーとして使用されます。

「保存」をクリックします。

メンバーシップ認証サービスが有効になります。

メンバーシップ認証を使用してログインする

メンバーシップ認証を使用してログインするには、「組織認証モジュール」というコア認証サービス属性で、メンバーシップ認証を有効にして選択するように修正する必要があります。そうすると、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=Membership を使用してログインするときに (大文字と小文字の区別に注意)、メンバーシップ認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。

NT 認証

Identity Server は、すでにインストールされている NT または Windows 2000 サーバーで使用できるように設定できます。Identity Server では、NT 認証のクライアント部分を担当します。NT 認証サービスは、Solaris プラットフォームでのみサポートされています。

NT サーバーを設定します。詳しい手順については、NT サーバーのマニュアルを参照してください。

NT 認証サービスを追加し、有効にする前に、Samba クライアントを入手してインストールし、Solaris システム上の Identity Server と通信できるようにする必要があります。詳細は、「NT 認証属性」を参照してください。

NT 認証サービスを追加し、有効にします。

Samba クライアントのインストール

NT 認証モジュールをアクティブにするには、Samba Client 2.2.2 をダウンロードして次のディレクトリにインストールする必要があります。

Samba Client は、Windows マシンと UNIX マシンを共存させるためのファイルサーバー兼プリントサーバーで、専用の Windows NT/2000 Server を必要としません。詳細とダウンロードについては、http://wwws.sun.com/software/download/products/3e3af224.html を参照してください。

Red Hat Linux とともに出荷される Samba クライアントは、次のディレクトリに置かれています。

Linux 用 NT 認証サービスを使って認証を行うためには、クライアントのバイナリを Identity Server の次のディレクトリにコピーします。

IdentityServer_base/SUNWam/dtd/



注	複数のインタフェースがある場合には、追加の設定が必要です。複数のインタフェースは smb.conf ファイルで設定し、それを mbclient へ伝えることにより、設定できます。

NT 認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Identity Server にログインする必要があります。

NT 認証を追加する組織に移動します。

「表示」メニューから「サービス」を選択します。

コアサービスが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、NT 認証サービスとともに追加されます。

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

利用可能なサービスの一覧がデータ区画に表示されます。

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

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

「認証」「NT」の矢印をクリックします。

「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

「はい」をクリックします。

NT 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 24 章「NT 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

「保存」をクリックします。

NT 認証サービスが有効になります。

NT 認証を使用してログインする

NT 認証を使用してログインするには、「組織認証モジュール」というコア認証サービス属性で、NT 認証を有効にして選択するように修正する必要があります。そうすると、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=NT を使用してログインするときに、NT 認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。

RADIUS サーバー認証

Identity Server は、すでにインストールされている RADIUS サーバーで使用できるように設定できます。エンタープライズで認証のためにレガシーの RADIUS サーバーを使用している場合に便利です。RADIUS 認証サービスを有効にするには、次の 2 つの手順を行います。

RADIUS サーバーを設定します。

詳しい手順については、RADIUS サーバーのマニュアルを参照してください。

RADIUS 認証サービスを登録し、有効にします。

RADIUS 認証を追加し、有効にする

組織管理者として、Identity Server にログインする必要があります。

RADIUS 認証を追加する組織に移動します。

「表示」メニューから「サービス」を選択します。

コアサービスが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、RADIUS 認証サービスとともに追加されます。

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

利用可能なサービスの一覧がデータ区画に表示されます。

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

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

「認証」「RADIUS」の矢印をクリックします。

「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

「はい」をクリックします。

RADIUS 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 25 章「RADIUS 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

「保存」をクリックします。

RADIUS 認証サービスが有効になります。

RADIUS 認証を使用してログインする

RADIUS 認証を使用してログインするには、「組織認証モジュール」というコア認証サービス属性で、RADIUS 認証を有効にして選択するように修正する必要があります。そうすると、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=RADIUS を使用してログインするときに、RADIUS 認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。

RADUIS クライアントがそのサーバーに対してソケット接続を作成するとき、デフォルトでは、Application Server の server.policy ファイルで SocketPermission の connect アクセス権だけが与えられています。RADUIS 認証を正常に機能させるには、次のアクションを許可する必要があります。

accept (受け入れ)

connect (接続)

listen (待機)

resolve (解決)

ソケット接続のアクセス権を与えるには、Application Server の server.policy ファイルにエントリを追加します。SocketPermission は、ホストの指定と、そのホストへの接続方法を指定する一連のアクションとで構成されます。ホストは次のように指定されます。

host = hostname | IPaddress:portrange:portrange = portnumber | -portnumberportnumber-portnumber

ホストは、DNS 名または IP アドレスの数値で表されるか、ローカルマシンの場合は localhost と表されます。DNS 名でホストを指定する場合は、ワイルドカード "*" を 1 つだけ使用できます。ワイルドカードを使用する場合は、*.example.com のように、左端に置く必要があります。

ポート (portrange) は省略可能です。N- という形式のポート指定は、N またはそれ以上の番号を持つすべてのポートを表します。ここで、N はポート番号です。-N という形式のポート指定は、N またはそれ以下の番号を持つすべてのポートを表します。

listen アクションは、ローカルホストで使用される場合のみ有効です。resolve (ホスト/IP 解決のネームサービスルックアップ) アクションは、ほかのアクションで暗黙的に使用されます。

たとえば、SocketPermission を作成するときに次のアクセス権をコードに与えると、そのコードは machine1.example.com のポート 1645 に接続することと、そのポート上で接続を受け入れることができます。

permission java.net.SocketPermission machine1.example.com:1645, "connect,accept";

同様に、次のアクセス権を与えられたコードは、ローカルホストのポート 1024 ～ 65535 に接続することと、これらのポートで接続受け入れおよび待機を行うことができます。

permission java.net.SocketPermission "machine1.example.com:1645", "connect,accept";

permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";



注	リモートホストに対する接続受け入れや接続作成のアクセス権をコードに与えると、悪意のあるコードによって、本来アクセス権を持たない第三者に機密データが転送されたり共有されたりしやすくなるので、問題が発生することがあります。適切なアクセス権だけを与えるために、ポート番号を範囲で指定するのではなく、正確なポート番号を指定してください。

SafeWord 認証

Secure Computing の SafeWord^TM または SafeWord PremierAccess^TM 認証サーバーで SafeWord 認証要求を処理するように、Identity Server を設定できます。Identity Server では、SafeWord 認証のクライアント部分を担当します。SafeWord サーバーは、Identity Server のインストールされているシステムにも、別のシステムにも置くことができます。

SafeWord 認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Identity Server にログインする必要があります。

SafeWord 認証を追加する組織に移動します。

「表示」メニューから「サービス」を選択します。

コアサービスが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、SafeWord 認証サービスとともに追加されます。

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

利用可能なサービスの一覧がデータ区画に表示されます。

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

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

「認証」「SafeWord」の矢印をクリックします。

「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

「はい」をクリックします。

SafeWord 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 26 章「SafeWord 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

「保存」をクリックします。

SafeWord 認証サービスが有効になります。

SafeWord 認証を使用してログインする

SafeWord 認証を使用してログインするには、「組織認証モジュール」というコア認証サービス属性で、SafeWord 認証を有効にして選択するように修正する必要があります。そうすると、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=SAFEWORD を使用してログインするときに、SafeWord 認証のログインウィンドウが表示されます。使用している認証タイプ (ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。

Sun ONE Application Server で SafeWord を設定する

SafeWord クライアントがそのサーバーに対してソケット接続を作成するとき、デフォルトでは、Application Server の server.policy ファイルで SocketPermission の connect アクセス権だけが与えられています。SafeWord 認証を正常に機能させるには、次のアクションを許可する必要があります。

accept (受け入れ)

connect (接続)

listen (待機)

resolve (解決)

host = (hostname | IPaddress)[:portrange] portrange = portnumber | -portnumberportnumber-[portnumber]

permission java.net.SocketPermission machine1.example.com:5030, "connect,accept";

permission java.net.SocketPermission "machine1.example.com:5030", "connect,accept";

permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";



注	リモートホストに対する接続受け入れや接続作成のアクセス権をコードに与えると、悪意のあるコードによって、本来アクセス権を持たない第三者に機密データが転送されたり共有されたりしやすくなるので、問題が発生することがあります。適切なアクセス権だけを与えるために、ポート番号を範囲で指定するのではなく、正確なポート番号を指定してください。

SecurID 認証

RSA の ACE/Server 認証サーバーで SecureID 認証要求を処理するように、Identity Server を設定できます。Identity Server では、SecurID 認証のクライアント部分を担当します。ACE/Server は、Identity Server のインストールされているシステムにも、別のシステムにも置くことができます。ローカルで管理されたユーザー ID を認証する (admintool (1M) 参照) には、ルートでアクセスする必要があります。

SecurID 認証では、認証ヘルパ amsecuridd を使用します。認証ヘルパはメイン Identity Server プロセスとは独立したプロセスです。起動すると、このヘルパは設定情報を得るためにポートで待機します。Identity Server が nobody、またはルート以外のユーザー ID で実行するようにインストールされている場合でも、IdentityServer_base/SUNWam/share/bin/amsecuridd プロセスはルートユーザーとして実行する必要があります。amsecuridd ヘルパについての詳細は、「amsecuridd ヘルパ」を参照してください。

SecurID 認証を追加し、有効にする

組織管理者または最上位レベル管理者として、Identity Server にログインする必要があります。


注	Identity Server のこのリリースでは、 Linux または Solaris x86 プラットフォームでは SecurID 認証サービスを利用できません。

SecureID 認証を追加する組織に移動します。

「表示」メニューから「サービス」を選択します。

コアサービスが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、SecurID 認証サービスとともに追加されます。

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

利用可能なサービスの一覧がデータ区画に表示されます。

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

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

「認証」「SecurID」の矢印をクリックします。

「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

「はい」をクリックします。

SecureID 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 27 章「SecurID 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

「保存」をクリックします。

SecurID 認証サービスが有効になります。

SecurID 認証を使用してログインする

SecureID 認証を使用してログインするには、「組織認証モジュール」というコア認証サービス属性で、SecureID 認証を有効にして選択するように修正する必要があります。そうすると、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=SecurID を使用してログインするときに、SecurID 認証のログインウィンドウが表示されます。使用している認証タイプ (ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。

UNIX 認証

Identity Server がインストールされている Solaris または Linux システムで既知の UNIX ユーザー ID およびパスワードに対する認証要求を処理するように、Identity Server を設定できます。UNIX 認証では組織属性は 1 つだけしかなく、またグローバル属性は少ししかありませんが、システムの観点から検討すべき点があります。ローカルで管理されたユーザー ID を認証する (admintool (1M) 参照) には、ルートでアクセスする必要があります。

UNIX 認証では、認証ヘルパ amunixd を使用します。認証ヘルパはメイン Identity Server プロセスとは独立したプロセスです。起動すると、このヘルパは設定情報を得るためにポートで待機します。UNIX ヘルパは Identity Server ごとに 1 つだけあり、そのすべての組織で共用されます。

Identity Server が nobody、またはルートユーザー以外のユーザー ID で実行するようにインストールされている場合でも、IdentityServer_base/SUNWam/share/bin/amunixd プロセスはルートユーザーとして実行する必要があります。UNIX 認証モジュールは、UNIX 認証要求を待機するために localhost:58946 へのソケットを開くことで、amunixd デーモンを呼び出します。デフォルトのポートで amunixd ヘルパを実行するには、次のコマンドを入力します。

デフォルト以外のポートで amunixd ヘルパを実行するには、次のコマンドを入力します。

IP アドレスとポート番号は、AMConfig.properties 内の UnixHelper.ipadrs 属性 (IPV4 形式) と UnixHelper.port 属性で指定されています。amunixd を amserver コマンド行ユーティリティーから実行することもできます。amserver は AMConfig.properties からポート番号と IP アドレスを取り出し、このプロセスを自動的に実行します。

/etc/nsswitch.conf ファイル内の passwd エントリでは、/etc/passwd および /etc/shadow ファイル、または NIS を認証で探すかどうかを指定します。

UNIX 認証を追加し、有効にする

以下の手順では、最上位レベル管理者として、Identity Server にログインする必要があります。

サービス設定モジュールを選択します。

「サービス名」リストで、「認証」「UNIX」の矢印をクリックします。

グローバル属性および組織属性が表示されます。1 つの UNIX ヘルパで Identity Server サーバーの組織をすべて提供するため、UNIX 属性のほとんどはグローバルです。これらの属性の説明については、第 28 章「UNIX 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

「保存」をクリックして、属性の新しい値を保存します。

組織管理者として Identity Server にログインすると、組織に対する UNIX 認証を有効にできます。

UNIX 認証を追加する組織に移動します。

「表示」メニューから「サービス」を選択します。

コアサービスが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、UNIX 認証サービスとともに追加されます。

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

利用可能なサービスの一覧がデータ区画に表示されます。

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

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

「認証」「UNIX」の矢印をクリックします。

「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

「はい」をクリックします。

UNIX 認証の組織属性がデータ区画に表示されます。必要に応じて認証レベル属性を修正します。この属性の説明については、第 28 章「UNIX 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

「保存」をクリックします。UNIX 認証サービスが有効になります。

UNIX 認証を使用してログインする

UNIX 認証を使用してログインするには、「組織認証モジュール」というコア認証サービス属性で、UNIX 認証を有効にして選択するように修正する必要があります。そうすると、ユーザーが http://ホスト名:ポート/配備_URI/UI/Login?module=Unix を使用してログインするときに、UNIX 認証のログインウィンドウが表示されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。

Windows デスクトップ SSO 認証

Windows デスクトップ SSO 認証サービスは、Windows 2000^TM に使用する、Kerberos ベースのプラグインモジュールです。このサービスを使用すると、Kerberos Distribution Center (KDC) で認証されたユーザーは、ログインの条件を再度提示しなくても Identity Server に認証されます。

Windows デスクトップ SSO 認証を追加し、有効にする

Windows デスクトップ SSO 認証サービスを有効にするには、次の 3 つの手順を実行します。

Windows 2000 のドメインコントローラにユーザーを作成します。

Internet Explorer をセットアップします。

Windows デスクトップ SSO 認証サービスを追加し、設定します。

Windows 2000 のドメインコントローラにユーザーを作成する

ドメインコントローラで、Identity Server 認証サービス用のユーザーアカウントを作成します。

「スタート」メニューから、「プログラム」>「管理ツール」に進みます。

「Active Directory ユーザーとコンピュータ」を選択します。

Identity Server ホスト名がユーザー ID (ログイン名) の新しいユーザーを作成します。Identity Server ホスト名には、ドメイン名を含めないでください。

ユーザーアカウントをサービスプロバイダの名前と関連付け、Keytab ファイルを Identity Server がインストールされたシステムにエクスポートします。そのためには、次のコマンドを実行します。

ktpass -princ host/hostname.domainname@DCDOMAIN -pass password -mapuser userName-out hostname.host.keytab

ktpass -princ HTTP/hostname.domainname@DCDOMAIN -pass password -mapuser userName-out hostname.host.keytab

ktpass コマンドには、次のパラメータを使用できます。

hostname: Identity Server が実行されるホスト名 (ドメイン名なし)。

domainname: Identity Server のドメイン名。

DCDOMAIN: ドメインコントローラのドメイン名。この名前は、Identity Server のドメイン名とは異なる場合があります。

password: ユーザーアカウントのパスワード。ktpass はパスワードを検証しないので、パスワードが正しいことを確認します。

userName: ユーザーアカウント ID。これはホスト名と同じである必要があります。



注	両方の Keytab ファイルがセキュリティ保護されているようにします。

サーバーを再起動します。

Internet Explorer をセットアップする

「ツール」メニューで、「インターネットオプション」>「詳細設定」>「セキュリティ」に進みます。

「統合 Windows 認証を使用する」オプションを選択します。

「セキュリティ」>「イントラネット」に進みます。

「レベルのカスタマイズ」を選択します。「ユーザー認証」の「ログオン」で「イントラネットゾーンでのみ自動的にログオンする」オプションを選択します。

「サイト」に進み、すべてのオプションを選択します。

「詳細設定」をクリックして、Identity Server をローカルゾーンに追加します (まだ追加されていない場合)。



注	この手順は、Microsoft Internet Explorer^TM 6 以上に当てはまります。これよりも前のバージョンを使用している場合は、Identity Server がブラウザのインターネットゾーンにあり、ネイティブ Windows 認証が有効であることを確認します。

Windows デスクトップ SSO 認証を追加し、設定する

組織管理者または最上位レベル管理者として、Identity Server にログインする必要があります。

Windows デスクトップ SSO 認証を追加する組織に移動します。

「表示」メニューから「サービス」を選択します。

コアサービスが追加済みの場合は、ナビゲーション区画に表示されます。追加済みでない場合は、Windows デスクトップ SSO 認証サービスとともに追加されます。

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

利用可能なサービスの一覧がデータ区画に表示されます。

「Window デスクトップ SSO 認証」のチェックボックスを選択し、「了解」をクリックします。

Windows デスクトップ SSO 認証サービスがナビゲーション区画に表示され、追加されたことが管理者に示されます。

「認証」「Window デスクトップ SSO 認証」の矢印をクリックします。

「現在このサービスにはテンプレートが存在しません。新規に作成しますか?」というメッセージがデータ区画に表示されます。

「はい」をクリックします。

Windows デスクトップ SSO 認証属性がデータ区画に表示されます。必要に応じて属性を修正します。これらの属性の説明については、第 29 章「Windows デスクトップ SSO 認証属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

「保存」をクリックします。Windows デスクトップ SSO 認証サービスが有効になります。

Windows デスクトップ SSO 認証を使用してログインする

Windows デスクトップ SSO 認証を使用してログインするには、「組織認証モジュール」というコア認証サービス属性で、Windows デスクトップ SSO 認証を有効にして選択するように修正する必要があります。これで、Windows 2000 のドメインコントローラの一部であるホストに http://ホスト名:ポート/配備_URI/UI/Login?module=WindowsDesktopSSO を使ってすでにドメインユーザーとしてログインしているユーザーが、そのホストからログインしても正しく認証されます。使用している認証タイプ (サービス、ロール、ユーザー、組織など) によっては、認証モジュールをデフォルトとして設定する場合に、URL でモジュール名を指定する必要がありません。

認証設定

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

組織

ロール

サービス

ユーザー

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

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

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

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

オブジェクトの認証設定属性の隣にある「編集」リンクをクリックして、「モジュールリスト」ウィンドウを表示します。

このウィンドウには、そのオブジェクトに割り当ててある認証モジュールの一覧が表示されます。モジュールが存在しない場合は、「追加」をクリックして「モジュールを追加」ウィンドウを表示します。

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

「モジュール名」:このプルダウンリストでは、Identity Server で利用可能な認証モジュールを選択できます (追加されたカスタムモジュールを含む)。デフォルトでは、次のモジュールがあります。

LDAP

証明書

匿名

SafeWord

SecurID

HTTP 基本

メンバーシップ

RADIUS

UNIX

Windows デスクトップ SSO

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

REQUIRED - 認証には認証モジュールが必要です。認証に成功または失敗すると、認証モジュール一覧の次のモジュールへと認証が進行します。

REQUISITE - 認証には認証モジュールが必要です。認証に成功すると、認証モジュール一覧の次のモジュールへと認証が進行します。認証に失敗すると、制御がアプリケーションに返されます。認証モジュール一覧の次のモジュールには認証が進行しません。

SUFFICIENT - 認証に認証モジュールは不要です。認証に成功するとすぐに、制御がアプリケーションに返されます。この場合、認証モジュール一覧の次のモジュールには認証が進行しません。認証に失敗すると、一覧の次のモジュールへと認証が進行します。

OPTIONAL - 認証に認証モジュールは不要です。認証に成功または失敗しても、認証モジュール一覧の次のモジュールへと認証が進行します。

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

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

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

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

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

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

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

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

「並べ換え」ボタンをクリックします。

並べ換えるモジュールを選択します。

「上」および「下」のボタンを使用して、希望する位置に移動します。

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



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

組織用の認証設定

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

認証属性を設定する組織に移動します。

「表示」メニューから「サービス」を選択します。

サービスのリスト表示で、「コア」をクリックします。

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

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

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

組織認証設定属性の隣にある「編集」リンクをクリックします。これにより、組織内の全ユーザー用に認証モジュールを定義できます。デフォルトの認証モジュールは LDAP です。

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

ロール用の認証設定

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

認証属性を設定する組織に移動します。

「表示」メニューから「ロール」を選択します。

認証設定を設定するロールを選択し、「プロパティ」の矢印をクリックします。

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

データ区画の「表示」メニューから「サービス」を選択します。

必要に応じて認証設定属性を修正します。これらの属性の説明については、第 30 章「認証設定サービス属性」を参照するか、またはコンソール右上の「ヘルプ」リンクをクリックしてください。

「保存」をクリックします。



注	新しいロールを作成している場合、そのロールに認証設定サービスは自動的に割り当てられません。ロールを作成する前に、ロールプロファイルページの上部で認証設定サービスを選択していることを確認してください。ロールベースの認証を有効にするときは、LDAP 認証モジュールはデフォルトのままにでき、メンバーシップを設定する必要はありません。

サービス用の認証設定

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

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

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

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

利用可能なサービスの一覧がデータ区画に表示されます。

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

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

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

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

認証モジュールを設定するサービスインスタンスをクリックします。

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

ユーザー用の認証設定

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

ユーザーの一覧がナビゲーション区画に表示されます。

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

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



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

認証設定サービスがユーザーに割り当てられていることを確認するには、「表示」メニューで「サービス」を選択します。割り当てられている場合は、認証設定サービスが割り当て済みサービスとして表示されます。

データ区画の「表示」メニューから「ユーザー」を選択します。

ユーザー認証設定属性の隣にある「編集」リンクをクリックして、ユーザー用の認証モジュールを定義します。

「保存」をクリックします。

認証レベルによる認証

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

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

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

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

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

モジュールに基づいた認証

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

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

URL のリダイレクト

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

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

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

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

認証サービス URL を AutoContext API に送る
例

AuthContext(orgName, url)

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

認証コンテキストが AMConfig.properties ファイルのcom.iplanet.am.server* 属性に定義されたサーバーをチェックする

手順 2 で失敗すると、認証コンテキストはネーミングサービスが利用可能なサーバーからのプラットフォームリストを照会する。ディレクトリサーバーの 1 つのインスタンスを共有する複数のインスタンスが、(主にフェイルオーバーを目的として) Identity Server 上にインストールされたときに、このプラットフォームリストが作成される

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

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

前へ目次索引次へ
Sun Java System Identity Server 2004Q2 管理ガイド