認証モジュールタイプ (Sun Java System Access Manager 7.1 管理ガイド)

Sun Java System Access Manager 7.1 管理ガイド

認証モジュールタイプ

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

注 –

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

コアシステムサポート

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)

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

証明書

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

証明書に基づく認証モジュールをレルムに追加する前に、いくつかの作業を行う必要があります。まず、Access Manager とともにインストールした Web コンテナを保護し、証明書に基づく認証で使用できるように設定する必要があります。

注 –

SSL 対応の Sun Java System WebsServer 6.1 インスタンスとともに Access Manager Certificate の認証を設定し、証明書ベースの認証要求と証明書ベースでない認証要求の両方を受け入れるように WebServer を定義する場合は、WebServer の obj.conf ファイルに次の値を設定する必要があります。

PathCheck fn="get-client-cert" dorequest="1" require="0"

これは、この動作に対してオプションの属性を設定するときには、WebServer コンソールに制限があるためです。

証明書に基づくモジュールを有効にする前に、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 を設定し、クライアント認証を有効化しておく必要があります。詳細については、『Access Manager Post Installation Guide』の「Configuring Access Manager in SSL Mode」を参照してください。

データストア

データストアの認証モジュールを使用すると、レルムのアイデンティティーリポジトリを使用したログインでユーザーを認証できます。同じデータストアリポジトリに対して認証を行う必要がある場合は、データストアのモジュールを使用すると、認証プラグインモジュールを書き、ロードし、認証モジュールを設定する必要がなくなります。さらに、そのレルムの該当リポジトリに対してフラットファイルの認証が必要な場合でも、カスタム認証モジュールを書く必要がありません。

この認証タイプには、Access Manager 認証を設定するときに、ある程度の利便性があります。Access Manager 7.1 より前のリリースでは、LDAPv3 データストアのユーザーが自分のレルムへの認証をできるようにする場合に、次を実行する必要があります。

LDAPv3 データストアの設定
同じレルム対象を参照する LDAP 認証モジュールインスタンスの設定

データストアの認証モジュールを使用すると、レルムのアイデンティティーリポジトリに定義されたユーザーが認証を行うことができます。LDAP 認証の設定は必要ありません。たとえば、レルムのアイデンティティーリポジトリには LDAPv3 データストアが含まれ、同じレルムでデータストア認証が使用されると仮定します。この場合、アイデンティティーリポジトリに定義されたユーザーはすべて、そのレルムへの認証を行うことができます。

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 を設定する

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

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 PremierAccess™ 認証サーバーに対して送られる 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 2005Q2 から Access Manager 7.1 などへのアップグレード後も含めて、ターゲットマシンで設定されている場合にかぎって、SAML SSO は動作します。

SecurID

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

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

注 –

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

UNIX

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

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

Microsoft Windows デスクトップ SSO 認証モジュールは、Microsoft 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 に認証できます。クライアントサイドでトークンを使用できるかどうかにより、SPNEGO トークンか Kerberos トークンがこのモジュールによって提供されます。どちらの場合でもプロトコルは同一です。Microsoft Windows 2000 以上で動作している Microsoft Internet Explorer 5.01 以上では、現在このプロトコルがサポートされています。Solaris 9 および 10 上で動作する Mozilla 1.4 では SPNEGO もサポートしていますが、返されるトークンは KERBEROS トークンのみです。これは、Solaris 自体が SPNEGO をサポートしてないためです。

注 –

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

注 –

このリリースの Access Manager から、この制限は Microsoft によって解決されています。詳細については、次のマニュアルを参照してください。

http:// http://www.microsoft.com/technet/security/bulletin/ms06-042.mspx

Windows デスクトップ SSO の設定

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

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

Microsoft 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

注 –

Windows 2003 または Windows 2003 サービスパックを使用している場合は、次の ktpass コマンド構文を使用します。

ktpass /out filename /mapuser username /princ HTTP/hostname.domainname 
     /crypto encryptiontype /rndpass /ptype principaltype /target domainname

次に例を示します。

ktpass /out demo.HTTP.keytab /mapuser http 
/princ HTTP/demo.identity.sun.com@IDENTITY.SUN.COM /crypto RC4-HMAC-NT 
/rndpass /ptype KRB5_NT_PRINCIPAL /target IDENTITY.SUN.COM

構文の定義については、http://technet2.microsoft.com/WindowsServer/en/library/64042138-9a5a-4981-84e9-d576a8db0d051033.mspx?mfr=trueの Web サイトを参照してください。

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

Internet Explorer をセットアップする

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

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

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

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

Windows NT

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

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

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

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

AccessManager-base/SUNWam/bin

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

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

/usr/bin

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

AccessManager-base/sun/identity/bin

注 –

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