2 ユーザーおよびロールの理解
この章の内容は次のとおりです。
用語
この項では、このドキュメント全体で使用されているOPSS用語を定義します。
ユーザーおよびグループ
ユーザーとは、サービスにアクセスしているエンドユーザーです。グループとは、ユーザーおよびその他のグループのサブセットであるため、グループには階層構造があります。
認証されたユーザーとは、資格証明が検証されているユーザーです。ユーザーを認証するために、OPSSではWebLogic Server認証プロバイダを使用します。
匿名ユーザーとは、保護されていないリソースにのみアクセスを許可された、認証されたユーザーのことです。
アプリケーション・ストライプ
アプリケーション・ストライプまたはストライプとは、(アプリケーションが認識されている場合)ポリシーのサブセットです。アプリケーションでは、セキュリティ・ストアでストライプを指定することで使用するポリシーが選択されます。複数のアプリケーションで同じストライプを使用できます。
Roles
エンタープライズ・ロールまたはエンタープライズ・グループとは、ユーザーおよびグループの集合です。
アプリケーション・ロールとは、ユーザーおよびその他のアプリケーション・ロールの集合です。アプリケーション・ロールはアプリケーション・ポリシーで定義されますが、Javaコンテナに認識されるとはかぎりません。
アプリケーション・ロールは、エンタープライズ・ロールに多対多でマップできます。たとえば、(アイデンティティ・ストア内の)employee
エンタープライズ・ロールを、(あるストライプ内の)helpdesk service request
アプリケーション・ロールにマッピングし、さらに(他のストライプ内の)self service HR
アプリケーション・ロールにマップできます。
プリンシパル
プリンシパルとは、ポリシーによってパーミッションが付与されるアイデンティティです。プリンシパルには、ユーザー、外部ロールまたはアプリケーション・ロールを指定できます。
ポリシー
アプリケーション・ポリシーとは、プリンシパルに対してパーミッション・セット(アプリケーションWebページの閲覧やアプリケーション・レポートの変更など)を指定するポリシーです。アプリケーション・ポリシーにはプリンシパルが少なくとも1つ必要であり、個別のパーミッションまたはパーミッション・セットのいずれかを指定できますが、両方は指定できません。
システム・ポリシーとは、プリンシパルまたはコードソースに対してパーミッション・セットを指定するポリシーです。システム・ポリシーの有効範囲はドメイン全体です。システム・ポリシーではコードソースとプリンシパルにパーミッションが付与されますが、アプリケーション・ポリシーではプリンシパルにのみパーミッションが付与されます。アプリケーション・ポリシーとシステム・ポリシーは、jazn-data.xml
ファイルに指定します。
サブジェクト
サブジェクトとは、プリンシパルおよびユーザーの資格証明(パスワード、暗号キーなど)の集合です。認証サービスにより、サブジェクトにユーザー、グループ、アプリケーション・ロールおよび資格証明が移入されます。OPSSサブジェクトは、ドメイン間のアイデンティティ伝播にきわめて重要です。
OPSS構成ファイル
ドメイン全体に対するすべてのセキュリティ・サービスが指定されているOPSS構成ファイル。OPSS構成ファイルでの指定内容は、ドメイン内で実行されているサーバーおよびアプリケーションすべてに適用されます。
デフォルトでは、OPSS構成ファイルはjps-config.xml
ファイル(Java EEアプリケーションの場合)およびjps-config-jse.xml
ファイル(Java SEアプリケーションの場合)であり、$DOMAIN_HOME/config/fmwconfig
ディレクトリにあります。
OPSSコンテキスト
コンテキストは、ドメインに共通するサービス・インスタンスの集合を定義します。コンテキストは、OPSS構成ファイルに指定します。
セキュリティ・ストア
アイデンティティ・ストアは、エンタープライズ・ユーザーおよびグループのリポジトリで、LDAPである必要があります。すぐに使用できる状態では、ユーザーおよびグループはデフォルト・プロバイダ(組込みLDAPサーバー)に格納できます。
セキュリティ・ストアは、ドメイン内で実行されているアプリケーションすべてで使用されるシステム・ポリシー、アプリケーション・ポリシー、資格証明、監査データ、キーおよび証明書のリポジトリです。
ポリシー・ストアは、アプリケーション・ポリシーおよびシステム・ポリシーが格納される部分、すなわちセキュリティ・ストアのことです。資格証明ストアは、資格証明が格納されるセキュリティ・ストアの部分のことです。キーストアは、キーおよび証明書が格納されるセキュリティ・ストアの部分のことです。トラストストアは、サードパーティの認証局の信頼できる証明書が格納されるキーストアのことです。
監査の用語の詳細は、「監査の用語」を参照してください。
ロール・マッピング
OPSSでは、アプリケーション・ロールとエンタープライズ・グループの多対多のマッピングがサポートされています。これにより、アプリケーション・ロールでの指定に従って、エンタープライズ・グループのユーザーがアプリケーション・リソースにアクセスできます。
エンタープライズ・グループにアプリケーション・ロールをマップすると、そのエンタープライズ・グループのパーミッションは、自身のパーミッションとマップされたロールのパーミッションの和集合に書き換えられます。したがって、マッピングによってエンタープライズ・グループのパーミッションが増えることはあっても減ることはありません。
アプリケーションのデプロイ後に、WebLogic Scripting Tool (WLST)、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)またはOracle Entitlements Server (OES)を使用してアプリケーション・ロールをエンタープライズ・グループにマップします。
関連項目:
Fusion Middleware Controlを使用したロールの管理の詳細は、「アプリケーション・ロールの管理」を参照してください。
パーミッションの継承とロールの階層
ロールは、「所属メンバー」という関係を使用して階層構造にできるため、ロールはメンバーとしてユーザーまたはロールを持つことができます。
ロール階層では、ロールのメンバーは親ロールからパーミッションを継承します。つまり、roleA
がroleB
のメンバーである場合、roleB
に付与されているすべてのパーミッションがroleA
にも付与されます。また、roleA
は独自のパーミッションを持つこともできます。
関連項目:
『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のgrantAppRoleおよびrevokeAppRole
ロール階層の例
次の例は、ネストしたアプリケーション・ユーザーおよびロールのロール階層を示しています。この例では、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.WLSUserImpl</class> <name>directorAppRole</name> </member> <member> <class>weblogic.security.principal.WLSGroupImpl</class> <name>developer_group</name> </member> <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つのユーザーおよびロールのパーミッションをまとめたものです。
表2-1 付与されるパーミッションと継承されるパーミッション
ロール | 付与されるパーミッション | 実際のパーミッション |
---|---|---|
|
P1=java.io.FilePermission |
P1 |
|
P2= java.util.PropertyPermission |
P2および(継承される)P1 |
|
P3=foo.CustomPermission |
P3および(継承される)P1 |
|
該当なし |
P1およびP3(どちらも継承される) |
|
該当なし |
P1およびP3(どちらも継承される) |
ロール・カテゴリについて
ロール・カテゴリは、アプリケーション・ロールの集まりです。ロール・カテゴリには階層構造がありません。
次の例は、ロール・カテゴリの構成を示しています。
<app-roles> <app-role> <name>AppRole_READONLY</name> <display-name>display name</display-name> <description>description</description> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <extended-attributes> <attribute> <name>ROLE_CATEGORY</name> <values> <value>RC_READONLY</value> </values> </attribute> </extended-attributes> </app-role> </app-roles> <role-categories> <role-category> <name>RC_READONLY</name> <display-name>RC_READONLY display name</display-name> <description>RC_READONLY description</description> </role-category> </role-categories>
ロール・カテゴリのメンバーは<role-category>
内で構成されませんが、対応するアプリケーション・ロールの<extended-attributes>
内で構成されます。ロール・カテゴリ名では、大文字と小文字は区別されません。ロール・カテゴリは、RoleCategoryManager
インタフェースを使用して管理できます。
関連項目:
-
『Oracle Entitlements Serverの管理』のロール・カテゴリの管理
認証ロールについて
OPSSでは、認証ロールがサポートされています。このロールは、あらゆるアプリケーションで使用でき、OPSS構成ファイルで宣言する必要がありません。認証ロールに付与されるパーミッションは、所属先のエンタープライズ・グループおよびアプリケーション・ロールから取得されます(つまり、継承されるパーミッションのみが付与されます)。認証ロールの一般的な用途は、認証されたユーザーに共通アプリケーション・リソースへのアクセスを許可することです。このロールは、Javaサーブレット・フィルタおよびEnterprise JavaBeans (EJB)インターセプタで構成します。
関連項目:
匿名ユーザーとロールについて
管理ユーザーおよび管理ロールについて
WebLogic Server管理者は、Administrators
グループのユーザー・メンバーであり、このグループにはWebLogic Serverセキュリティ・レルム内のユーザーを追加できます。通常、管理者にデフォルト名はありません。
ドメインを構成すると、Administrators
グループのメンバーはAdministrators
グループのユーザーを管理できます。これらのアカウントを管理するためのツールは、Oracle WebLogic Server管理コンソール、WLSTおよびFusion Middleware Controlです。
関連項目:
『Oracle WebLogic Server本番環境の保護』のWebLogic Serverのセキュアなインストール
『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループ、セキュリティ・ロールに関する項
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのグループへのユーザーの追加
『WebLogic Scripting Toolの理解』のWebLogic Scripting Toolの使用方法に関する項
ユーザー・アカウントの管理
ユーザー・アカウントおよびパスワードの詳細は、次を参照してください。
-
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザーおよびグループの管理
-
『Oracle WebLogic Server本番環境の保護』のWebLogic Serverホストの保護
-
『Oracle WebLogic Serverセキュリティの管理』の組込みLDAPサーバーの管理
-
『Oracle WebLogic Serverセキュリティの管理』のパスワード検証プロバイダの構成