特定のレルムに関する追加情報
この節では、次の項目について説明します。
ldap レルムの作成
ldap レルムは、LDAP サーバーからの情報を使用して認証を行います。ユーザー情報には、ユーザー名、パスワード、およびユーザーが属するグループが含まれます。LDAP レルムを使用するには、ユーザーおよびグループを LDAP ディレクトリで事前に定義しておいてください。
LDAP レルムを作成するには、「レルムを作成する」の手順に従って新しいレルムを追加したあと、次の表に示したプロパティーを追加します。
表 9–2 ldap レルムに必要なプロパティー|
プロパティー名 |
説明 |
値 |
|---|---|---|
|
directory |
ディレクトリサーバーの LDAP URL。 |
ldap://hostname:port という形式の LDAP URL。例: ldap://myldap.foo.com:389。 |
|
base-dn |
ユーザーデータの場所のベース DN (Distinguished Name)。ツリー範囲検索が実行されるため、ユーザーデータのレベルより上に置かれます。検索ツリーが小さければ小さいほど、パフォーマンスが向上します。 |
検索用のドメイン。例: dc=siliconvalley, dc=BayArea, dc=sun, dc=com。 |
|
jaas-context |
このレルムに使用するログインモジュールのタイプ。 |
ldapRealm が必須です。 |
ldap レルムのオプションのプロパティーを、次の表に示します。
表 9–3 ldap レルムのオプションのプロパティー|
プロパティー名 |
説明 |
デフォルト |
|---|---|---|
|
search-filter |
ユーザー検索に使用される検索フィルタ。 |
uid=%s (%s はサブジェクト名に展開される)。 |
|
group-base-dn |
グループデータの場所のベース DN。 |
base-dn と同じですが、必要に応じて変更可能です。 |
|
group-search-filter |
ユーザーのグループメンバーシップ検索に使用する検索フィルタ。 |
uniquemember=%d (%d はユーザー要素 DN に展開される)。 |
|
group-target |
グループ名エントリを含む LDAP の属性名。 |
CN |
|
search-bind-dn |
search-filter 検索を実行するディレクトリの認証に使用するオプション DN。匿名検索を実行できないディレクトリにのみ必要になります。 | |
|
search-bind-password |
search-bind-dn で指定した DN の LDAP パスワード。 |
例
たとえば、次のように LDAP ユーザー、Joe Java が LDAP ディレクトリで定義されているとします。
uid=jjava,ou=People,dc=acme,dc=com uid=jjava givenName=joe objectClass=top objectClass=person objectClass=organizationalPerson objectClass=inetorgperson sn=java cn=Joe Java
ldap レルムの作成または編集をする際には、例示したコードを使用して、次の表で示す値を入力できます。
表 9–4 ldap レルムの値の例|
プロパティー名 |
プロパティー値 |
|---|---|
|
directory |
サーバーへの LDAP URL。例: ldap://ldap.acme.com:389 |
|
base-dn |
ou=People,dc=acme,dc=com. より上位に置くことも可能です (例: dc=acme、dc=com)。ただし、トラバースするツリーの範囲が広ければ、それだけパフォーマンスが低下します。 |
|
jaas-context |
ldapRealm |
solaris レルムの作成
solaris レルムは、システム設定で指定されているとおり、基礎となる Solaris ユーザーデータベースからユーザーおよびグループの情報を取得します。solaris レルムは、認証のための基礎となる PAM インフラストラクチャーを呼び出します。設定されている PAM モジュールに root 権限が必要な場合、ドメインはこのレルムを使用するため root として実行される必要があります。詳細については、セキュリティーサービスに関する Solaris ドキュメントを参照してください。
solaris には、1 つの必須プロパティー jaas-context があり、これは使用するログインモジュールのタイプを指定します。プロパティー値は solarisRealm である必要があります。
注 –
solaris レルムは Solaris 9 以降でのみサポートされています。
カスタムレルムの作成
4 つのビルトインレルムに加えて、ユーザーデータを、リレーショナルデータベースなどのほかの何らかの方法で格納するカスタムレルムも作成できます。カスタムレルムの作成は、このマニュアルの対象外です。詳細については、Application Server の『Developer's Guide』の「Securing Applications」の章を参照してください。
管理者として知っておく必要のある主な事柄は、カスタムレルムが、JAAS (Java Authentication and Authorization Service) パッケージから派生した LoginModule と呼ばれるクラスによって実装されていることです。
カスタムレルムを作成する
手順
-
「レルムを作成する」で概説した手順に従い、カスタムレルムの名前と LoginModule クラスの名前を入力します。
myCustomRealm などの一意で任意の名前が、カスタムレルムに使用できます。
-
次の表に示すカスタムレルムのプロパティーを追加します。
プロパティー名
プロパティー値
jaas-context
LoginModule クラス名。例: simpleCustomRealm
auth-type
レルムの説明。例: 「カスタムレルムの分かりやすい例」。
-
「了解」をクリックします。
-
ドメインのログイン設定ファイル domain-dir/config/login.conf を編集し、このファイルの最後に JAAS LoginModule の完全修飾クラス名を次のように追加します。
realmName { fully-qualified-LoginModule-classname required; };次に例を示します。
myCustomRealm { com.foo.bar.security.customrealm.simpleCustomLoginModule required; }; -
LoginModule クラスと依存するすべてのクラスを、ディレクトリ domain-dir/lib/classes にコピーします。
-
コンソールに「再起動が必要です」と表示される場合は、サーバーを再起動します。
-
レルムが正常にロードされたことを確認します。
domain-dir/logs/server.logを開き、サーバーがレルムを読み込んだことを確認します。サーバーは、レルムの init() メソッドを呼び出す必要があります。
certificate レルムの編集
certificate レルムは、SSL 認証をサポートしています。このレルムは、Application Server のセキュリティーコンテキスト内にユーザー ID を設定したあと、トラストストアファイルとキーストアファイル内の暗号的に検証されたクライアント証明書からユーザーデータを取得し、それをそのユーザー ID に格納します ( 「証明書ファイルについて」を参照)。これらのファイルにユーザーを追加するには、certutil を使用します。
J2EE コンテナは、certificate レルムを使用して、証明書からの各ユーザーの DN (Distinguished Name) に基づいた承認処理を行います。DN とは、その公開鍵を証明書が識別するエンティティーの名前です。この名前には、X.500 標準が使用され、インターネット全体で一意であるように意図されています。キーストアおよびトラストストアの詳細については、 certutil のドキュメント (「NSS (Network Security Services) ツールの使用」)を参照してください。
次の表は、certificate レルムのオプションのプロパティーの一覧です。
表 9–5 certificate レルムのオプションのプロパティー|
プロパティー |
説明 |
|---|---|
|
assign-groups |
グループ名のコンマで区切られたリスト。有効な証明書を提出するすべてのクライアントがこのグループに割り当てられます。たとえば、employee,manager など。この場合、これらはユーザーグループの名前です。 |
|
jaas-context |
このレルムに使用するログインモジュールのタイプ。certificate レルムでは、この値は必ず certificateRealm にする必要があります。 |
file および admin-realm レルムの編集
サーバーは、file レルムの keyfile および admin-realm レルムの admin-keyfile という名前のファイルに、すべてのユーザー、グループ、およびパスワードの情報を保持します。どちらの場合も、file プロパティーを使って keyfile の場所を指定します。次の表に、file レルムに必要なプロパティーを示します。
表 9–6 file レルムに必要なプロパティー|
プロパティー名 |
説明 |
デフォルト値 |
|---|---|---|
|
file |
keyfile のフルパスおよび名前。 |
domain-dir/config/keyfile |
|
jaas-context |
このレルムに使用するログインモジュールのタイプ。 |
fileRealm だけが有効な値です。 |
keyfile は最初は空のため、file レルムを使用する前にユーザーを追加する必要があります。手順については、「file レルムユーザーの管理」を参照してください。
admin-keyfile には最初、管理ユーザー名、暗号形式の管理パスワード、およびデフォルトで asadmin であるこのユーザーが属するグループが収められています。admin-realm にユーザーを追加する方法の詳細については、「管理ツールへのアクセスを許可する」を参照してください。
注 –
admin-realm のグループ asadmin のユーザーには、管理コンソールおよび asadmin ツールを使用する権限があります。このグループには、サーバーの管理権限のあるユーザーだけを追加してください。
NSS (Network Security Services) によるユーザーの管理
Enterprise Edition の場合にのみ、「file レルムユーザーの管理」で説明したように管理コンソールを使ってユーザーを管理することもできますし、NSS ツールを使ってユーザーを管理することもできます。NSS (Network Security Services) とは、セキュリティーが有効なクライアントおよびサーバーアプリケーションのクロスプラットフォーム開発をサポートするよう設計された一連のライブラリです。NSS で構築されたアプリケーションは、SSL v2 および v3、TLS、PKCS #5、PKCS #7、PKCS #11、PKCS #12、S/MIME、X.509 v3 証明書およびその他のセキュリティー標準をサポートできます。詳細については、次の URL を参照してください。
-
NSS (Network Security Services) については、http://www.mozilla.org/projects/security/pki/nss/
-
NSS セキュリティーツールについては、http://www.mozilla.org/projects/security/pki/nss/tools/
-
NSS の概要については、http://www.mozilla.org/projects/security/pki/nss/overview.html
file レルムユーザーの管理
file レルムユーザーは管理コンソールで管理します。file レルムのユーザーおよびグループは keyfile で表示され、その場所は file プロパティーで指定されます。
注 –
この手順を使用して、admin-realm を含む任意の file レルムにユーザーを追加することもできます。この節で言及されている file レルムの代わりに、ターゲットレルムの名前を代入するだけです。
file レルムの各ユーザーは、特定の「J2EE グループ」に所属できます。J2EE グループは、共通の特性に基づいて分類されるユーザーのカテゴリです。たとえば、E コマースアプリケーションの顧客は CUSTOMER グループに属しますが、お得意様は PREFERRED グループに属します。ユーザーをグループに分類すると、ユーザーからの大量のアクセスを制御することが容易になります。
Application Server のインストール後の当初は、ユーザーはインストールの際に入力した管理者だけです。デフォルトで、このユーザーは Application Server を変更する権限を付与する admin-realm レルムの asadmin グループに属します。このグループに割り当てられるすべてのユーザーは、管理者権限が付与されます。つまり、asadmin ツールおよび管理コンソールへのアクセス権があります。
file レルムのユーザーを管理するには、次の各タスクを実行します。
「ファイルユーザー」ページにアクセスする
手順
-
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
-
設定するインスタンスを選択します。
-
「セキュリティー」ノードを展開します。
-
「レルム」ノードを展開します。
-
file ノードを選択します。
-
「レルムを編集」ページで、「ユーザーを管理」ボタンをクリックします。
「ファイルユーザー」ページが表示されます。このページで、次のタスクを実行します。
ユーザーを追加する
手順
-
「新規」をクリックして、新しいユーザーを file レルムに追加します。
-
「ファイルユーザー」ページで次の情報を入力します。
-
ユーザー ID (必須) - ユーザーの名前。
-
パスワード (必須) - ユーザーのパスワード。
-
パスワードの再入力 (必須) - ユーザーのパスワードの確認用再入力。
-
グループリスト (オプション) - ユーザーが属するグループのコンマで区切られたリスト。これらのグループをほかの場所で定義する必要はありません。
-
-
「了解」をクリックして、このユーザーを file レルムのユーザーのリストに追加します。「取消し」をクリックすると保存せずに終了します。
同機能を持つ asadmin コマンド
create-file-user
ユーザー情報を編集する
手順
-
「ユーザー ID」列で、変更するユーザーの名前をクリックします。
「ファイルレルムユーザーの編集」ページが表示されます。
-
「パスワード」および「パスワードの確認」フィールドに新しいパスワードを入力して、ユーザーのパスワードを変更します。
-
「グループ リスト」フィールドのグループを追加または削除して、ユーザーが属するグループを変更します。
グループ名をコンマで区切ってください。グループを事前に定義する必要はありません。
-
「保存」をクリックして、このユーザーを file レルムのユーザーのリストに保存します。
「閉じる」をクリックすると保存せずに終了します。
ユーザーを削除する
手順
同機能を持つ asadmin コマンド
delete-file-user
相互認証の設定
相互認証では、サーバーとクライアント側の両方で認証が有効です。相互認証をテストするには、有効な証明書を持つクライアントが存在している必要があります。相互認証の詳細については、『J2EE 1.4 Tutorial』(http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html) の「Security」の章を参照してください。
アプリケーションの相互 SSL 認証の有効化
特定のアプリケーションで相互認証を有効にするには、deploytool を使用して認証のメソッドを Client-Certificate に設定してください。deploytool の使用方法の詳細については、『J2EE 1.4 Tutorial』(http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html) の「Security」の章を参照してください。
すべてのアプリケーションの相互認証を有効にする
Application Server は、HTTPS 認証に certificate レルムを使用します。
手順
- © 2010, Oracle Corporation and/or its affiliates