Sun Java System Access Manager 7 2005Q4 管理ガイド

第 7 章認証の管理

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

認証の設定

ここでは、配備の認証を設定する方法について説明します。最初の節では、デフォルトの認証モジュールタイプの概要について説明し、必要な事前の設定手順を示します。レルム、ユーザー、ロールなどに対して、同じ認証モジュールタイプの複数の設定インスタンスを設定できます。また、認証に成功するためには複数のインスタンスの条件に合格する必要があるようにするため、認証連鎖を追加することもできます。次の内容で構成されています。

認証モジュールタイプ

認証モジュールは、ユーザー ID やパスワードなどのユーザー情報を収集し、その情報をデータベース内のエントリで確認するプラグインです。ユーザーが認証条件を満たす情報を入力した場合、そのユーザーは要求するリソースへのアクセスを許可されます。ユーザーが認証条件を満たしていない情報を入力した場合、そのユーザーは要求したリソースへのアクセスを拒否されます。Access Manager は、次の 15 タイプの認証モジュールとともにインストールされます。

注 –

一部の認証モジュールタイプでは、認証インスタンスとして使用できるようにするには、事前の設定が必要です。必要に応じて、設定手順がモジュールタイプの説明にリスト表示されています。

コア

Access Manager では、コア認証モジュールばかりではなく、デフォルトで 15 種類の認証モジュールを提供しています。コア認証モジュールでは、認証モジュールの全体的な設定を行います。Active Directory 認証、匿名認証、証明書に基づく認証、HTTP 基本認証、JDBC 認証、LDAP 認証、任意の認証のモジュールを追加して有効にする前に、コア認証モジュールの追加と有効化を行う必要があります。コア認証モジュールおよび LDAP 認証モジュールは両方とも、デフォルトのレルムに対して自動的に有効になります。

「拡張プロパティー」ボタンをクリックすると、レルムに対して定義できる「コア」認証属性が表示されます。グローバル属性はレルムに適用できないので表示されません。

Active Directory

Active Directory 認証モジュールでは、LDAP モジュールと同様の認証が実行されますが、LDAP 認証モジュールの場合の Directory Server ではなく、Microsoft の Active Directory™ サーバーが使用されます。LDAP 認証モジュールを Active Directory サーバー用に設定できますが、このモジュールでは、LDAP と Active Directory 認証の両方を同一レルム下に存在させることができます。

注 –

このリリースの Active Directory 認証モジュールでは、ユーザー認証のみがサポートされます。パスワードポリシーは LDAP 認証モジュールのみでサポートされます。

匿名 (anonymous)

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

証明書

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

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

http://docs.sun.com/db/prod/s1websrv#hic

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

http://docs.sun.com/db/prod/s1appsrv#hic

注 –

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

このモジュールを追加するためには、Access Manager にレルム管理者としてログインし、Access Manager と Web コンテナに対して SSL を設定し、クライアント認証を有効化しておく必要があります。詳細は、第 3 章「Access Manager の SSL モードへの設定」を参照してください。

HTTP 基本

このモジュールは、HTTP プロトコルのビルトイン認証サポートである基本認証を使用します。Web サーバーはユーザー名とパスワードを求めるクライアント要求を発行し、その情報を認証済み要求の一部としてサーバーに返します。Access Manager ではユーザー名とパスワードを取得し、LDAP 認証モジュールに対してユーザーを内部的に認証します。HTTP 基本認証が正常に機能するために、LDAP 認証モジュールを追加する必要があります (HTTP 基本モジュールを単独で追加しても機能しない)。いったん認証に成功したユーザーには、再認証の際にユーザー名とパスワードの入力は要求されません。

JDBC

JDBC (Java Database Connectivity) 認証モジュールでは、JDBC 技術に対応したドライバを提供する SQL データベースを通して Access Manager でユーザーを認証できるようにするメカニズムが提供されます。SQL データベースへの接続は、JDBC ドライバを通して直接行うか、JNDI 接続プールで行います。

注 –

このモジュールは、MySQL4.0 と Oracle 8i でテストされています。

LDAP

