セキュリティについて

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

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

許可

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

否認

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

宣言型と参照型の制約

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

セキュリティ制約

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

  • roles - カンマで区切られた 1 つ以上のロール主体のリスト、もしくは全てのロールを表す
  • groups - カンマで区切られた 1 つ以上のグループ主体のリスト、もしくは全てのグループを表す
  • users - カンマで区切られた 1 つ以上のユーザー主体、もしくは全てのユーザーを表す
  • owner - 単一のユーザー主体
  • permissions - カンマで区切られた 1 つ以上のパーミッション (view, edit, help) のリスト

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

パーミッション

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

ロール

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

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

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

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

グループ

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

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

組み合せ

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>      
    </security-constraint>

すべて *

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

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

宣言型の制約とグローバルの制約

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

デフォルトの制約

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

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

フォルダの制約

フォルダのセキュリティ制約は、サイト内の各フォルダにオプショナルで存在する 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>

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

ページの制約

ページのセキュリティ制約は、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 内に記述しなければなりません。

フラグメントの制約

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

Spring の設定

宣言型のセキュリティ制約は、デフォルトでページマネージャコンポーネントの 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>
       <!-- 制約セキュリティモデルの有効フラグ、デフォルト true  -->
       <constructor-arg index="5"><value>true</value></constructor-arg>
  </bean>

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