| Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド 11g リリース1(11.1.1) B56235-06 |
|
 前 |
 次 |
この章では、匿名ロール、認証ロール、ロール・マッピング、ロール・カテゴリなどのユーザーとロールの様々な特性について説明します。また、このガイド全体で使用する用語の定義と、ユーザーおよびロールAPIフレームワークの概要についても説明します。
OPSSでは、WebLogic管理コンソールで管理するOracle WebLogic Server認証プロバイダに認証を委任します。
この章の内容は次のとおりです。
プログラムによるユーザーとロールの管理の詳細は、第25章「ユーザー/ロールAPIを使用した開発」を参照してください。
この項では、OPSSのセキュリティ用語を定義します。
ユーザー
ユーザーまたはエンタープライズ・ユーザーとは、サービスにアクセスするエンド・ユーザーです。ユーザー情報は、アイデンティティ・ストアに格納されます。認証されたユーザーとは、資格証明が検証されているユーザーです。
匿名ユーザーとは、資格証明が検証されていない(したがって認証されていない)ユーザーのことであり、保護されていないリソースにのみアクセスを許可されます。匿名ユーザーはOPSS固有のユーザーで、アプリケーション側でその使用を有効化または無効化できます。匿名ユーザーのサポートの詳細は、第2.4項「匿名ユーザーとロール」を参照してください。
ロール
エンタープライズ・ロールまたはエンタープライズ・グループとは、ユーザーとその他のグループの集合です。それは階層にすることが可能です。つまり、グループには任意にネストされたグループ(そのグループ自体を除く)を追加できます。
Java EE論理ロールとは、Java EEアプリケーションで宣言的またはプログラム的に指定するロールです。アプリケーション・デプロイメント・ディスクリプタで定義され、通常、アプリケーション・コード内で使用されます。エンタープライズ・グループまたはユーザーにのみマップでき、アプリケーション・ロールには直接マップできません。
アプリケーション・ロールは、ユーザー、グループおよびその他のアプリケーション・ロールの集まりであり、階層構造にできます。アプリケーション・ロールはアプリケーション・ポリシーによって定義されます。Java EEコンテナに認識されるとは限りません。アプリケーション・ロールは、外部ロールに多対多でマッピングできます。たとえば、(アイデンティティ・ストアに格納されている)外部グループemployeeを、(あるストライプ内の)アプリケーション・ロールhelpdesk service requestにマッピングして、さらに(別のストライプ内の)アプリケーション・ロールself service HRにマッピングできます。
匿名ロールの詳細は、第2.4項「匿名ユーザーとロール」を参照してください。認証ロールの詳細は、第2.3項「認証ロール」を参照してください。
プリンシパル
プリンシパルとは、ポリシー内の認可が付与されるアイデンティティです。プリンシパルには、ユーザー、外部ロールまたはアプリケーション・ロールを指定できます。ほとんどの場合、アプリケーション・ロールを指定します。
アプリケーション・ポリシー
アプリケーション・ポリシーは、アプリケーション内でエンティティ(権限受領者、プリンシパルまたはコード・ソース)に付与される権限セット(Webページの閲覧やレポートの変更など)を指定する機能ポリシーです。つまり、アプリケーション・ポリシーはアプリケーションで誰が何を実行できるかを指定するものです。
アプリケーション・ポリシーの特徴を次に示します。
プリンシパルを権限受領者として使用します。少なくとも1つのプリンシパルを割り当てる必要があります。
1つ以上の権限または資格を使用できますが、その両方は使用できません。
資格を使用するポリシーは資格に基づくポリシーと呼ばれ、1つ以上の権限を使用するポリシーはリソースに基づくポリシーと呼ばれます。
図2-1は、アプリケーション・ポリシー・モデルを示しています。
OPSSサブジェクト
OPSSサブジェクトとは、プリンシパルの集合です。多くの場合は、パスワードや暗号キーなどのユーザー資格証明です。サーバー認証では、サブジェクトにユーザーおよびグループを移入した後、サブジェクトにアプリケーション・ロールを追加します。OPSSサブジェクトは、OAMなどの他のOracle Identity Management製品を使用したID伝播で重要になります。匿名データの処理方法の詳細は、第2.4.1項「匿名サポートとサブジェクト」を参照してください。
セキュリティ・ストア
アイデンティティ・ストアとは、エンタープライズ・ユーザーとグループのリポジトリで、LDAPベースにする必要があります。追加設定なしで使用できるアイデンティティ・ストアは、WebLogic LDAP DefaultAuthenticatorです。その他のタイプのアイデンティティ・ストアには、Oracle Internet Directory、Sun Directory Server、Oracle Virtual Directoryなどがあります。
ポリシー・ストアとは、アプリケーション・ポリシーおよびシステム・ポリシーのリポジトリです。このストアは、Oracle Enterprise Manager Fusion Middleware Controlで管理します。
資格証明ストアとは、資格証明のリポジトリです。このストアは、Oracle Enterprise Manager Fusion Middleware Controlで管理します。
OPSSセキュリティ・ストアとは、 システムやアプリケーションに固有のポリシー、資格証明、およびキーの論理リポジトリです。LDAPベースのOPSSセキュリティ・ストアでサポートされているタイプは、Oracle Internet Directoryのみです。
詳細は、第3章「アイデンティティ、ポリシー、資格証明、キーおよび証明書について」を参照してください。
その他の用語
システム・コンポーネントとは、WebLogicコンポーネント以外の管理可能なプロセスです。たとえば、Oracle Internet Directory、WebCache、Java SEコンポーネントなどがあります。
Javaコンポーネントとは、システム・コンポーネントの一種ですが、その管理はアプリケーション・サーバー・コンテナで行います。通常は、ドメイン拡張テンプレートと1対1の関係にある、アプリケーションおよびリソースの集合を表します。たとえば、Oracle SOAアプリケーションやOracle WebCenter Spaceなどがあります。
OPSSでは、ポリシー・ストアにあるアプリケーション・ロールを、アイデンティティ・ストアにあるエンタープライズ・グループに多対多の関係でマッピングできます。このマッピングにより、アプリケーション・ロールでの指定に従って、エンタープライズ・グループのユーザーがアプリケーション・リソースにアクセスできます。このマッピングは多対多なので、ロール対グループ・マッピングまたはグループ対ロール・マッピングとも呼ばれています。
|
注意: Oracle JDeveloperでは、その環境でアプリケーションを開発している段階でこのマッピングを指定できます。また、第9.2.2項「アプリケーション・ロールの管理」の説明に従って、アプリケーションのデプロイ後にOPSSスクリプト、Fusion Middleware ControlまたはOracle Entitlements Serverを使用してマッピングを指定することもできます。 エンタープライズ・グループにアプリケーション・ロールをマッピングすると、そのエンタープライズ・グループの権限は、その権限とそれにマッピングされたアプリケーション・ロールの権限を結合したものに書き換えられます。したがって、エンタープライズ・グループの権限が増加することはあっても減少することはありません。 |
OPSSロールは、「所属メンバー」という関係を使用して階層構造とすることができます。つまり、ロールは、ユーザーまたは他のロールをメンバーとして持つことができます。
|
重要: ロール階層を構築するときは、望ましくない動作を防止するために、循環依存を使用しないでください。たとえば、ロールAをロールBのメンバーに設定し、ロールBをロールAのメンバーに設定すると、このような循環依存が生成されます。 |
ロール階層では、ロールのメンバーは親ロールからパーミッションを継承します。つまり、ロールAがロールBのメンバーである場合、ロールBに付与されているすべてのパーミッションがロールAにも付与されます。当然のことながら、ロールAは、それ自体の特定のパーミッションを持っていますが、ロールBのメンバーとなることにより、ロールBに付与されているすべてのパーミッションを継承します。
OPSSスクリプトによるアプリケーション・ロール階層の管理方法の詳細は、第9.3.4項「grantAppRole」および第9.3.5項「revokeAppRole」を参照してください。
Oracle Entitlements Serverによるアプリケーション・ロール階層の管理方法の詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドを参照してください。
次の例は、ネストしたアプリケーション・ユーザーとロールで構成したロール階層を示しています。
ロールdeveloperAppRoleは次のメンバーを持っています。
developer developer_group managerAppRole directorAppRole
また、ロールdirectorAppRoleは次のメンバーを持っています。
developer developer_group
ファイルjazn-data.xmlの中で、前述の階層を記述した部分を次に示します。
<policy-store>
<applications>
<application>
<name>MyApp</name>
<app-roles>
<app-role>
<name>developerAppRole</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<display-name>Application developer role</display-name>
<description>Application developer role</description>
<guid>61FD29C0D47E11DABF9BA765378CF9F5</guid>
<members>
<member>
<class>weblogic.security.principal.WLSUserImpl</class>
<name>developer</name>
</member>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>developer_group</name>
</membe>
<member>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>managerAppRole</name>
</member>
</members>
</app-role>
<app-role>
<name>directorAppRole</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<display-name>Application director role </display-name>
<description>Application director role</description>
<guid>61FD29C0D47E11DABF9BA765378CF9F8</guid>
<members>
<member>
<class>weblogic.security.principal.WLSUserImpl</class>
<name>developer</name>
</member>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>developer_group</name>
</member>
</members>
</app-role> ...
</app-roles>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>developerAppRole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>java.io.FilePermission</class>
<name>/tmp/oracle.txt</name>
<actions>write</actions>
</permission>
</permissions>
</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>managerAppRole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>java.util.PropertyPermission</class>
<name>myProperty</name>
<actions>read</actions>
</permission>
</permissions>
</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>directorAppRole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>foo.CustomPermission</class>
<name>myProperty</name>
<actions>*</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
</policy-store>
表2-1は、前述の階層の5つのユーザーとロールのそれぞれが継承ルールに従って取得するパーミッションをまとめたものです。
OPSSでは、特別なロールである認証ロールの使用がサポートされています。このロールには次の特性があります。
構成ファイルで宣言する必要がありません。
認証が成功した後、必ず、サブジェクトに関連付けられているプリンシパルとして表されます。つまり、認証されたすべてのユーザーにデフォルトで付与されます。
サブジェクト内における認証ロールの存在は、匿名ロールと相互に排他的です。つまり、(a)サブジェクトが認証を受けていない場合は、「匿名サポートとサブジェクト」の説明のように、サブジェクトにはプリンシパルと匿名ロールが含まれます。(b)サブジェクトが正常に認証された場合は、認証ロールが含まれるほか、構成によっては匿名ロールも含まれます。
アプリケーション・ロールです。したがって、あらゆるアプリケーションで使用でき、アプリケーションのロール階層に追加できます。
認証ロールに付与するパーミッションは、明示的に指定する必要はなく、所属先のエンタープライズ・グループおよびアプリケーション・ロールから暗黙的に派生します。
認証ロールの一般的な用途は、共通のアプリケーション・リソース、つまり認証されたユーザーが利用できるリソースへのアクセスを、認証されたユーザーに許可することです。
認証されたロールの使用をアプリケーション側で手動で構成する方法の詳細は、第21.1項「サーブレット・フィルタとEJBインターセプタの構成」を参照してください。
OPSSでは、匿名ユーザーと匿名ロールという、2つの特殊なエンティティを使用できます。認証ロールと同様に、これらのエンティティを宣言する必要はなく、アプリケーションによってJpsFilterまたはJpsInterceptorでその使用が構成されます。これらのどのエンティティも、アプリケーションのロール階層内でアプリケーションによって使用できます。
この匿名のエンティティを有効にしておくと、認証されていないユーザーが非保護リソースにアクセスするとき、そのユーザーは匿名ユーザーと匿名ロールのみが移入されたサブジェクトで表されます。そのサブジェクトが保護されたリソースにアクセスを試みた場合、認可過程でサブジェクトは「匿名サポートとサブジェクト」の説明のように処理されます。
匿名ユーザーおよびロールに付与するパーミッションは、明示的に指定する必要はなく、所属先のエンタープライズ・グループおよびアプリケーション・ロールから暗黙的に派生します。
匿名ユーザーおよびロールの一般的な用途は、認証されていないユーザーにパブリックな非保護リソースへのアクセスを許可することです。
匿名ユーザーおよび匿名ロールの使用をアプリケーション側で手動で構成する方法の詳細は、第21.1項「サーブレット・フィルタとEJBインターセプタの構成」を参照してください。
この項では、全体を通じて匿名ユーザーおよび匿名ロールの使用が有効になっていることを前提とします。
エンドユーザーが初めて非保護リソースにアクセスした場合、サブジェクトが作成され、そのサブジェクトに匿名ユーザーと匿名ロールに対応した2つのプリンシパルが移入されます。非保護リソースに関するかぎり、そのサブジェクトは変更されず認証は行われません。
保護されたリソースにそのサブジェクトがアクセスすると認証が始まり、この時点までは匿名ロールのみを持っていたサブジェクトが、認証プロセスの結果に応じて次のように変更されます。
認証に成功した場合は次のようになります。
認証に成功すると、サブジェクトには、非匿名ユーザーに対応した1つのプリンシパル、認証ロールに対応した1つのプリンシパル、および場合によってはエンタープライズ・ロールまたはアプリケーション・ロールに対応した他のプリンシパルが含まれるようになります。
認証が成功しなかった場合は、匿名ユーザーが保持されます。匿名ロールは、アプリケーションによるJpsFilterまたはJpsInterceptorの構成に応じて削除または保持されます。他のプリンシパルは追加されません。デフォルトでは、匿名ロールはサブジェクトから削除されます。
(WebLogic)管理者は、グループAdministratorsのユーザー・メンバーであり、このグループにはセキュリティ・レルムに存在している任意のユーザーを追加できます。
セキュリティ・レルムに存在するデフォルト・グループの詳細は、Oracle Fusion Middlewareのロールとポリシーを使用したリソースの保護のユーザー、グループ、およびセキュリティ・ロールに関する項を参照してください。
通常、管理者にはデフォルト名はありません。唯一の例外は実行例をインストールした場合で、その際はサンプル・ドメインの管理者のデフォルト・ユーザー名とパスワードが提供されます。ただし、これらの例は本番環境では使用しないでください。
詳細は、『Oracle Fusion Middleware Oracle WebLogic Server本番環境の保護』のセキュアな方法によるWebLogic Serverのインストールに関する項を参照してください。
ドメインを構成すると、Administratorsグループのメンバーは、セキュリティ・レルムに作成されたユーザーを、いつでもAdministratorsグループに追加したりグループから削除することができます。これらのアカウントを管理するための2つの基本ツールが、Oracle WebLogic管理コンソールとOracle WebLogic Scripting Tool (WLST)です。
詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプのグループへのユーザーの追加に関する項および『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』のWebLogic Scripting Toolの使用に関する項を参照してください。
この項では、ユーザー・アカウントの作成とこれらのパスワードの保護に関する情報へのリンクをいくつか紹介します。
パスワードの作成の一般的なガイドラインは、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプのユーザーおよびグループの管理に関する項を参照してください。デフォルトの認証プロバイダでは、8文字以上の長さのパスワードが必要ですが、これは構成可能です。
パスワードの作成に関するいくつかの推奨事項は、『Oracle Fusion Middleware Oracle WebLogic Server本番環境の保護』のWebLogic Serverホストの保護に関する項を参照してください。
一般的に、パスワードは、LDAPサーバーまたはRDBMSに格納されます。これらのパスワードが格納される特定の場所は、環境(正確にはドメインのセキュリティ・レルム)内で構成された固有の認証プロバイダによって決定されます。追加設定なしで使用できる認証プロバイダの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の組込みLDAPサーバーの管理に関する項を参照してください。
カスタマイズ可能なパスワード作成ルールを適用するパスワード検証プロバイダを、パスワードを作成したときに自動的にコールできるオプションがあります。このオプションの構成方法は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のパスワード検証プロバイダの構成に関する項を参照してください。
ユーザーの追加または削除の際は、第L.11項「ユーザーによる予期しないパーミッションの取得」の説明にある推奨事項を考慮してください。
この項では、プリンシパルの比較がOPSS認可に及ぼす影響とプリンシパル名の比較ロジックを制御するシステム・パラメータについて説明します。この項の内容は次のとおりです。
ユーザーが適切に認証されると、そのユーザーについてアイデンティティ・ストアに格納されているユーザー名およびエンタープライズ・グループ名(ユーザーが所属するエンタープライズ・グループ名)と一致するプリンシパルを持つサブジェクトが移入されます。
これに対し、ユーザー(またはエンタープライズ・グループ)を認可する必要がある場合は、アプリケーション・ロールがエンタープライズ・グループにどのようにマップされているかがシステムで考慮され、ポリシー・ストアに格納されているアプリケーション権限の名前から別のプリンシパルが構築されます。
プリンシパルを認可するために、サブジェクトに(アイデンティティ・ストアで検出された名前から)移入されたプリンシパル名とポリシー・ストアの名前から構築されたプリンシパル名が比較されます。これらのプリンシパル名が一致した場合にのみ、そのユーザー(またはグループ)が認可されます。
したがって、想定どおりにプリンシパル名が機能するには、認可プロバイダでプリンシパル名を適切に比較することが重要です。
たとえば、アイデンティティ・ストアに格納されているユーザー名が「jdoe」であるのに対し、権限付与のユーザー名は「Jdoe」であるとします。この場合は、大文字と小文字を区別せずにプリンシパル名を比較するように指定する必要があります。そうしないと、「jdoe」と「Jdoe」という名前から構築されたプリンシパルは一致せず(この2つの名前が異なると認識され)、「jdoe」が想定どおりには認可されなくなります。
次の2つのWebLogic Serverシステム・パラメータを使用すると、プリンシパル名をドメイン内で比較する方法を制御でき、さらにDNデータとGUIDデータを使用してプリンシパルを比較できます。
PrincipalEqualsCaseInsensitive (True or False; False by default) PrincipalEqualsCompareDnAndGuid (True or False; False by default)
WebLogic Serverコンソールを使用してこれらのパラメータを設定する手順は、次のとおりです。
「コンソール」の左側ペインにある「ドメイン構造」で、前述のパラメータを設定するドメインを選択します。
「構成」→「セキュリティ」を選択し、「詳細」をクリックします。
次のエントリの隣にあるボックスを選択(trueに設定)または選択解除(falseに設定)します。
Principal Equalsの大文字/小文字を区別しない
Principal EqualsでDNとGUIDを比較
サーバーを再起動します。サーバーが再起動するまで、変更は有効になりません。
OPSSスクリプトを使用してこれらのパラメータを設定することもできます。WebLogic Serverの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のJAAS認可を使用するためのドメインの構成に関する項を参照してください。
実行時に選択した名前の比較ロジックは、次の擬似コードで記述できます。
if PrincipalEqualsCompareDnAndGuid is true
//use GUID and DN to compare principals
{
when GUID is present in both principals {
use case insensitive to compare GUIDs
}
when DN is present in both principals {
use case insensitive to compare DNs
}
}
if PrincipalEqualsCaseInsensitive is true
//use just name to compare principals
{
use case insensitive to compare principal names
}
else
{
use case sensitive to compare principal names
}
デフォルトではPrincipalEqualsCompareDnAndGuidとPrincipalEqualsCaseInsensitiveがfalseに設定されているので、プリンシパル名の比較では大文字と小文字が区別されます。
ロール・カテゴリを使用すると、セキュリティ管理者はアプリケーション・ロールを編成できます。管理者は、アプリケーション内のロールのフラット・リストを表示するかわりに、それらのロールを任意のフラット・セットやカテゴリに編成できます。
Oracle Entitlements Serverによるアプリケーション・ロール・カテゴリの管理方法の詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドを参照してください。
次のコードは、ロール・カテゴリの構成を示しています。
<role-categories>
<role-category>
<name>RC_READONLY</name>
<display-name>RC_READONLY display name</display-name>
<description>RC_READONLY description</description>
<members>
<role-name-ref>AppRole1</role-name-ref>
<role-name-ref>AppRole2</role-name-ref>
<role-name-ref>AppRole3</role-name-ref>
</members>
</role-category>
</role-categories>
ロール・カテゴリでは、大文字と小文字は区別されません。ロール・カテゴリは、インタフェースRoleCategoryManagerを使用して管理できます。
このインタフェースの詳細は、Javadocドキュメントの『Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services』を参照してください。