LDAP 認証モジュールを使用すると、ユーザーがログインするときに、特定のユーザー DN およびパスワードを使用して、LDAP Directory Server にバインドする必要があります。すべてのレルムに基づく認証では、デフォルトの認証モジュールです。ユーザーが Directory Server に存在するユーザー ID およびパスワードを指定すると、ユーザーは有効な Access Manager セッションへのアクセスが許可され、セットアップされます。コア認証モジュールおよび LDAP 認証モジュールは両方とも、デフォルトのレルムに対して自動的に有効になります。

メンバーシップ

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

MSISDN

MSISDN (Mobile Station Integrated Services Digital Network) 認証モジュールでは、携帯電話などのデバイスに関連するモバイル加入者 ISDN を使用して認証できます。これは対話型モジュールではありません。このモジュールでは加入者 ISDN が取得されて Directory Server で妥当性が検査され、番号が一致するユーザーが検索されます。

RADIUS

Access Manager は、すでにインストールされている RADIUS サーバーと連携するように設定できます。エンタープライズで認証のために旧バージョンの RADIUS サーバーを使用している場合に便利です。RADIUS 認証モジュールを有効にするには、次の 2 つの手順を行います。

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

詳しい手順については、RADIUS サーバーのマニュアルを参照してください。
RADIUS 認証モジュールを登録し、有効にします。

Sun Java System Application Server で RADIUS を設定する

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 のように、左端に置く必要があります。

ポート (またはポート範囲) は省略可能です。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™ または SafeWord PremierAccessd™ 認証サーバーに対して送られる SafeWord 認証要求を処理するように、Access Manager を設定できます。Access Manager は、SafeWord 認証のクライアント部分を担当します。SafeWord サーバーは、Access Manager のインストールされているシステムにも、別のシステムにも置くことができます。

Sun Java System Application Server で SafeWord を設定する

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

accept (受け入れ)
connect (接続)
listen (待機)
resolve (解決)

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

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

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";

注 –

SAML

SAML (Security Assertion Markup Language) 認証モジュールでは、ターゲットサーバーで SAML アサーションの受信と確認が行われます。このモジュールが、Access Manager 2005Q1 から Access Manager 2005Q4 などのアップグレード後も含めて、ターゲットマシンで設定されている場合にかぎって、SAML SSO は動作します。

SecurID

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

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

注 –

このリリースの Access Manager の場合、Linux プラットフォームと Solaris x86 プラットフォームでは SecurID 認証モジュールを使用できません。この 2 つのプラットフォームでは、SecurID 認証モジュールの登録、設定、有効化を行わないでください。SecurID 認証モジュールは、SPARC のみで使用できます。

UNIX

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

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

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

./amunixd

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

./amunixd [-c portnm] [ipaddress]

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

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

Windows デスクトップ SSO

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

ユーザーは、SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) プロトコルで Access Manager に Kerberos トークンを送信します。この認証モジュールで Access Manager への Kerberos ベースのシングルサインオンを実行するには、ユーザーが、クライアントサイドにおいて、SPNEGO プロトコルをサポートして自分自身を認証する必要があります。一般的に、このプロトコルをサポートするすべてのユーザーは、このモジュールを使用して Access Manager に認証できます。クライアントサイドでトークンを使用できるかどうかにより、SPENGO トークンか Kerberos トークンがこのモジュールによって提供されます。どちらの場合でもプロトコルは同一です。Microsoft Windows 2000 以上で動作している Microsoft Internet Explorer 5.01 以上では、現在このプロトコルがサポートされています。Solaris 9 および 10 の Mozilla 1.4 では SPNEGO がサポートされますが、Solaris では SPNEGO がサポートされていないので、返されるトークンは KERBEROS トークンのみです。

注 –

Kerberos V5 認証モジュールの新機能を使用するには、JDK 1.4 以上を使用する必要があります。この SPNEGO モジュールで Kerberos ベースの SSO を実行するには、Java GSS API を使用する必要があります。

Internet Explorer の既知の制限事項

