[Security Constraints] セキュリティ制約

Security Constraints are applied to pages and folders. Security Constraints either grant or deny access to pages and folders. Constraints can be defined in one or all of these four places:

  • 1. Global: As declarations in the page.security file found in the root of the PSML tree.
  • 2. Folder: In the folder.metadata file optionally located in every directory.
  • 3. Page: In PSML files to constrain access to specific pages.
  • 4. Fragment: In page PSML files to constrain access to a specific fragment within a page.

セキュリティ制約は、ページとフォルダに適用されます。セキュリティ制約は、ページとフォルダに対するアクセスを許可したり拒否したりします。制約は、以下の 4 つの場所の 1 つまたは全てで定義されます。

  • 1. グローバル: PSML ツリーのルートに存在する page.security ファイル内の宣言として。
  • 2. フォルダ: 各ディレクトリにオプショナルに存在する folder.metadata ファイル内で。
  • 3. ページ: 特定のページへのアクセスを制限するために PSML ファイル内で。
  • 4. フラグメント: ページ内の特定のフラグメントに対するアクセスを制限するために PSML ファイルの中で。

[Grants] 許可

Grants are associated with permissions, authorizing, or granting, a principal list access to a page or folder. A granting security constraint is the association of a list of one or more security principals combined with one or permissions. Grant constraints grant access to a page or folder for the associated list of permissions.

許可は、ページまたはフォルダへのアクセスに対するパーミッション、承認、権限の授与、プリンシパルのリストのどれかに関係します。セキュリティ制約を与えるということは、 1 つ以上のパーミッションと組み合せた、 1 つ以上のセキュリティプリンシパルのリストの関連付けを行うということです。制約を与えると、関連づけられたパーミッションのリストの通りになるようページまたはフォルダへのアクセスが許可されます。

[Denies] 否認

A deny security constraint is declared with one or more security principals; with no associated permissions. Deny constraints prohibit access to the page or folder for the given list of principals. Note that deny constraints must be listed before grant constraints.

否認のセキュリティ制約は、 1 つ以上のセキュリティプリンシパルと共に宣言されます。制約の否認は、与えられたプリンシパルのリストの通りになるよう、ページやフォルダに対するアクセスを禁止します。制約の否認は、制約の承認の前にリストアップされる必要があることに注意してください。

[Declarative and Referential Constraints] 宣言型と参照型の制約

When working with pages and folder resource constraints, a constraint can be either a declarative constraint or a referential constraint. Declarative constraints are declared and put to use right in place for the particular page or folder resource. Where as referential constraints refer to a constraint declared in a centralized security constraint resource: the page.security file. Each site or subsite can have one page.security resource for declaring constraints to be referenced in any page or folder.

ページとフォルダのリソース制約が適用されるとき、制約は 宣言型 または 参照型 の制約のどちらかである可能性があります。宣言型の制約は、特定のページまたはフォルダのリソースが、適切に使われるために宣言されます。参照型の制約は、中央集権的なセキュリティ制約リソースである page.security ファイル内で宣言された制約を参照します。サイト毎かサブサイト毎に、任意のページやフォルダ内で参照される制約を宣言するために、page.security が 1 つあります。

[The Security Constraint] セキュリティ制約

A security constraint is an XML element found in a PSML file, a folder metadata file, or inthe global security declarations. A security constraint has one attribute: the name. A security constraint has the following elements:

セキュリティ制約は、PSML ファイル内、もしくはフォルダのメタデータファイル内、もしくはグローバルなセキュリティの宣言中にある XML 要素です。セキュリティ制限には name という属性が 1 つ存在します。セキュリティ制約は、以下の要素を持ちます。

  • roles - a comma-separated list of one or more role principals or * for all roles
  • groups - a comma-separated list of one or more group principals or * for all groups
  • users - a comma-separated list of one or more user principals or * for all users
  • owner - a single user principal
  • permissions - a comma-separated list of one or permissions (view,edit,help)
  • roles - カンマで区切られた 1 つ以上のロールプリンシパルのリスト、もしくは全てのロールを表す *
  • groups - カンマで区切られた 1 つ以上のグループプリンシパルのリスト、もしくは全てのグループを表す *
  • users - カンマで区切られた 1 つ以上のユーザプリンシパル、もしくは全てのユーザを表す *
  • owner - 単一のユーザプリンシパル
  • permissions - カンマで区切られた 1 つ以上のパーミッション (view, edit, help) のリスト

