セキュリティ制約は、ページとフォルダに適用されます。セキュリティ制約は、ページとフォルダに対するアクセスを許可したり拒否したりします。制約は、以下の 4 つの場所の 1 つまたは全てで定義されます。
許可は、ページまたはフォルダへのアクセスに対するパーミッション、承認、権限の授与、主体のリストのどれかに関係します。セキュリティ制約を与えるということは、 1 つ以上のパーミッションと組み合せた、 1 つ以上のセキュリティ主体のリストの関連付けを行うということです。制約を与えると、関連づけられたパーミッションのリストの通りになるようページまたはフォルダへのアクセスが許可されます。
セキュリティ制約は、PSML ファイル内、もしくはフォルダのメタデータファイル内、もしくはグローバルなセキュリティの宣言中にある XML 要素です。セキュリティ制限には name という属性が 1 つ存在します。セキュリティ制約は、以下の要素を持ちます。
最初の 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>
宣言型の制約は、サイトのルートにある 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>
フォルダのセキュリティ制約は、サイト内の各フォルダにオプショナルで存在する 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 の設定で有効になります。以下に、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") の真偽値のコンストラクタ引数が、"制約セキュリティ" モデルを有効にするかどうかの指定を行うものです。もし、宣言型のセキュリティ制約が有効でないのなら、全てのインライン、参照型、グローバルのセキュリティ制約は無視されます。