WindowsDesktopSSO 認証に Microsoft Internet Explorer 6.x を使用しており、WindowsDesktopSSO モジュールで設定されている KDC レルムと一致する、ユーザーの Kerberos/SPNEGO トークンにこのブラウザでアクセスできない場合、WindowsDesktopSSO モジュールへの認証がエラーになったあとで、このブラウザはその他のモジュールに対して不正に動作します。この問題の直接的な原因は、Internet Explorer が WindowsDesktopSSO モジュールでエラーになると、ブラウザを再起動するまで、コールバックを要求されても、別のモジュールのコールバックを Access Manager に渡すことができなくなることです。このため、WindowsDesktopSSO のあとのすべてのモジュールは、ユーザー資格が NULL であるためにエラーとなります。

関連情報については、次の資料を参照してください。

http://support.microsoft.com/default.aspx?scid=kb;en-us;308074

http://www.wedgetail.com/jcsi/sso/doc/guide/troubleshooting.html#ieNTLM

Windows デスクトップ SSO の設定

Windows デスクトップ SSO 認証を有効にするプロセスには、次の 2 つの段階があります。

Windows 2000 のドメインコントローラにユーザーを作成します。
Internet Explorer をセットアップします。

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

手順

ドメインコントローラで、Access Manager 認証モジュール用のユーザーアカウントを作成します。
1. 「スタート」メニューから、「プログラム」>「管理ツール」に進みます。
2. 「Active Directory ユーザーとコンピュータ」を選択します。
3. Access Manager ホスト名をユーザー ID (ログイン名) として新しいユーザーを作成します。Access Manager ホスト名には、ドメイン名を含めないでください。

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

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
.HTTP.keytab

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

hostname: Access Manager が稼働する、ドメイン名なしのホスト名です。

domainname: Access Manager のドメイン名です。

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

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

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

注 –

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

サービステンプレートの値は、次の例のようになっている必要があります。

「サービス主体」: HTTP/machine1.EXAMPLE.COM@ISQA.EXAMPLE.COM

「Keytab ファイル名」: /tmp/machine1.HTTP.keytab

「Kerberos レルム」: ISQA.EXAMPLE.COM

「Kerberos サーバー名」: machine2.EXAMPLE.com

「ドメイン名を含む主体を返す」: false

「認証レベル」: 22

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

Internet Explorer をセットアップする

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

手順

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

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

「セキュリティー」>「イントラネット」に進みます。
1. 「レベルのカスタマイズ」を選択します。「ユーザー認証」の「ログオン」で「イントラネットゾーンでのみ自動的にログオンする」オプションを選択します。
2. 「サイト」に進み、すべてのオプションを選択します。
3. 「詳細設定」をクリックして、Access Manager をローカルゾーンに追加します (まだ追加されていない場合)。

Windows NT

Access Manager は、すでにインストールされている Windows NT サーバーまたは Windows 2000 サーバーで使用できるように設定できます。Access Manager は、NT 認証のクライアント部分を担当します。

NT サーバーを設定します。詳しい手順については、Windows NT サーバーのマニュアルを参照してください。
Windows NT 認証モジュールを追加し、有効にする前に、Samba クライアントを入手してインストールし、Solaris システム上の Access Manager と通信できるようにする必要があります。

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

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

AccessManager-base/SUNWam/bin

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

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

/usr/bin

Linux 用 Windows NT 認証モジュールを使って認証を行うためには、クライアントのバイナリを Access Manager の次のディレクトリにコピーします。

AccessManager-base/sun/identity/bin

注 –

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

認証モジュールインスタンス

デフォルトの認証モジュールに基づいて、複数の認証モジュールインスタンスをレルム用に作成できます。同じ認証モジュールを元に、個別に設定した複数のインスタンスを追加できます。

新しい認証モジュールインスタンスを作成する

手順

新しい認証モジュールインスタンスを追加するレルムの名前をクリックします。

「認証」タブを選択します。

注 –
「管理者認証設定」ボタンにより、管理者専用に認証サービスを定義できます。この属性は、管理者とエンドユーザーの認証モジュールを別々のものにする必要がある場合に使用できます。この属性で設定したモジュールは、Access Manager コンソールにアクセスするときに選択されます。