The first four elements (roles, groups, users, owner) all define the principals who will either have a permission granted or denied.

最初の 4 つの要素 (roles, groups, users, owner) は全て、承認されるもしくは拒否されるパーミッションを持つプリンシパルを定義します。

[Permissions] パーミッション

Permissions are the portal modes that are granted by the security constraint. Note that permissions are only granted, not denied. The view permission is similiar to the read permission found in operating systems. The edit permission is similiar to the write permission found in operating systems. The help permission is similiar to the info permission found in some portals.

パーミッションは、セキュリティ制限によって許可が与えられるポータルのモードです。パーミッションは許可を行うだけで、否認はしません。 view パーミッションは、オペレーティングシステムにおける read パーミッションと同様のものです。 edit パーミッションは、オペレーティングシステムにおける write パーミッションと同様のものです。 help パーミッションは、他のポータルで info パーミッションとなっているものと同様のものです。

[Roles] ロール

Constraints can be granted to one or more role principals for a set of permissions on a given resource. Roles are derived from the authorized users list of role principals, i.e. the roles that the user is a member of. If the authorized user is a member of any of the listed roles, the permission to the resource will be granted.

制約は、与えられたリソースへのパーミッションのセットを、 1 つ以上のロールプリンシパルに与えることができます。ロールは、承認されたロールプリンシパル (つまりそのユーザがメンバーであるということ) のユーザリストから得られます。もし承認されたユーザが、リストされたロールのどれかのメンバーであるのなら、リソースに対するパーミッションが与えられます。

    <security-constraint>
      <roles>adminstrator, manager</roles>    
      <permissions>view, edit</permissions>
    </security-constraint>
    <security-constraint>
      <roles>adminstrator, manager</roles>    
      <permissions>view, edit</permissions>
    </security-constraint>

Constraints can also deny role principals access to the entire resource. If the authorized user is a member of any of the listed roles, all access to the resource is denied.

制約は、ロールプリンシパルのリソース全体に対するアクセスを拒否することも可能です。もし承認されたユーザが、リストされたロールのどれかのメンバーであるのなら、リソースに対する全てのアクセスが拒否されます。

    <security-constraint>
      <roles>adminstrator, manager</roles>    
    </security-constraint>
    <security-constraint>
      <roles>adminstrator, manager</roles>    
    </security-constraint>

[Groups] グループ

Constraints can be granted to one or more group principals for a set of permissions on a given resource. Groups are derived from the authorized users list of group principals, i.e. the groups that the user is a member of. If the authorized user is a member of any of the listed groups, the permission to the resource will be granted.

    <security-constraint>
      <groups>accounting, development</groups>    
      <permissions>view</permissions>
    </security-constraint>
Constraints can also deny group principals access to the entire resource. If the authorized user is a member of any of the listed groups, all access to the resource is denied.
    <security-constraint>
      <groups>accounting, development</groups>    
    </security-constraint>

制約は、与えられたリソースへのパーミッションのセットを、 1 つ以上のグループプリンシパルに与えることができます。 グループは、承認されたグループプリンシパル (つまりユーザがメンバーであるグループ) のユーザのリストから得られます。 もし承認されたユーザが、リストされたグループのどれかのメンバーであるのなら、リソースに対するパーミッションが与えられます。

    <security-constraint>
      <groups>accounting, development</groups>    
      <permissions>view</permissions>
    </security-constraint>
制約は、グループプリンシパルのリソース全体に対するアクセスを拒否することもできます。もし承認されたユーザが、リストされたグループのいずれかのメンバーであるのなら、リソースに対する全てのアクセスが拒否されます。
    <security-constraint>
      <groups>accounting, development</groups>    
    </security-constraint>

