| Oracle Fusion Middlewareセキュリティ・ガイド 11gリリース1（11.1.1） B56235-01 |
|
 戻る |
 次へ |
この章では、Oracle Platform Security Services（OPSS）のユーザーとロール、匿名ロール、認証ロールおよびロール・マッピングについて説明します。また、このガイド全体で使用する用語の定義と、ユーザーおよびロールAPIフレームワークの概要についても説明します。
OPSSでは、WebLogic管理コンソールで管理するOracle WebLogic Server認証プロバイダに認証を委任します。
この章の内容は次のとおりです。
ユーザーとロールのプログラムによる管理の詳細は、第19章「ユーザーおよびロールAPIを使用した開発」を参照してください。
この項では、一般的な用語とOPSS固有の用語の定義について説明します。これらの用語のいくつかは前の章で説明しており、他のいくつかの用語については後の章で説明します。
ユーザー
ユーザーまたはエンタープライズ・ユーザーとは、サービスにアクセスするエンド・ユーザーです。ユーザー情報は、一般にWebLogic Server DefaultAuthenticatorでインスタンス化するドメイン・アイデンティティ・ストアに格納されます。認証されたユーザーとは、資格証明が検証されているユーザーです。
匿名ユーザーとは、資格証明が検証されていない（したがって認証されていない）ユーザーのことであり、保護されていないリソースにのみアクセスを許可されます。匿名ユーザーはOPSS固有のユーザーで、アプリケーション側でその使用を有効化または無効化できます。匿名ユーザーのサポートの詳細は、第3.4項「匿名ユーザーとロール」を参照してください。
ロール
エンタープライズ・グループまたはグループとは、ユーザーまたは他のグループで構成するロールです。アプリケーション・デプロイメント・ディスクリプタ（web.xmlやejb-jar.xmlなど）で定義できるほか、コード内で注釈を使用して定義することもできます。
JavaEE論理ロールとは、JavaEEアプリケーションで宣言的またはプログラム的に指定するロールです。アプリケーション・デプロイメント・ディスクリプタで定義され、通常、アプリケーション・コード内で使用されます。
OPSSアプリケーション・ロールとは、ユーザー、グループおよびアプリケーション・ロールの集合で、階層構造にできます。これはアプリケーション固有であり、アプリケーション・ポリシーによって定義され、JavaEEコンテナが認識するとはかぎりません。アプリケーション・ロールは、アプリケーションの実行中にのみ参照可能であるため、有効範囲が限定されています。このロールは、同じアプリケーション・スコープで定義されている他のアプリケーション・ロール（およびエンタープライズ・ユーザーまたはグループ）にマップでき、認可の判断に使用します。
匿名ロールの詳細は、第3.4項「匿名ユーザーとロール」を参照してください。認証ロールの詳細は、第3.3項「認証ロール」を参照してください。
プリンシパル
プリンシパルとは、認証プロセスによって要求元エンティティ（ユーザーなど）に割り当てられる識別情報です。
OPSSサブジェクト
OPSSサブジェクトとは、プリンシパルの集合です。多くの場合は、パスワードや暗号キーなどのユーザー資格証明です。WebLogic認証では、サブジェクトにユーザーおよびグループを移入した後、サブジェクトにアプリケーション・ロールを追加します。匿名データの処理方法の詳細は、第3.4.1項「匿名サポートとサブジェクト」を参照してください。
セキュリティ・ストア
アイデンティティ・ストアとは、エンタープライズ・ユーザーおよびグループのリポジトリです。特別な設定をしていない場合、アイデンティティ・ストアはWebLogic DefaultAuthenticatorです。他のアイデンティティ・ストアとして、LDAP、RDBMS、カスタムなどがあります。このストアは、WebLogic管理コンソールで管理します。
ポリシー・ストアとは、アプリケーション・ポリシーおよびシステム・ポリシーのリポジトリです。このストアは、Oracle Enterprise Manager Fusion Middleware Controlで管理します。
資格証明ストアとは、ドメイン資格証明のリポジトリです。OPSSでは、1つの論理ストアを使用してポリシーと資格証明の両方を格納します。このストアは、Fusion Middleware Controlで管理します。
ストアの詳細は、第4章「アイデンティティ、ポリシーおよび資格証明について」を参照してください。
その他の用語
システム・コンポーネントとは、WebLogicコンポーネント以外の管理可能なプロセスです。たとえば、Oracle Internet Directory、WebCache、JavaSEコンポーネントなどがあります。
Javaコンポーネントとは、システム・コンポーネントの一種ですが、その管理はアプリケーション・サーバー・コンテナで行います。通常は、ドメイン拡張テンプレートと1対1の関係にある、アプリケーションおよびリソースの集合を表します。たとえば、Oracle SOAアプリケーションやOracle WebCenter Spaceなどがあります。
OPSSでは、採用しているドメイン・ポリシー・リポジトリの種類がファイルベースであるか、LDAPベースであるかに関係なく、ドメイン・ポリシー・ストアでアプリケーション・ロールをエンタープライズ・グループにマッピングできます。このメカニズムにより、アプリケーション・ロールでの指定に従って、エンタープライズ・グループのユーザーにアプリケーション・リソースへのアクセスを許可できます。このマッピングでは、多対多が可能です。
|
注意: Oracle JDeveloperでは、アプリケーションの開発中にこのマッピングを指定できます。また、第8.4.1.2項「アプリケーション・ロールの管理」で説明するように、アプリケーションのデプロイ後にWLSTまたはFusion Middleware Controlを使用してマッピングを指定することもできます。エンタープライズ・グループにアプリケーション・ロールをマッピングすると、そのエンタープライズ・グループの権限は、その権限とそれにマッピングされたアプリケーション・ロールの権限を結合したものに書き換えられます。したがって、エンタープライズ・グループの権限が増加することはあっても減少することはありません。 |
OPSSアプリケーション・ロールは、「所属メンバー」という関係を使用して階層構造にできます。つまり、ロールは、ユーザーまたは他のロールをメンバーとして持つことができます。
|
重要: ロール階層を構築するときは、望ましくない動作を防止するために、循環依存を使用しないでください。たとえば、ロールAをロールBのメンバーに設定し、ロールBをロールAのメンバーに設定すると、このような循環依存が生成されます。 |
ロール階層では、ロールのメンバーは親ロールからパーミッションを継承します。つまり、ロールAがロールBのメンバーである場合、ロールBに付与されているすべてのパーミッションがロールAにも付与されます。当然のことながら、ロールAは、それ自体の特定のパーミッションを持っていますが、ロールBのメンバーとなることにより、ロールBに付与されているすべてのパーミッションを継承します。
次の例は、ネストしたアプリケーション・ユーザーとロールで構成したロール階層によるアプリケーション・ロールの管理です。
ロール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>
表3-1は、継承ルールに従って、前述の階層の5つのユーザーとロールそれぞれが取得するパーミッションをまとめたものです。
OPSSでは、特別なロールである認証ロールの使用がサポートされています。このロールには次の特性があります。
構成ファイルで宣言する必要がありません。
認証が成功した後、必ず、サブジェクトに関連付けられているプリンシパルとして表されます。つまり、認証されたすべてのユーザーにデフォルトで付与されます。
サブジェクト内における認証ロールの存在は、匿名ロールと相互に排他的です。つまり、（a）サブジェクトが認証を受けていない場合は、「匿名サポートとサブジェクト」の説明のように、サブジェクトにはプリンシパルと匿名ロールが含まれます。（b）サブジェクトが正常に認証された場合は、認証ロールが含まれるほか、構成によっては匿名ロールも含まれます。
アプリケーション・ロールです。したがって、あらゆるアプリケーションで使用でき、アプリケーションのロール階層に追加できます。
認証ロールに付与するパーミッションは、明示的に指定する必要はなく、所属先のエンタープライズ・グループおよびアプリケーション・ロールから暗黙的に派生します。
認証ロールの一般的な用途は、共通のアプリケーション・リソース、つまり認証されたユーザーが利用できるリソースへのアクセスを、認証されたユーザーに許可することです。
認証されたロールの使用をアプリケーション側で手動で構成する方法の詳細は、第15.1項「サーブレット・フィルタとEJBインターセプタの構成」を参照してください。
OPSSでは、匿名ユーザーと匿名ロールという、2つの特殊なエンティティを使用できます。認証ロールと同様に、これらのエンティティを宣言する必要はなく、アプリケーションによってJpsFilterまたはJpsInterceptorでその使用が構成されます。これらのどのエンティティも、アプリケーションのロール階層内でアプリケーションによって使用できます。
この匿名のエンティティを有効にしておくと、認証されていないユーザーが非保護リソースにアクセスするとき、そのユーザーは匿名ユーザーと匿名ロールのみが移入されたサブジェクトで表されます。そのサブジェクトが保護されたリソースにアクセスを試みた場合、認可過程でサブジェクトは「匿名サポートとサブジェクト」の説明のように処理されます。
匿名ユーザーおよびロールに付与するパーミッションは、明示的に指定する必要はなく、所属先のエンタープライズ・グループおよびアプリケーション・ロールから暗黙的に派生します。
匿名ユーザーおよびロールの一般的な用途は、認証されていないユーザーにパブリックな非保護リソースへのアクセスを許可することです。
匿名ユーザーおよびロールの使用をアプリケーションで手動で構成する方法の詳細は、第15.1項「サーブレット・フィルタとEJBインターセプタの構成」を参照してください。
この項では、全体を通じて匿名ユーザーおよび匿名ロールの使用が有効になっていることを前提とします。
エンドユーザーが初めて非保護リソースにアクセスした場合、サブジェクトが作成され、そのサブジェクトに匿名ユーザーと匿名ロールに対応した2つのプリンシパルが移入されます。非保護リソースに関するかぎり、そのサブジェクトは変更されず認証は行われません。
保護されたリソースにそのサブジェクトがアクセスすると認証が始まり、この時点までは匿名ロールのみを持っていたサブジェクトが、認証プロセスの結果に応じて次のように変更されます。
認証に成功した場合は次のようになります。
匿名ユーザーがサブジェクトから削除され、必要に応じて、認証されたユーザーに置換されます。
匿名ロールは削除され、認証ロールが追加されます。
その他のロールが、必要に応じてサブジェクトに追加されます。
認証に成功すると、サブジェクトには、非匿名ユーザーに対応した1つのプリンシパル、認証ロールに対応した1つのプリンシパル、および場合によってはエンタープライズ・ロールまたはアプリケーション・ロールに対応した他のプリンシパルが含まれるようになります。
認証が成功しなかった場合は、匿名ユーザーが保持されます。匿名ロールは、アプリケーションによるJpsFilterまたはJpsInterceptorの構成に応じて削除または保持されます。他のプリンシパルは追加されません。デフォルトでは、匿名ロールはサブジェクトから削除されます。
（WebLogic）管理者は、グループAdministratorsのユーザー・メンバーであり、このグループにはセキュリティ・レルムに存在している任意のユーザーを追加できます。
セキュリティ・レルムに存在するデフォルト・グループの詳細は、『Oracle Fusion Middleware Securing Resources Using Roles and Policies for Oracle WebLogic Server』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。
通常、管理者にはデフォルト名はありません。唯一の例外は実行例をインストールした場合で、その際はサンプル・ドメインの管理者のデフォルト・ユーザー名とパスワードが提供されます。ただし、これらの例は本番環境では使用しないでください。
詳細は、『Oracle Fusion Middleware Securing a Production Environment for 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 Securing a Production Environment for Oracle WebLogic Server』のWebLogic Serverホストの保護に関する項を参照してください。
一般的に、パスワードは、LDAPサーバーまたはRDBMSに格納されます。これらのパスワードが格納される特定の場所は、環境（正確にはドメインのセキュリティ・レルム）内で構成された固有の認証プロバイダによって決定されます。追加設定なしで使用できる認証プロバイダの詳細は、『Oracle Fusion Middleware Securing Oracle WebLogic Server』の組込みLDAPサーバーの管理に関する項を参照してください。
パスワードを作成すると自動的にコールされ、一連のカスタマイズ可能なパスワード作成ルールを適用するオプションのパスワード検証プロバイダの構成方法は、『Oracle Fusion Middleware Securing Oracle WebLogic Server』のパスワード検証プロバイダの構成に関する項を参照してください。
ユーザーの追加または削除の際は、第I.12項「ユーザーによる予期しないパーミッションの取得」で説明している推奨事項を考慮してください。