「モジュールインスタンス」リストの「新規」をクリックします。

認証モジュールインスタンスの名前を入力します。名前は一意にする必要があります。

レルムの認証モジュールタイプの「タイプ」を選択します。

「作成」をクリックします。

新しく作成したモジュールインスタンスの名前をクリックし、そのモジュールのプロパティーを編集します。各モジュールタイプのプロパティーの定義については、オンラインヘルプの「認証」の節を参照してください。

複数のモジュールインスタンスを追加するときは、これらの手順を繰り返します。

認証連鎖

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

新しい認証連鎖を作成する

手順

新しい認証連鎖を追加するレルムの名前をクリックします。

「認証」タブを選択します。

「認証連鎖」リストの「新規」をクリックします。

認証連鎖の名前を入力します。

「作成」をクリックします。

「追加」をクリックし、連鎖に含める認証モジュールインスタンスを定義します。そのためには、「インスタンス」リストからモジュールインスタンス名を選択します。このリストに表示されるモジュールインスタンス名は、「モジュールインスタンス」属性で作成されます。

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

必要

認証にはモジュールインスタンスが必要です。認証に成功すると、「認証連鎖」リストの次のインスタンスへと認証が進行します。認証に失敗すると、制御がただちにアプリケーションに返されます。この場合、「認証連鎖」リストの次のインスタンスには認証が進行しません。

必須

認証には、このモジュールへの認証が必要です。この連鎖の必須モジュールのいずれかが失敗すると、最終的に認証連鎖全体が失敗します。ただし、必須モジュールが成功しても失敗しても、連鎖の次のモジュールへと制御が進行します。

十分

認証にモジュールインスタンスは必要ありません。認証に成功するとすぐに、制御がアプリケーションに返されます。この場合、モジュールインスタンスリストの次のインスタンスには認証が進行しません。認証に失敗すると、「認証連鎖」リストの次のインスタンスへと認証が進行します。

オプション

認証にモジュールインスタンスは必要ありません。認証に成功しても失敗しても、「認証連鎖」リストの次のインスタンスへと認証が進行します。

連鎖のオプションを入力します。これにより、モジュールの追加オプションがキーと値のペアとして有効になります。複数のオプションを指定するときは、スペースで区切ります。

次の属性を定義します。

「成功したログイン URL」

認証が成功した場合にユーザーをリダイレクトする URL を指定します。

「失敗したログイン URL」

認証が成功しなかった場合にユーザーをリダイレクトする URL を指定します。

「認証ポストプロセスクラス」

ログインが成功または失敗したあとに認証ポストプロセスのカスタマイズに使用する Java クラスの名前を定義します。

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

認証タイプ

認証サービスは、さまざまな認証適用方法を提供します。それらの異なる認証方法にアクセスするには、ログイン URL パラメータを指定するか、認証 API を使用します。詳細については、『Sun Java System Access Manager 7 2005Q4 Developer’s Guide』の第 5 章「Using Authentication APIs and SPIs」を参照してください。認証モジュールを設定する前に、特定の認証モジュール名を含むように、コア認証サービス属性のレルム認証モジュールを修正する必要があります。

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

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

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

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

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

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

コア認証モジュールには、値として認証ポストプロセスクラス名を含む「認証ポストプロセスクラス」属性が含まれています。AMPostAuthProcessInterface は、ポストプロセスインタフェースです。このインタフェースは、認証の成功または失敗時、またはログアウト時に実行できます。
セッショントークンで次のプロパティーが追加または更新され、ユーザーのセッションがアクティブになります。

realm: これは、ユーザーが所属するレルムの DN です。

Principal: ユーザーの DN です。

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

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

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

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

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

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

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

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

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

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

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

Service: サービスに基づく認証にのみ適用可能であり、ユーザーが属すサービスです。
Access Manager は、成功または失敗した認証のあとにユーザーをリダイレクトする場所についての情報を検索します。

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

URL のリダイレクト

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

レルムに基づく認証

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

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

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

domain パラメータ。
realm パラメータ。