[Users] ユーザ

Constraints can be granted to one or more user principals for a set of permissions on a given resource: The current user must be one of the listed principals in the comma-separated list in order to grant permission to the resource.

    <security-constraint>
      <users>joey, deedee, johnny</users>    
      <permissions>view, edit, help</permissions>
    </security-constraint>
Constraints can also deny user principals access to the entire resource. If the authorized user is in the list, all access to the resource is denied.
    <security-constraint>
      <users>fred</users>    
    </security-constraint>

制約は、与えられたリソースへのパーミッションのセットを、 1 つ以上のユーザプリンシパルに与えることができます。現在のユーザは、リソースに対するパーミッションを与えるためにカンマで区切られたリスト中にリストされる、プリンシパルの 1 つでなければなりません。

    <security-constraint>
      <users>joey, deedee, johnny</users>    
      <permissions>view, edit, help</permissions>
    </security-constraint>
制約は、ユーザプリンシパルの全てのリソースに対するアクセスを拒否することも可能です。もし承認されたユーザがリスト内にあれば、全てのアクセスは拒否されます。
    <security-constraint>
      <users>fred</users>    
    </security-constraint>

[Combinations] 組み合せ

Note that you can grant or deny permissions to a collection of one or more principal types. For example, here we grant view and edit permissions to the roles (manager, developer), and to the groups (QA and Research), and to the particular user (dilbert): If the authorized user is a member of any of the listed roles, groups, or users, the permission to the resource will be granted.

1 つ以上の種類のプリンシパルの集合に対してパーミッションを与えたり、拒否したりできることに注意してください。例えば、ここではロール (manager, developer) とグループ (QA と Research) と特定のユーザ (dilbert) に対して、view と edit のパーミッションを与えています。もし承認されたユーザが、ここにリストされたロール、ユーザ、グループのどれかのメンバーであるのなら、このリソースに対するパーミッションが与えられます。

    <security-constraint>
      <roles>hacker, coder, guru</roles>    
      <groups>unix, linux, freebsd</groups>
      <users>betty, fred, barney, wilma</users>      
      <permissions>view, edit</permissions>
    </security-constraint>
    <security-constraint>
      <roles>hacker, coder, guru</roles>    
      <groups>unix, linux, freebsd</groups>
      <users>betty, fred, barney, wilma</users>      
      <permissions>view, edit</permissions>
    </security-constraint>

Constraints can also deny combinations of principals access to the entire resource. If the authorized user is a member of any of the listed groups, roles or users, all access to the resource is denied.

制約は、プリンシパルの組み合せが、全てのリソースに対するアクセスを拒否することも可能です。もし承認されたユーザが、リストされたグループやロールやユーザのメンバーであれば、リソースに対する全てのアクセスは拒否されます。

    <security-constraint>
      <roles>hacker, coder, guru</roles>    
      <groups>unix, linux, freebsd</groups>
      <users>betty, fred, barney, wilma</users>      
    </security-constraint>
    <security-constraint>
      <roles>hacker, coder, guru</roles>    
      <groups>unix, linux, freebsd</groups>
      <users>betty, fred, barney, wilma</users>      
    </security-constraint>

[All *] All *

The * can be applied to roles, groups, users or permissions to imply ALL.

    <security-constraint>
      <users>*</users>      
      <permissions>*</permissions>
    </security-constraint>

全てを意味する * (アスタリスク) は、ロール、グループ、ユーザ、パーミッションの全てに適用可能です。

    <security-constraint>
      <users>*</users>      
      <permissions>*</permissions>
    </security-constraint>

[Owner] オーナー

TODO

TODO

[Declarative and Global Constraints] 宣言型の制約とグローバルの制約

Declarative constraints are declared in the page.security file of the root of a site. Declarative constraints are referenced in pages and folders with the security-constraints-ref tag. Global constraints are also declarative constraints. They are also defined and found in the page.security file in the root PSML repository. The difference with global constraints is that they implicitly apply to all folders and pages within the scope of the page.security file, (i.e. the site). Note that there can be only one page.security file in a Jetspeed installation.