管理サービスの「DNS エイリアス名」属性の値。

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

http://server_name.domain_name:port/amserver/UI/Login
http://server_name.domain_name:port/amserver/UI/Login?domain=domain_name
http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name

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

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

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

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

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

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。

レルムに基づく認証に失敗した場合のリダイレクト URL

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

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

レルムに基づく認証を設定する

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

レルムの認証属性を設定する

手順

認証連鎖を追加するレルムに移動します。

「認証」タブをクリックします。

プルダウンメニューから「デフォルト認証連鎖」を選択します。

プルダウンメニューから「管理者認証連鎖」を選択します。この属性は、管理者とエンドユーザーの認証モジュールを別々のものにする必要がある場合に使用できます。デフォルトの認証モジュールは LDAP です。

認証連鎖を定義したら、「保存」をクリックします。

組織に基づく認証

この認証タイプは、旧バージョンモードでインストールされた Access Manager の配備先にのみ適用されます。

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

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

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

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

正しい組織を呼び出したあと、ユーザーが認証を受ける認証モジュールは、コア認証サービスの「組織認証設定」属性から取得されます。組織に基づく認証を指定し、開始するログイン URL を次に示します。
http://server_name.domain_name:port/amserver/UI/Login http://server_name.domain_name:port/amserver/UI/Login?domain=domain_name http://server_name.domain_name:port/amserver/UI/Login?org=org_name
定義されたパラメータがない場合、組織はログイン URL に指定されたサーバーホストとドメインから判断されます。

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

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

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

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーの組織エントリの iplanet-am-auth-login-success-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。

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

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

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

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

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

組織の認証属性を設定する

手順

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

「認証」タブをクリックします。

プルダウンメニューから「デフォルト認証連鎖」を選択します。

プルダウンメニューから「管理者認証連鎖」を選択します。この属性は、管理者とエンドユーザーの認証モジュールを別々のものにする必要がある場合に使用できます。デフォルトの認証モジュールは LDAP です。

認証連鎖を定義したら、「保存」をクリックします。

ロールに基づく認証

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

注 –

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

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

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

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

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

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

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

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

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

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

http://server_name.domain_name:port/amserver/UI/Login?role=role_name
http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&role=role_name

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

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

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

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

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

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

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

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

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

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

手順

認証設定サービスを追加するレルム (または組織) に移動します。

「対象」タブをクリックします。

「フィルタロール」または「ロール」です。

認証設定を設定するロールを選択します。

認証設定サービスがロールに追加されていない場合は、「追加」をクリックし、「認証サービス」を選択して「次へ」をクリックします。

プルダウンメニューから、有効にする「デフォルト認証連鎖」を選択します。

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

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

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

サービスに基づく認証

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

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

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

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

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

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

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

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

http://server_name.domain_name:port/amserver/UI/
Login?service=auth-chain-name

および

http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&service=auth-chain-name
e

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

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

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

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

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

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーが認証を受けたサービスの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
ユーザーが認証を受けたサービスの iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。

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

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

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

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

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

手順

サービスに基づく認証を設定するレルムを選択します。

「認証」タブをクリックします。

認証モジュールインスタンスを作成します。

認証連鎖を作成します。

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

レルムのサービスに基づく認証にアクセスするには、次のアドレスを入力します。

http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&service=auth-chain-name

ユーザーに基づく認証

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

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

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

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

http://server_name.domain_name:port/amserver/UI/Login?user=user_name
http://server_name.domain_name:port/amserver/UI/Login?org=org_name&user=user_name

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

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

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

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

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

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

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。

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

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

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

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

手順

ユーザーの認証を設定するレルムに移動します。

「対象」タブをクリックし、「ユーザー」をクリックします。

変更するユーザーの名前をクリックします。

ユーザープロファイルが表示されます。

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

「ユーザー認証設定」属性で、適用する認証連鎖を選択します。

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

認証レベルに基づく認証

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

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

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

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

http://hostname:port/deploy_URI/UI/Login?authlevel=
auth_level_value

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

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

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

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

http://server_name.domain_name:port/amserver/UI/Login?authlevel=authentication_level

および

http://server_name.domain_name:port/amserver/UI/
Login?realm=realm_name&authlevel=authentication_level

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

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

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

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

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

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。

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

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

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

モジュールに基づく認証

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

http://hostname:port/deploy_URI/UI/Login?module=
module_name

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

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

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

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

http://server_name.domain_name:port/amserver/UI/Login?module=authentication_module_name
http://server_name.domain_name:port/amserver/UI/
Login?org=org_name&module=authentication_module_name

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

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

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

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

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

認証モジュールで設定された URL。
goto ログイン URL パラメータで設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性用に clientType カスタムファイルに設定された URL。
ユーザーのプロファイル (amUser.xml) の iplanet-am-user-success-url 属性に設定された URL。
ユーザーのロールエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
ユーザーのレルムエントリの iplanet-am-auth-login-success-url 属性に設定された URL。
グローバルデフォルトとして iplanet-am-auth-login-success-url 属性に設定された URL。

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

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

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

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

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

http://AccessManager-root/.domain_name:port /service_deploy_uri /UI/Login

注 –

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

特定の認証方法や、成功、失敗した認証のリダイレクト URL を定義するために、ユーザーインタフェースのログイン URL にログイン URL パラメータを付加することもできます。

ログイン URL パラメータ

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

http://server_name.domain_name:port/amserver/UI/
Login?module=LDAP&locale=ja&goto=http://www.sun.com

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

各パラメータは、1 つの URL に 1 回のみ指定できます。たとえば、module=LDAP&module=NT は受け入れられません。
org パラメータと domain パラメータは両方ともログインレルムを決定します。この場合、ログイン URL にはこの 2 つのパラメータどちらかを使用する必要があります。両方を使用する場合に優先順位を指定しないと、1 つのみが有効になります。
user、role、service、module、および authlevel は、それぞれの基準に基づいて認証モジュールを定義するためのパラメータです。このため、ログイン URL にはこれらのパラメータのいずれか 1 つのみを使用する必要があります。複数のパラメータを使用する場合に優先順位を指定しないと、1 つのみが有効になります。

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

注 –

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

goto パラメータ

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

http://server_name.domain_name:port/amserver/
UI/Login?goto=http://www.sun.com/homepage.html

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

http://server_name.domain_name:port/amserver/
UI/Logout?goto=http://www.sun.com/logout.html.

注 –

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

gotoOnFail パラメータ

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

注 –

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

realm パラメータ

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

注 –

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

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

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

http://server_name.domain_name:port/amserver/UI/Login?realm=sun

org パラメータ

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

注 –

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

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

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

http://server_name.domain_name:port/amserver/UI/Login?org=sun

user パラメータ

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

http://server_name.domain_name:port/amserver/UI/Login?user=jsmith

role パラメータ

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

http://server_name.domain_name:port/amserver/UI/Login?role=manager

locale パラメータ

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

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

locale=localeName パラメータの値は、定義されたその他のすべてのロケールよりも優先されます。
ユーザーのプロファイルに定義されたロケール

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

このロケールは、Web ブラウザによって設定されます。
コア認証サービスに定義されたロケール

これは、コア認証モジュールの「デフォルト認証ロケール」属性の値です。
プラットフォームサービスに定義されたロケール

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

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

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

http://server_name.domain_name:port/amserver/UI/Login?locale=ja

注 –

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

module パラメータ

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

http://server_name.domain_name:port/amserver/UI/Login?module=Unix

注 –

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

service パラメータ

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

http://server_name.domain_name:port/amserver/UI/Login?service=sv1

注 –

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

arg パラメータ

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

http://server_name.domain_name:port/amserver/UI/Login?arg=newsession

authlevel パラメータ

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

http://server_name.domain_name:port/amserver/UI/Login?authlevel=1

注 –

認証レベルは、各モジュールの特定のプロファイルに設定されます。

domain パラメータ

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

http://server_name.domain_name:port/amserver/UI/Login?domain=sun.com

注 –

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

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

iPSPCookie パラメータ

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