宣言型の制約は、サイトのルートにある page.security ファイル内で宣言されます。宣言型の制約は、security-constraints-ref タグを使って、ページやフォルダ内で参照されます。グローバルな制約も宣言型の制約です。これらは、ルート PSML リポジトリ内の page.security ファイル内で定義され、見付かります。グローバルな制約との違いは、page.security ファイルのスコープ内 (すなわちサイト) の全てのフォルダとページに、暗黙のうちに適用されることです。Jetspeed をインストールすると、 1 つしか page.security ファイルは存在できないことに注意してください。

  <security-constraints-def name="admin">
    <security-constraint>
      <roles>admin</roles>
      <permissions>view, edit</permissions>
    </security-constraint>
  </security-constraints-def>
  <global-security-constraints-ref>admin</global-security-constraints-ref>
  <security-constraints-def name="admin">
    <security-constraint>
      <roles>admin</roles>
      <permissions>view, edit</permissions>
    </security-constraint>
  </security-constraints-def>
  <global-security-constraints-ref>admin</global-security-constraints-ref>

[Default Constraints] デフォルトの制約

Several security constraint declarations are made in the default deployment of Jetspeed:

namegrantspermissionsglobal
adminroles: adminview, edityes
managerroles: managerviewno
usersroles: user, managerviewno
public-viewusers: *viewno
public-editusers: *view, editno

セキュリティ制約の宣言には、Jetspeed のデフォルトの配備で作成されるものがあります。

制約名与えられる対象パーミッショングローバルかどうか
adminroles: adminview, edityes
managerroles: managerviewno
usersroles: user, managerviewno
public-viewusers: *viewno
public-editusers: *view, editno

[Folder Constraints] フォルダの制約

Folder Security constraints are placed in a security-constraints list in the folder.metadata file optionally found in each folder in the site. Note that the absence of a folder.metadata or security constraints within that file means that the folder will inherit the constraints of the parent folder, all the way up to the root folder of the site or subsite. Folder constraints do not inherit across subsites. Folder security constraints are made up of declarative security constraints and referential security constraints. Here is an example of both, the first being a referential constraint, the second a declarative constraint:

  <security-constraints>
    <security-constraints-ref>public-view</security-constraints-ref>
    <security-constraint>
      <groups>engineering</groups>
      <permissions>view</permissions>
    </security-constraint>    
  </security-constraints>

フォルダのセキュリティ制約は、サイト内の各フォルダにオプショナルで存在する folder.metadata ファイル内の security-constraints リスト 内に記述されます。folder.metadata ファイルがない場合、もしくはそのファイル内にセキュリティ制約の記述がない場合は、フォルダは、サイトかサブサイトのルートフォルダまでディレクトリをたどって、親フォルダの制約を継承することに注意してください。以下に 2 つの例を示します。 1 つ目は参照型の制約であり、 2 つ目は宣言型の制約です。

  <security-constraints>
    <security-constraints-ref>public-view</security-constraints-ref>
    <security-constraint>
      <groups>engineering</groups>
      <permissions>view</permissions>
    </security-constraint>    
  </security-constraints>

Note that all security constraints must be placed within a security-constraints collection.

全てのセキュリティ制約は、security-constraints 内に記述しなければなりません。

[Page Constraints] ページの制約

Page Security constraints are placed security-constraints list in PSML files and are optional. Note that the absence of a security constraints list within that file means that the folder will inherit the constraints of the folder in which it resides. Page security constraints are made up of declarative security constraints and referential security constraints. Here is an example of both, the first being a referential constraint, the second a declarative constraint:

ページのセキュリティ制約は、PSML ファイル内の security-constraints list に記述されます。これはオプショナルです。このファイルにセキュリティ制約の記述がない場合は、フォルダは、自身が存在するフォルダの制約を継承することに注意してください。ページのセキュリティ制約は、宣言型のセキュリティ制約と参照型のセキュリティ制約から作成されます。以下に、 2 つの例を示します。 1 つ目は参照型の制約、 2 つ目は宣言型の制約です。

  <security-constraints>
    <security-constraints-ref>global-view</security-constraints-ref>
    <security-constraint>
      <groups>accounting</groups>
      <permissions>view, edit</permissions>
    </security-constraint>    
  </security-constraints>
  <security-constraints>
    <security-constraints-ref>global-view</security-constraints-ref>
    <security-constraint>
      <groups>accounting</groups>
      <permissions>view, edit</permissions>
    </security-constraint>    
  </security-constraints>

Note that all security constraints must be placed within a security-constraints collection.

全てのセキュリティ制約は、security-constraints 内に記述しなければなりません。

[Fragment Constraints] フラグメントの制約

As with Page Security constraints, Fragment Security constraints are placed within security-constraints list in PSML page files and are again optional. As expected, the absence of a security constraints list implies the fragment will inherit the constraints of the page of which it is a part. Note that only the view permission is checked against these constraints. Other permissions are tested only against the containing page.

ページのセキュリティ制約と同様に、フラグメントのセキュリティ制約は、PSML ファイル内の security-constraints リスト に記述されます。この記述は省略可能です。期待通り、セキュリティの制約のリストがない場合は、フラグメントは、自身が属するページの制約を継承します。view パーミッションだけがフラグメントの制約に対してチェックされることに注意してください。他のパーミッションは含まれるページに対してのみテストされます。

[Spring Configuration] Spring の設定

Declarative Security Constraints are enabled by default in the Spring configuration of the Page Manager component. Here is the default Page Manager bean configuration from the page-manager.xml spring assembly configuration file:

宣言型のセキュリティ制約は、デフォルトでページマネージャコンポーネントの Spring の設定で有効になります。以下に、page-manager.xml という Spring の部品設定ファイルのデフォルトのページマネージャ bean の設定を示します。

  <bean id="org.apache.jetspeed.page.PageManager" 
       name="pageManager"
       class="org.apache.jetspeed.page.psml.CastorXmlPageManager">         
       <constructor-arg index="0"><ref bean="IdGenerator"/></constructor-arg>
       <constructor-arg index="1"><ref bean="DocumentHandlerFactory"/></constructor-arg>
       <constructor-arg index="2"><ref bean="FolderHandler"/></constructor-arg>
       <constructor-arg index="3"><ref bean="PageFileCache"/></constructor-arg>        
       <!-- permissions security enabled flag, default=false -->
       <constructor-arg index="4"><value>false</value></constructor-arg>
       <!-- constraints security enabled flag, default=true -->
       <constructor-arg index="5"><value>true</value></constructor-arg>
  </bean>
  <bean id="org.apache.jetspeed.page.PageManager" 
       name="pageManager"
       class="org.apache.jetspeed.page.psml.CastorXmlPageManager">         
       <constructor-arg index="0"><ref bean="IdGenerator"/></constructor-arg>
       <constructor-arg index="1"><ref bean="DocumentHandlerFactory"/></constructor-arg>
       <constructor-arg index="2"><ref bean="FolderHandler"/></constructor-arg>
       <constructor-arg index="3"><ref bean="PageFileCache"/></constructor-arg>        
       <!-- permissions security enabled flag, default=false -->
       <constructor-arg index="4"><value>false</value></constructor-arg>
       <!-- 制約セキュリティモデルの有効フラグ、デフォルト true  -->
       <constructor-arg index="5"><value>true</value></constructor-arg>
  </bean>

Here the 6th, (index="5"), boolean constructor argument specifies whether or not the "constraints security" model is enabled. If the Declarative Security Constraints are not enabled, all inline, referenced, and global security constraints will be ignored.

この例の 6 番目 (index="5") の真偽値のコンストラクタ引数が、"制約セキュリティ" モデルを有効にするかどうかの指定を行うものです。もし、宣言型のセキュリティ制約が有効でないのなら、全てのインライン、参照型、グローバルのセキュリティ制約は無視されます。