http://server_name.domain_name:port/amserver/UI/Login?org=example&iPSPCookie=yes

IDTokenN パラメータ

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

http://server_name.domain_name:port/amserver/UI/
Login?module=LDAP&IDToken1=userID&IDToken2=password

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

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

http://server_name.domain_name:port/amserver/UI/Login?module=Anonymous&IDToken1=anonymousUserID

注 –

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

アカウントのロック

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

注 –

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

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

「ログイン失敗時のロックアウトモード」は、アカウントロックを有効にします。
「ログイン失敗時のロックアウト回数」は、ユーザーがロックアウトされるまでに認証を試みることができる回数を定義します。この回数は、ユーザー ID ごとにのみ有効であり、同一ユーザー ID が指定された回数だけ認証に失敗するとロックアウトされます。
「ログイン失敗時のロックアウト間隔」は、分単位で定義された時間内にユーザーのログイン失敗の回数が「ログイン失敗時のロックアウト回数」で定義された値に達した場合に、そのユーザーをロックアウトすることを意味します。
「ロックアウト通知の送信先電子メールアドレス」は、ユーザーロックアウト通知が送信される電子メールアドレスを指定します。
「ユーザーに警告を出すまでの失敗回数」は、認証の失敗回数がここで定義した値に達したら、警告メッセージをユーザーに表示することを意味します。これにより、ロックアウトの発生が迫っていることを知らせる警告をユーザーが受けたあとに、さらに実行できるログインの試行回数を、管理者が設定できます。
「ログイン失敗時のロックアウト持続時間」は、ロックアウト後、次に認証を再試行できるようになるまで、ユーザーが待たなければならない時間を分単位で定義します。
「ロックアウト属性名」は、物理ロックのためにユーザーのプロファイルのどの LDAP 属性を「非アクティブ」に設定するかを定義します。
「ロックアウト属性値」は、「ロックアウト属性名」に指定された LDAP 属性を「非アクティブ」または「アクティブ」のどちらに設定するかを定義します。

アカウントのロックアウトに関する電子メールの通知が、管理者に送信されます。アカウントロックのアクティビティーはログにも記録されます。

注 –

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

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

物理ロック

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

注 –

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

メモリーロック

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

Access Manager が再起動されると、メモリー上でロックされたすべてのアカウントはロック解除されます。
ユーザーのアカウントがメモリー上でロックされ、管理者がロックアウト持続時間を 0 に設定してアカウントロックメカニズムを物理ロックに変更すると、ユーザーのアカウントはメモリーでロック解除され、ロックカウントがリセットされます。
メモリーのロックアウト後、LDAP およびメンバーシップ以外の認証モジュールを使用するときに、ユーザーが正しいパスワードでログインを試みると、「このレルムにユーザーのプロファイルがありません。」というエラーが返され、「ユーザーがアクティブではありません。」というエラーは返されません。

注 –

ユーザーのプロファイルに「失敗 URL」属性を設定すると、ロックアウト警告メッセージもアカウントがロックされたことを示すメッセージも表示されず、ユーザーは定義された URL にリダイレクトされます。

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

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

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

認証サービス URL を AutoContext API に送ります。次に例を示します。
AuthContext(orgName, url)
この API を使う場合は、URL で参照されたサーバーのみを使用します。この場合、そのサーバー上で認証サービスが使用可能であっても、フェイルオーバーは起きません。
認証コンテキストが AMConfig.properties ファイルの com.iplanet.am.server* 属性に定義されたサーバーをチェックします。
手順 2 で失敗すると、認証コンテキストはネーミングサービスが利用可能なサーバーからのプラットフォームリストを照会します。ディレクトリサーバーの 1 つのインスタンスを共有する複数のインスタンスが、(主にフェイルオーバーを目的として) Access Manager 上にインストールされたときに、このプラットフォームリストが自動的に作成されます。

たとえば、プラットフォームリストに 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 ファイルにあります。

例 7–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 address ]=IP address

注 –

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

持続 Cookie

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

持続 Cookie を有効にする

手順

コア認証モジュールで「持続 Cookie モード」をオンにします。

コア認証モジュールで「Cookie の最大持続時間」属性の時間値を設定します。

ユーザーインタフェースのログイン URL に yes の値で iPSPCookie パラメータを付加します。

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

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

AMLoginModule.setPersistentCookieOn()

レガシーモードにおけるマルチ LDAP 認証モジュール設定

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

追加の LDAP 構成を設定する

手順

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

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

<?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 Access Manager 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>
<realmRequests DN="dc=iplanet,dc=com">
    <AddSubConfiguration subConfigName = "ssc"
        subConfigId = "serverconfig"
        priority = "0" serviceName="iPlanetAMAuthLDAPService">

              <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>

</realmRequests>
</Requests>

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

この属性の値は、コード例に太字で示されています。

amadmin コマンド行ツールを使用して、XML ファイルをロードします。
./amadmin -u amadmin -w administrator_password -v -t name_of_XML_file.
この 2 番目の LDAP 設定は、コンソールを使用して表示も変更もできません。

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

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

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

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

各モジュールに設定されたページタイムアウト値 (デフォルトは 1 分)
AMConfig.properties の com.iplanet.am.invalidMaxSessionTime プロパティー (デフォルトは 10 分)
iplanet-am-max-session-time (デフォルトは 120 分)

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 パッケージを参照してください。

検証プラグインを作成して設定する

手順

新しいプラグインクラスは、com.iplanet.am.sdk.AMUserPasswordValidation クラスを拡張し、validateUserID() および validatePassword() メソッドを実装します。検証が失敗した場合は、AMException がスローされます。

プラグインクラスをコンパイルし、.class ファイルを必要な場所に配置します。実行時に Access Manager がプラグインにアクセスできるように、クラスパスを更新します。

最上位の管理者として Access Manager コンソールにログインします。「サービス管理」タブをクリックし、管理サービスの属性にアクセスします。「ユーザー ID とパスワードの検証プラグインクラス」フィールドにパッケージ名を含むプラグインクラスの名前を入力します。

ログアウトし、ログインし直します。

JAAS 共有状態

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

レルム (または、組織)
ユーザー
サービス
ロール

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

JAAS 共有状態の有効化

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

iplanet-am-auth-shared-state-enabled オプションを使用します。
共有状態オプションの使用法を次に示します。iplanet-am-auth-shared-state-enabled=true
このオプションのデフォルトは、true です。
この変数は、認証連鎖設定の「オプション」列で指定されます。

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

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

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

iplanet-amauth-store-shared-state-enabled オプションを使用します。
「共有状態」オプションの使用法を次に示します。iplanet-am-auth-store-shared-state-enabled=true
このオプションのデフォルトは、false です。
この変数は、認証連鎖設定の「オプション」列で指定されます。

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

第 7 章 認証の管理

認証の設定

認証モジュールタイプ

コア

Active Directory

匿名 (anonymous)

証明書

HTTP 基本

JDBC

LDAP

メンバーシップ

MSISDN

RADIUS

Sun Java System Application Server で RADIUS を設定する

SafeWord

Sun Java System Application Server で SafeWord を設定する

SAML

SecurID

UNIX

Windows デスクトップ SSO

Internet Explorer の既知の制限事項

Windows デスクトップ SSO の設定

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

手順

Internet Explorer をセットアップする

手順

Windows NT

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

認証モジュールインスタンス

新しい認証モジュールインスタンスを作成する

手順

認証連鎖

新しい認証連鎖を作成する

手順

認証タイプ

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

URL のリダイレクト

レルムに基づく認証

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

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

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

レルムに基づく認証に失敗した場合のリダイレクト URL

レルムに基づく認証を設定する

レルムの認証属性を設定する

手順

組織に基づく認証

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

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

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

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

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

組織の認証属性を設定する

手順

ロールに基づく認証

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

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

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

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

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

手順

サービスに基づく認証

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

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

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

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

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

手順

ユーザーに基づく認証

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

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

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

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

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

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

手順

認証レベルに基づく認証

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

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

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

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

第 7 章認証の管理

例 7–1 `AMConfig.properties` の FQDN マッピング属性