セキュリティー
認証および JAAS
認証は、ユーザーが提示した認証情報に基づいて、そのユーザーが本人であるかどうかを確認するプロセスです。Content Engine の認証は、要求がサーバーに到着する方法に応じて、その動作方法が異なります。Content Engine サーバーは、Enterprise Java™ (EJB) トランスポートおよび Content Engine Web Service (CEWS) トランスポートの 2 つのトランスポート・プロトコルを介して着信要求を受け入れます。
Content Engine は Java Platform, Enterprise Edition (Java EE) アプリケーション・サーバー内にあり、Java Authentication and Authorization (JAAS) 標準を認証の基盤として使用します。 JAAS プログラミング・モデルは、認証と許可を管理する標準的な Java フレームワークです。FileNet® P8 Platform は、JAAS を使用して、許可ではなく認証を実行します。(許可は、FileNet P8 Platform コードによって実行されます)。認証は、Java EE クライアント・アプリケーション、Java EE アプリケーション・サーバー、および 1 つ以上の JAAS LoginModules 間で実行されます。
EJB トランスポート経由での認証は、JAAS フレームワークを使用して処理されます。FileNet コードは、この認証プロセスには含まれません。呼び出し側は、EJB レイヤーにアクセスする前に、Java EE アプリケーション・サーバーによって認証されます。認証されたユーザーの認証情報を含む JAAS Subject が作成され、クライアント・アプリケーションに戻されます。
CEWS トランスポート経由での認証は、別の方法で処理されます。FileNet コードは、Web サービス・ベース・クライアントの認証プロセスに含まれます。WS-Security 標準では、セキュリティー認証情報の形式、およびセキュリティー認証情報を Web サービス要求に挿入する方法が定義されています。Web サービス要求が Content Engine サーバーに到着すると、CEWS リスナーが WS-Security のヘッダーを抽出し、その内容に基づいて JAAS ログインを実行します。この JAAS ログインが成功すると、CEWS リスナーは、EJB コンテナー内の Content Engine EJB レイヤーに要求を渡します。
Content Engine では、WS-Security ユーザー名/パスワード・トークン・プロファイルと Kerberos プロファイルがサポートされています。一方、FileNet P8 Platform は、WS-Security 標準で定義されたバイナリー・セキュリティー・トークンを使用できるようにするために、プラグ可能な認証メカニズムである Content Engine Web Service Extensible Authentication Framework (WS-EAF) を提供しています。WS-EAF は、カスタム JAAS LoginModule を作成する一連の規則から構成されています。カスタム JAAS LoginModule を作成することによりFileNet P8 CEWS リスナーと対話して、着信要求パケットの WS-Security ヘッダーに含まれる認証情報を取得することができます。詳細については、『WS-EAF Developer's Guide』を参照してください。この資料には、フレームワークを拡張する詳細情報とコード・サンプルが記載されています。
LoginModule
認証は、JAAS 構成ファイルで指定された JAAS LoginModule で実行されます。JAAS 構成ファイルを使用すると、Java Platform, Enterprise Edition 環境のクライアントとサーバーの両方に対する認証を動的に構成できます。
通常、Content Engine にアクセスする Java クライアント・プログラムは、関連するアプリケーション・サーバー用にインストールされた JAAS 構成ファイル (jaas.conf.WebSphere、jaas.conf.JBoss、または jaas.conf.WebLogic など) を使用する必要があります。 クライアントは、jaas.conf.WSI を使用することも選択できます。この場合、構成ファイルの FileNet P8 スタンザの定義では、デフォルトの EJB トランスポートではなく、CEWS トランスポートが使用されます。
構成ファイルには、JAAS 構成 (スタンザ) が 1 つ含まれます。各 JAAS 構成 (スタンザ) には、LoginModule のリストが含まれています。リスト内の各項目には、Java LoginModule クラスの完全修飾名、フラグ (「Required」、「Optional」、「Sufficient」、または「Requisite」に設定)、およびその LoginModule のオプションが指定されています。提供されるスタンザは、以下のとおりです。
- FileNetP8
この構成は、すべてのスタンドアロン (シック) Java クライアントが使用する必要があります。互換性を確保するために、このスタンザをサーブレット・ベースの Java クライアントで使用することも可能です。実際には、現在、FileNetP8Server スタンザがこの目的のために提供されています。jaas.conf.WSI ファイルを使用する場合、このスタンザでは、(jaas.conf.<app server> ファイルのこのスタンザで指定された) EJB トランスポートではなく、CEWS トランスポートを指定します。
- FileNetP8Engine
(クライアントでは使用されません。) この構成は、プロセスを処理する CEWS トランスポートによって内部的に使用されます。クライアントが使用してはなりません。このスタンザは、WS-EAF を使用している場合に限って変更できます。
- FileNetP8Server
この構成は、アプリケーション・サーバー・コンテナー内で稼働するサーブレット・ベースのクライアントが使用します。
- FileNetP8WSI
この構成は、デフォルトの EJB トランスポートではなく、CEWS トランスポートを使用する必要のある Java クライアント (スタンドアロン、またはサーブレット内) が使用できます。これを達成するもう一つの方法は、jaas.conf.WSI サンプル構成ファイルを FileNetP8 構成とともに使用することです。
- FileNetP8KerberosService
(クライアントでは使用されません。) この構成は、プロセスを処理する CEWS トランスポートによって内部的に使用されます。クライアントが使用してはなりません。
CEWS トランスポートの処理中にサーバーで必要なスタンザは、他にも多数存在します (Credentials、ReceivedCredentials、HttpCredentials など)。これらのスタンザは、クライアントが使用する JAAS 構成ファイルから安全に除去することができます。
クライアント・アプリケーションが認証を試みると、JAAS フレームワークは、構成ファイルの内容に基づいて、起動する一連の LoginModule を動的に決定します。認証が成功するのは、「Required」または「Requisite」としてマークされた LoginModule がすべて成功した場合に限られます。「Required」または「Requisite」の LoginModule が成功しない場合は、少なくとも 1 つの「Sufficient」または「Optional」の LoginModule が成功する必要があります。
独自の構成のセットアップに使用できるように、JAAS 構成ファイルのサンプル・セットが提供されています。FileNet P8 インストール・プログラムは、これらのサンプル・ファイルを Content Engine インストール・ディレクトリーの ¥config¥samples サブディレクトリー・ディレクトリーに保管します。デフォルトでは、Windows 版の Content Engine のインストール・ディレクトリーは C:¥Program Files¥IBM¥FileNet¥ContentEngine です。Windows 版以外の場合は /opt/IBM/FileNet/ContentEngine です。アプリケーション・サーバーごとに多少、要件が異なるため、ファイルにはサポートされるアプリケーション・サーバー環境に応じて jaas.conf.WebLogic、jaas.conf.jaas.conf.WebSphere、jaas.conf.JBoss などの名前が付けられています。また、特殊な CEWS トランスポート構成ファイルの名前は、jaas.conf.WSI となっています。
許可
認証が実行された後、オブジェクト・ストア内のオブジェクトにアクセスする許可が検証されます。すべてのオブジェクトには、固有のセキュリティー設定があります。複数のバージョンのドキュメントが存在する場合、各バージョンには、固有のセキュリティー設定があります。
Content Engine および Process Engine で管理される資産は保護されており、ユーザーのアクセス権限のみに基づいて表示または変更が可能になります。各オブジェクトには固有のセキュリティーがあるため、このセキュリティーによって、そのオブジェクトへのユーザーまたはグループのアクセスが制御されます。オブジェクトには、そのオブジェクトへのアクセスを制御する複数のルールを設定できます。例えば、GroupA のユーザーにはオブジェクトの表示のみを許可し、UserB にはオブジェクトの表示と変更を許可することができます。各ルール (すなわち「アクセス・コントロール」) は、Permission オブジェクトによって表現されます。このオブジェクトは、ユーザーまたはグループ (「対象者」) に付与するアクセス権を設定するものであり、権限が割り当てられたユーザーまたはグループへの参照が含まれています。ユーザーとグループの詳細については、対象者、および User、Group、SecurityPrincipal、Permission インターフェースで提供される参照ヘルプを参照してください。
アクセス・レベルは、参照された対象者が保持するアクセス権、または拒否されるアクセス権を示すものであり (読み取りアクセス権や書き込みのアクセス権など)、対象者がオブジェクトに対して実行できるアクティビティーを決定します。通常、ユーザーとグループに付与するアクセス権のタイプを設定する責任があるのは、システム管理者です。
Permissions コレクションは、オブジェクトに関連付けられた一連のアクセス・コントロール項目 (ACE) をすべて表しており、オブジェクトのアクセス・コントロール・リスト (ACL) を形成します。権限を付与するには、(1) AccessPermission オブジェクトのメソッドを呼び出して適切なプロパティーを設定し、(2) オブジェクトの権限リストに権限を追加し、(3) 変更された AccessPermissionList コレクションをオブジェクトに保存します。アクセス権を除去する場合も同様のプロセスになります。アクセス権の設定方法を示すコード・サンプルについては、「セキュリティーの操作」を参照してください。
オブジェクトへのアクセスは、Content Engine レベルで設定されるプロパティーの影響を受ける場合もあります。特に、ModificationAccessRequired および TargetAccessRequired プロパティーを設定すると、オブジェクトのカスタム・プロパティーとそのオブジェクト値プロパティーへのユーザー・アクセス、およびそれらのプロパティーを変更する能力がさらに制限されます。ModificationAccessRequired および TargetAccessRequired プロパティーの値は、Content Engine API を使用して設定または取得することはできません。ただし、アプリケーションの要件によっては、これらのプロパティーによるオブジェクト・アクセスへの影響を理解しなければならない場合があります。詳細については、Property modification access および Target access required を参照してください。
各 ACE の内部にセキュリティー識別子 (SID) があります。SID は、セキュリティー・プリンシパル (Content Engine がオブジェクト・アクセスを付与または拒否するユーザーまたはグループ) を識別するグローバルに固有な値です。
IBM® FileNet P8 は、LDAP ディレクトリー・サーバーの組み込み属性を、安定した固有のユーザー識別子またはグループ識別子として使用します。固有の ID は、SID 形式に変換されてオブジェクトの ACL に格納されます。LDAP サーバーでユーザーまたはグループが作成され、SID 属性値にデータが取り込まれたら、その値を変更してはなりません。SID の詳細について、および Content Engine がサポートする LDAP サーバーのデフォルト SID 属性のリストについては、What are access rights? のトピックの「Security identifier (SID)」を参照してください。
デフォルトの SID 属性のほとんどは、ユーザーまたはグループの作成時に LDAP サーバー自体によって生成され、マシンに依存するため、基盤となる LDAP サーバーおよびハードウェアのバックアップ、リストア、移動、および複製中に、煩雑な状況になる可能性があります。構成の柔軟性を取り入れ、固定された SID 属性に関連する問題を回避するため、使用できる属性は、SID の構成時に LDAP サーバーによって提供されたデフォルトの属性に限定されません。代わりに、識別名 (DN)、社員番号などの他の LDAP 属性を、SID として機能するように選択できます。
ユーザー ID およびグループ ID として選択する属性の値は、構成された LDAP レルム間で固有でなければなりません。Content Engine の認可プロセスは、LDAP リポジトリー内のユーザーまたはグループの単一の識別子として属性を使用するため、非固有値の場合、認可が失敗します。DirectoryConfiguration クラスの UserUniqueIDAttribute および GroupUniqueIDAttribute プロパティーの値を通じて、属性を指定します。値は通常、両方のプロパティーで同一にしますが、設計上必要な場合は、各プロパティーに異なる値を指定することも可能です。
現在は、LDAP Java API で Java String を返す LDAP 属性のみを、SID 属性として使用するように制限されています。
対象者
ユーザー・アカウントは、ディレクトリー・サービスが提供するツールを使用して Content Engine サーバーに定義します (ディレクトリー・サービスには、Microsoft Active Directory、Microsoft Active Directory Application Mode (ADAM)、Microsoft Active Directory Lightweight Directory Services (AD LDS)、Oracle Directory Server、Novell eDirectory、Computer Associates (CA) eTrust などがあります)。User オブジェクトは、特定ユーザーの Content Engine リソースへのアクセスを許可するセキュリティー・インターフェースの一部として、Content Engine API に存在します。Group オブジェクトは、ユーザー・アカウント・セットを表します。アクセス権 (権限) は、個々のユーザー・アカウント、および個々のユーザーが属するグループ (またはそのいずれか一方) に割り当てられます。
フォルダーやドキュメントなどのオブジェクトのセキュリティーは、特定のグループに属することができます。通常、これらのグループ、およびグループのメンバーシップを構成するユーザーとサブグループは、ディレクトリー・サービスが提供するツールを使用するシステム管理者が定義および作成します。 Content Engine API メソッドを呼び出して新しいグループまたはユーザーを作成することはできません。ただし、ディレクトリー・サービスに定義された Group または User オブジェクトをインスタンス化することは可能です。グループのコレクション、およびユーザーのコレクションを取得して、そのコレクションからエレメントを取得することができ、インスタンス化するオブジェクト (ユーザーまたはグループ) のタイプのために Factory クラスのメソッドを呼び出すこともできます。この後、そのオブジェクトのメソッドを呼び出して、ユーザーまたはグループに関する情報 (名前や ID など) を取得することができます。
ユーザーとグループに関する情報をアプリケーションで取得する方法によっては、システム・パフォーマンスに影響が及ぶ場合があります。パフォーマンスの考慮事項については、ロール・ベースのセキュリティーを参照してください。
暗号化
パスワード・プロパティーが Content Engine 内に保管されるときには、Federal Information Processing Standard (FIPS: 連邦情報処理標準) の Advanced Encryption Standard (AES) 128 ビット・アルゴリズムおよび Content Engine サーバーのマスター暗号鍵を使用して暗号化されます。認証情報を暗号化および復号化するマスター鍵は、Content Engine ソフトウェアのインストール時に生成および保管されます。詳細については、Content Engine 暗号化 (Content Engine Encryption) を参照してください。暗号化の情報は、CEMPBoot.properties ファイルにも指定されます (詳しくは、「Content Engine Administration」資料の『セキュリティー (Security)』セクションにある Content Engine のブートストラップ・プロパティー (Content Engine bootstrap properties) のトピックで、CipherKeyLength、CipherAlgorithm、EncryptedPassword、CEMPBootstrap の各プロパティーの説明を参照してください)。
Content Engine サーバー上でのパスワード値の実際の暗号化および復号化は、Content Engine をホストしているアプリケーション・サーバー内に存在する Java Cryptography Enhancements (JCE) モジュールを使用して実行されます。 Content Engine は FIPS 140-2 対応モードで実行できます。ただし、FIPS 140-2 認定 JCE プロバイダーが構成されている場合のみです。Content Engine を FIPS 対応モードにするには、IBM WebSphere® 7.0 プラットフォームを IBMJCEFIPS JCE プロバイダーと組み合わせて使用します。
セキュリティーのキャッシング
IBM FileNet Content Engine には、セキュリティー関連の多数のキャッシュが用意されています。これらのキャッシュは、オブジェクト・ストアに関連付けられているものもあれば、サーバーのセキュリティー構成に関連付けられているものもあります。 これらのキャッシュの大部分は、Content Engine の他のキャッシュと同様、least-recently-used (LRU) アルゴリズムに基づいており、TTL (time-to-live) が関連付けられているものもあります。キャッシュには、許可される最大キャッシュ項目数を定義する、構成可能な最大項目数属性があります。この値を超過すると、LRU エレメントは、最近使用された新しいエレメント用の場所を確保するために除去されます。キャッシュ・エレメントに関連付けられた TTL (該当する場合) は、キャッシュされた値を維持する時間を定義します。この時間を過ぎると、キャッシュがリフレッシュされます。TTL 値は、構成することもできます。キャッシュされたエレメントの特性は変更される場合があります (例えば、オブジェクトのセキュリティー権限の更新時)。そのため、キャッシュされた値は、それらの変更を有効にするために定期的にリフレッシュされます。
- SecurityDescriptorCache。セキュリティー記述子を管理 (キャッシング) して、データベースのラウンド・トリップを削減します。このキャッシュには、最大項目数属性 (ObjectStore.SecurityDescCacheMaxEntries) のみがあり、TTL 属性はありません。なぜなら、セキュリティー記述子が変更されないからです (新しい記述子が追加されるのみです)。セキュリティー記述子は古くならないため、リフレッシュする必要はありません。 この LRU キャッシュの最大項目数の値を超過すると、LRU エレメントは、より最近使用されたアイテムの場所を確保するために除去されます。
- ObjectSecurityCache。特定のオブジェクトに関連付けられたセキュリティー特性を管理 (キャッシング) します。このキャッシュは、セキュリティー・プロキシー・サポート (SecurityProxyType 定数クラス) のために使用されます。このキャッシュは、継承されるセキュリティーの計算と、オブジェクトがレコードとして宣言されている場合のレコード管理に使用されます。メタデータに SecurityProxyType が設定されているすべてのオブジェクト値プロパティーは、関連するオブジェクトのセキュリティーが計算されるときにこのキャッシュを使用します。このキャッシュには、最大項目数属性 (ObjectStore.ObjectSecurityCacheMaxEntries) と TTL 属性 (ObjectStore.ObjectSecurityCacheEntryTTL) の両方があります。
- MarkingSetCache。FileNet P8 からのマーキング・セットを管理 (キャッシング) します。 マーキング・セットは、ドメイン全体のリソースであり、1 つ以上のオブジェクト・ストア内のオブジェクトに関連付けることができます。マーキング・セット・キャッシュには、最大項目数属性 (ServerCacheConfiguration.MarkingSetCacheMaxEntries) と TTL 属性 (ServerCacheConfiguration.MarkingSetCacheEntryTTL) の両方があります。マーキング・セットは、GCD に保管されます。GCD をリフレッシュすると、すべてのマーキング・セットがリフレッシュされます。
- SubjectCache。セキュリティー・プリンシパル (JAAS Subject) 情報を管理 (キャッシング) します。サーバーの CEWS インターフェースはこのキャッシュを使用して、サーバーが実行する必要がある LDAP 認証要求の数を削減します (サーバー・プロセスに対するすべての CEWS 要求は、認証済みユーザーが実行する必要があります)。Subject キャッシュには、最大項目数属性 (ServerCacheConfiguration.SubjectCacheMaxEntries) と TTL 属性 (ServerCacheConfiguration.SubjectCacheEntryTTL) の両方があります。TTL は常に、認証情報の有効期限として構成された値 (通常は、アプリケーション・サーバーの構成値) よりも小さい値に設定する必要があります。
- PrincipalCache。プリンシパル情報を管理 (キャッシング) します。このキャッシュは、プリンシパルに関する情報 (名前、その他のプロパティーなど) とプリンシパルのセキュリティー ID とのマッピングのローカル・コピーを保管します。この情報をプリンシパル・キャッシュ内に維持すると、Content Engine は、この情報が必要になるたびに毎回認証プロバイダーから情報を取得する必要がなくなります。PrincipalCache には最大項目数属性 (PrincipalCacheMaxEntries) と TTL 属性 (PrincipalCacheEntryTTL) の両方があります。
- UserTokenCache。ユーザー・トークン情報を管理 (キャッシング) します。このキャッシュは、セキュリティー・プリンシパル (ユーザーまたはグループ) から、Content Engine がプリンシパルを許可するために使用する、そのセキュリティー・プリンシパルのセキュリティー ID (SID) のリストへのマッピングのローカル・コピーを保管します。セキュリティー ID のリストには、現行ユーザーの SID、ユーザーが (直接的に、またはグループのネストされたメンバーであることから間接的に) 属する各グループの SID、および #AUTHENTICATED-USERS 組み込みグループの SID が含まれます。 この情報を UserToken キャッシュ内に維持すると、Content Engine は、ユーザーに関する情報が必要になるたびに毎回認証プロバイダーから情報を取得する必要がなくなります。UserTokenCache には最大項目数属性 (UserTokenCacheMaxEntries) と TTL 属性 (UserTokenCacheEntryTTL) の両方があります。
ユーザーおよびグループのキャッシング
パフォーマンス上の理由から、Content Engine は、システムの構成済み認証プロバイダーのデータベースから戻されたユーザー、グループ、およびレルムのコピーをキャッシュ内に維持します。キャッシュのリフレッシュ・レートは、キャッシュされた情報の time-to-live (TTL) 値を指定するキャッシュ構成設定で制御されます。デフォルト値を以下に示します。
- EntireNetwork.get_AllRealms を呼び出して戻された Realms のコレクションの場合: 12 時間
- レルムに関連付けられている User または Group の場合: 1 時間
- ユーザーまたはグループに関連付けられている Users または Groups コレクションの場合: 1 時間
ユーザー、グループ、およびレルムの情報をキャッシュすると、その結果として、以下のような予期しない動作が発生する場合があります。
- 最後のキャッシュ・リフレッシュ以降に削除されたユーザー、グループ、またはレルムのオブジェクトが、アプリケーションで引き続き表示される場合があります。この動作は、ユーザー、グループ、またはレルムのリストを操作したときに発生する場合があります。
- 最近削除したユーザーまたはグループを AccessPermissionList コレクションで対象者として使用しようとすると、アプリケーションで例外が発生する場合があります。
- 最近追加したユーザー、グループ、またはレルムのコレクションを取得しても、それらのオブジェクトがアプリケーションで表示されず、使用しない場合があります。
- ユーザーとグループの情報を更新しても (表示名の変更など)、それを直ちに参照できない場合があります。
Content Engine のオブジェクトのセキュリティーが、上の結果によって毀損されることはありません。
グループを追加および除去する頻度は、ユーザーを追加および除去する頻度よりはるかに低い傾向があります。そのため、サイトおよびアプリケーションで、主としてユーザーではなくグループをセキュリティー対象者として使用した場合は、上の結果の影響をあまり受けません。
統合ログオン (SSO)
統合ログオン (シングル・サインオンまたは SSO とも呼ばれる) は、ユーザーが一度認証を受けるだけで複数のシステムにアクセスできる機能です。Content Engine サーバーは、以前の Windows ログオンを利用して、ユーザーを認証 (すなわち、ユーザーが本人であることを確認) します。ユーザーは、以降ログオンするたびに、ユーザー名やパスワードなどの認証情報を再入力せずにすみます。
FileNet P8 Platform の SSO サポートを使用すると、カスタム・アプリケーションは、FileNet P8 でサポートされるプラットフォームで JAAS ベースの認証を提供するすべての SSO ベンダー (CA/Netegrity や IBM Tivoli® など) と統合することができます。特定のアプリケーション・サーバーとも機能する JAAS LoginModule を SSO ベンダーが提供した場合、FileNet P8 は、Java ベース・アプリケーション用にそのシングル・サインオン・ソリューションをサポートすることができます。SSO プロバイダーとの統合には制限があります。制限の詳細については、Single Sign-on Integrations via JAAS を参照してください。カスタム・アプリケーションには以下の制限があります。
- JAAS-based ベースの SSO 統合は、Java EE ベースのクライアント (JAAS ログインを実行できるクライアント) でのみ使用できます。Java EE ベースのプレゼンテーション層サーバーと連動するほとんどのブラウザー・ベースのクライアントが、このクライアントに該当します。
- 通常、JAAS ベースの SSO 統合は、JAAS 統合を直接利用できない .NET ベースのクライアント、またはピュア Web サーバー・ベースのクライアントへは拡張されません (これらのクライアントでは、ユーザー名/パスワード、および Kerberos 認証プロファイルがサポートされます)。
- JAAS ベースの SSO 統合がサポートされるのは、Content Engine が EJB トランスポート経由で実行するように構成された場合に限られます。
SSO プロバイダーとして Kerberos を使用するクライアント向けの必要な要件および構成ステップについては、Kerberos の実装を参照してください。
オブジェクトの権限
オブジェクトのセキュリティーは、アクセス権で指定されます。アクセス権とは、対象者 (ユーザーまたはグループ) がオブジェクトに対して実行することを許可される操作を指定する権限のことです。 アクセス権は、マスク内の各ビットが 1 つのアクセス権を表すビット・マスクとして指定されます。 対応するビットが設定されているかいないかに応じて、対象者が特定の権限を保有するかしないかが決まります。 アクセス権は、API 内では、個々の権限を識別する AccessRight 定数として表されます。
クラスには、アクセス制御リスト (ACL) 形式のデフォルトのインスタンス権限があります。このリストは、対象者、および各対象者がそのクラスのオブジェクトについて保有するアクセス権のリストです。 1 人の対象者とその対象者に関連付けられているアクセス権を指定するリスト内の個々の項目が、アクセス制御項目 (ACE) です。 新規オブジェクトが作成されると、作成アプリケーションによって独自の ACL が明示的に指定されない限り、クラスのデフォルトのインスタンス権限がオブジェクトに割り当てられます。
オブジェクトの ACL は変更することも置換することもでき、ACL 内のオブジェクトのアクセス制御項目は任意の継承された権限によって補足されます。 例えば、ドキュメント・オブジェクトのデフォルトの ACL に、プロパティーとコンテンツを表示する権限 (AccessRight.READ_ACL、AccessRight.READ、および AccessRight.VIEW_CONTENT) がある 1 人の対象者が含まれているとします。 この対象者がドキュメントのプロパティーの変更やコンテンツの表示ができるようにするために、追加の権限 AccessRight.WRITE を付与できます。
Content Engine オブジェクトに対して一般的なアクションを実行するために必要なアクセス権を判別するには、「Access rights required to take actions」を参照してください。
権限の取得
オブジェクトの基本権限を取得するには、get_Permissions を呼び出します。このメソッドにより、オブジェクトに対して権限を保有するすべての対象者のアクセス権リストが返されます。 リスト内の各 AccessPermission オブジェクトは、1 人の対象者 (1 人のユーザーまたは 1 つのグループ)、その対象者に関連付けられているアクセス権 (権限)、およびオブジェクトに対する指定のアクセス権がその対象者に付与されているかいないかを示します。
get_Permissions は、ほとんどの IndependentlyPersistableObject オブジェクトで呼び出すことができます。
Marking インターフェースは、Permissions プロパティーを持つ唯一のものですが、1 次オブジェクトの有効なアクセスを計算するためには使用されないことに注意してください。詳細については、Marking オブジェクトの権限を参照してください。
権限の設定と確認
オブジェクトに権限を設定するには、set_Permissions を呼び出し、AccessPermission オブジェクトのコレクションを渡します。 コード例については、「アクセス権限の設定」を参照してください。
ユーザーの基本アクセス権を確認するには、IndependentlyPersistableObject に対して getAccessAllowed を呼び出します。これにより、現行の呼び出し元の、オブジェクトに対する有効なアクセス権を表すビット・マスクが返されます。次に AccessRight 定数を使用して権限をチェックします。コード例については、「権限のチェック」を参照してください。
ユーザー・インターフェースへの権限の表示
オブジェクトの権限を選択するためにユーザー・インターフェース (UI) が必要なアプリケーションのために、Content Engine API に AccessPermissionDescription インターフェースが用意されています。このインターフェースには、権限を選択するためにユーザーが必要とするアクセス権およびアクセス・レベルについての説明情報を取得するメソッドが用意されています。
オブジェクトに対して使用可能なすべてのアクセス権とアクセス・レベルを UI に設定するには、オブジェクト・タイプのクラスからアクセス権の記述 (APD) のコレクションを取得します。このコレクションは、そのオブジェクト・タイプに対してユーザーが設定できるすべての権限を表します。次に、このコレクション内で、各 APD の権限タイプ、表示名、および説明テキストを繰り返し表示します。
コード例については、「アクセス権の記述の取得」を参照してください。
ロール・ベースのセキュリティー
ロール・ベースのセキュリティーは、権限がグループ・メンバーシップに基づいていることを意味します。ロール・ベースのセキュリティーを使用すると、パフォーマンス上の利点が得られます。ロール・ベースのセキュリティーは、個々のユーザーに権限を割り当てるときに使用することをお勧めします。
User および Group オブジェクトのコレクションを戻すメソッド (Group インターフェースの get_Users や Realm インターフェースの findUsers および findGroups など) の呼び出しでは、ディレクトリー・サーバー上で検索操作が実行されます。これらの呼び出しに関連する検索操作の応答時間は、戻される項目数が増すとともに増加します。システム・リソースが限定されたディレクトリー・サーバーで検索を実行したときは、さらに応答時間が低下します。通常、レルム内のグループ数は、レルム内のユーザー数よりはるかに少なくなっています。そのため、グループ検索の応答時間は、ユーザー検索よりも短くなります。例えば、アプリケーションを作成するときは、最初に Realm.findGroups を呼び出し、必要に応じて Group.get_Users() のみを呼び出します。 グループとユーザーを含む非常に大規模なディレクトリーからコレクションを戻すときは、findGroups および findUsers メソッドのパラメーターで提供されるフィルター機能を使用して、戻されるアイテムの数を制限します。
ネストされた一連のグループに属する User または Group オブジェクトで get_MemberOfGroups を呼び出すと、そのユーザーまたはグループが属するすべてのグループが返されます。
DirectoryConfiguration クラスに RestrictMembershipToConfiguredRealms プロパティーを設定すると、グループ・メンバーシップ検索を IBM Administration Console for Content Platform Engine に構成されているレルム内に制限できます。このプロパティーの値が false (デフォルト) の場合、Content Engine サーバーは次のタイプのグループ・メンバーシップを検索します。
- レルム内ローカル・グループ・メンバーシップ。
- 構成済みのレルム内に存在するレルム間グループ・メンバーシップ。
- Administration Console for Content Platform Engine に構成されていないレルムに関係するレルム間グループ・メンバーシップ。 Content Engine サーバーはこのタイプのグループ・メンバーシップを検出すると、エラー・ログを記録し、検索処理を停止します。
このプロパティーの値が true の場合、Content Engine サーバーは最初の 2 つのタイプのグループ・メンバーシップを検索しますが、3 番目のタイプは無視します。 より詳細には、グループ・メンバーシップ検索が Administration Console for Content Platform Engine で構成されていないレルムを検出してもエラーは生成しません。代わりに、INFO レベルのメッセージが Content Engine サーバーのエラー・ログに書き込まれ、この特定のグループ・メンバーシップをスキップして処理が続行されます。すなわち、この Boolean プロパティーを有効にすると、Content Engine サーバーは Administration Console for Content Platform Engine に構成されていないレルムに関係するレルム間グループ・メンバーシップをすべて無視します。
Windows Active Directory Application Mode (ADAM) を除き、RestrictMembershipToConfiguredRealms プロパティーは、IBM FileNet Content Engine 4.5 でサポートされるすべてのタイプのディレクトリー・サービス・プロバイダーでサポートされます。 レルム間グループ・メンバーシップをサポートしない ADAM の場合、サポートされるすべてのディレクトリー・サーバーでの一貫性を保つため、このプロパティーは DirectoryConfiguration クラスにそのまま保持されますが、DirectoryConfigurationADAM オブジェクトでこのプロパティーを設定しても意味がなく、設定は無視されます (RestrictMembershipToConfiguredRealms は DirectoryConfiguration クラスに指定され、このクラスは DirectoryConfigurationADAM などの子クラスに継承されます)。
メンバーシップ検索を Administration Console for Content Platform Engine に構成されているレルムのみに制限する場合、セキュリティーに影響する可能性があります。以下のシナリオがその一例です。 セキュリティー管理者が 2 つの Active Directory ドメイン、X および Y を構成します。次に、管理者はドメイン X にグループ A を構成し、このグループ A がドメイン Y のグループ B に属するように構成します。次に、グループ B は Content Engine へのアクセスを拒否されます。 結果として、ドメイン X のグループ A も Content Engine へのアクセスを拒否されます。そのため、管理者はドメイン Y を構成から除去し、ドメイン X で DirectoryConfigurationAD.RestrictMembershipToConfiguredRealms を true に設定します (すなわち、ローカル・グループ・メンバーシップのみを使用)。これにより、グループ A に事前に構成された拒否アクションは有効でなくなるため、セキュリティーが侵害される可能性があります。
検索操作でレルム間グループ・メンバーシップを無視するように選択する前に、セキュリティー上の影響を慎重に調べてください。
セキュリティー・マーキング
セキュリティー・マーキングは、オブジェクトに割り当てることのできる追加のセキュリティー・レベルであり、Marking オブジェクトによって表されます。 Marking オブジェクトは、メタデータの動作とアクセス・コントロールの動作を組み合わせたものであり、プロパティー値を変更することにより、オブジェクトのアクセス・コントロールを変更できます。各マーキングには、文字列のメタデータ値があります。これは、マーキングをオブジェクトに適用するときに、プロパティー値に割り当てられます。
Marking オブジェクトは、マーキング・セットの単一のアイテムを表しています。マーキング・セット内のマーキングでは、オブジェクトの単値または多値プロパティーの取りうる値のリストを定義します。マーキング・セットは、オブジェクト・クラスのプロパティーに関連付けられます。例えば、「Security Codes」という名前のマーキング・セットで、個々のマーキングが「Top Secret」、「Secret」、「Confidential」などの文字列値を持つとします。この場合、「Security Codes」マーキング・セットを Document オブジェクトに割り当てた後、そのプロパティーのいずれかの値を設定すると、そのマーキングの 1 つ以上をドキュメントに割り当てることができます。(オブジェクトには、複数のマーキングではなく、1 つのマーキング・セットのみを割り当てられることに注意してください。) 例えば、あるドキュメントのカスタム・プロパティー Clearance に、「Top Secret」の値を割り当てることができます。認可サービスは、特定のオブジェクトの権限を評価した後、そのオブジェクトのマーキングも評価します。そのドキュメントにアクセスするセキュリティー・プリンシパルは、割り当てられたすべてのマーキングからの十分なアクセス権を持つ必要があります。
新しいオブジェクトの Marking プロパティーには、複数の値を設定できます。使用権限ではなく追加権限がユーザーに付与された Marking プロパティー値を渡してオブジェクトの作成を試みると、メソッドは「アクセス拒否」例外を発行します。
Marking オブジェクトの作成
マーキング・セットおよびマーキングを作成する場合、FileNet P8 ドメイン管理者は、アクセス権が必要になります。マーキング・セットおよびマーキングは、Content Engine GCD に保管されます。マーキング・セットは、オブジェクト・クラスのプロパティーに関連付けられます。Content Engine API を使用して Marking オブジェクトを作成することはできません。ただし、保存された Content Engine マーキングのインスタンスを作成することは可能です。Marking オブジェクトをインスタンス化する方法のリスト、および 1 つ以上のマーキングを割り当てることのできるオブジェクトのリストについては、Marking インターフェースの参照ヘルプを参照してください (Content Engine の Marking オブジェクトおよび MarkingSet オブジェクトの作成方法については、「Content Engine Security」資料の『マーキング (Markings)』のトピックを参照してください)。
Marking オブジェクトのインスタンスから、その ID、そのクラス記述の ID、およびその表示名を取得できます。また、マーキングの値、およびマーキング適用時にそのマーキングの値に関連付けられる一連のアクセス権を戻すメソッドを呼び出すことができます。マーキングの制約マスクを取得することもできます。制約マスクとは、Marking をオブジェクトに適用するときにマーキングの影響を受ける一連のアクセス権を表すビット・マスクです。これらの各メソッドについては、Marking インターフェースのオンライン・ヘルプを参照してください。コード例については、「Marking オブジェクトの操作」を参照してください。
アクティブ・マーキング
マーキングを持つことのできるすべてのオブジェクトには、1 つ以上のマーキングを割り当てることができます。オブジェクトに割り当てられたマーキングは、アクティブ・マーキングと呼ばれます。 単一のオブジェクトに割り当てられたすべてのマーキングのリストは、ActiveMarkings コレクションによって表されます。Content Java API を使用して ActiveMarking オブジェクトまたは ActiveMarkings コレクションを作成することはできません。ただし、オブジェクトの ActiveMarkings プロパティーを使用すれば、ActiveMarking オブジェクトをインスタンス化して、そこから、オブジェクトに割り当てる Marking オブジェクトを取得することができます。
マーキング・セットのキャッシング
マーキング・セットの情報をキャッシングする方法は、ユーザーおよびグループの情報をキャッシングする場合とほとんど同じです。MarkingSetCacheEntryTTL プロパティーを使用してキャッシュのリフレッシュ時間を設定できます。これは、ユーザーおよびグループのキャッシュのリフレッシュ時間の設定と同様です。キャッシュは、マーキング・セットを変更したとき (例えば、新しいマーキングをマーキング・セットに追加したとき) にも自動的にリフレッシュされます。マーキング・セットが削除されると、キャッシュの有効期限が切れます。
マーキング・セット・キャッシュには、定義されているマーキング・セットごとに 1 つのエントリーが含まれます。(マーキング・セット内のマーキング値の数は、キャッシュ・サイズによる制限を受けません。) 例えば、マーキング・セット・キャッシュの最大サイズを 100 に設定し、200 のマーキング・セットを定義している場合、メモリーにはこの半数のマーキング・セットのみがロードされます。パフォーマンスを最大限に引き出すには、マーキング・セット・キャッシュの最大サイズを、実際のマーキング・セット・インスタンス数よりも大きな値に設定してください。
マーキングが適用または変更されたオブジェクトにユーザーがアクセスするときは、キャッシュ更新のタイム・ラグによる影響を受ける場合があります。詳細については、セキュリティー・キャッシュを参照してください。
Marking オブジェクトの権限
Marking オブジェクトの権限を取得する場合、Marking.get_Permissions メソッドで戻される権限は、それが含まれる Marking オブジェクトへのアクセス権を表さないことに注意してください。これは、マーキング値に関連付けられたアクセス権のコレクションであり、マーキングをオブジェクトに割り当てるときに適用されます。このメソッドは、オブジェクトにマーキングを適用するユーザーと、オブジェクトからマーキングを除去するユーザーを決定する特別な権限も戻します。次のいくつかの段落では、これらの特別な「追加」、「除去」、および「使用」の各権限について説明します。
ユーザーまたはグループには、認可サービスで実行されるマーキング関連の操作 (マーキングの追加、削除、および使用) を実行する特別な権限を付与する必要があります。マーキングをオブジェクトに割り当てられる (追加できる) ようにするには、「追加」権限 (AccessRight.ADD_MARKING)、マーキングをオブジェクトから削除するには、「除去」権限 (AccessRight.REMOVE_MARKING) が必要です。
「使用」権限 (AccessRight.USE_MARKING) は、マーキングをオブジェクトに割り当てるときに制約マスクを適用するかどうかを決定します。ユーザーが「使用」アクセス権を拒否された場合は、ConstraintMask プロパティーの値が適用され、認可サービスで計算されたオブジェクトの事前の 有効アクセス・マスクが、この値でオーバーライドされます。
現在のユーザーおよび Marking オブジェクトの権限に基づいて Marking オブジェクトのアクセス・マスクを取得するには、get_MarkingUseGranted を呼び出します。この戻り値から、マーキング関連の操作をオブジェクト上で実行する適切な権限が特定のユーザーにあるかどうかを判別できます。
Marking 関連のプロパティー
オブジェクトに Marking を適用するには、最初に、オブジェクトの ClassDescription からの PropertyDescription に、Marking を含んでいる MarkingSet を関連付ける必要があります。この関連付けを行うと、PropertyDescription で定義されるプロパティーに割り当て可能な値が、Marking Set の Markings に関連付けられた値に制約される効果があります。
以下のトピックでは、特定のマーキング関連のプロパティー (MarkingSets、MarkingSet、IsHierarchical、ActiveMarkings、および ConstraintMask) に関する情報を説明します。
MarkingSets および MarkingSet プロパティー
Domain オブジェクトの MarkingSets プロパティーでは、特定のドメインに関連付けられた MarkingSet オブジェクトを含むコレクションを指定します。
マーキングの割り当てが可能なすべてのオブジェクトは、その PropertyDescription オブジェクト内に MarkingSet プロパティーを所有しています。PropertyDescription で記述されるプロパティーに割り当て可能なマーキング値は、このプロパティーの値によって定義されます。
このプロパティーを使用すると、特定のセキュリティー・プリンシパルがオブジェクトに割り当てることのできる Marking オブジェクトのリストを取得できます。戻されたマーキングはユーザー・インターフェースに表示することが可能であり、特定のユーザーは、このインターフェースから選択を行うことができます。例えば、「Security Codes」という名前のマーキング・セットの MarkingSet プロパティーに、「Top Secret」、「Secret」、「Confidential」の各マーキングが含まれることが考えられます。
IsHierarchical プロパティー
MarkingSet オブジェクトは、非階層または階層として定義することが可能です。これは、その IsHierarchical プロパティーの値に反映されます。
非階層マーキング・セットには 1 つ以上のマーキングが含まれており、それぞれのマーキングは互いに独立しています。オブジェクトへのセキュリティー・アクセスを算出するため、ほとんどの場合はサーバーがマーキング・セットとセットに含まれるマーキング値の両方に ID によってアクセスします。これは、効率的かつ迅速な方法です。ただし、新規マーキング値がマーキング・セットに追加されると、マーキング・セットが階層型であるか非階層型であるかに関係なく、サーバーによってマーキング・セット内の各値が検査され、セキュリティー・アクセスが再計算されます。マーキング・セット内の値の数が非常に多い場合、この操作のパフォーマンスに影響する可能性があります。
階層マーキング・セットでは、マーキングが単純な単一の分岐階層に配列されます。各マーキングには、最上位のマーキング (それより上位のマーキングがない) 以外に、上位マーキングが 1 つ存在します (上位マーキングは、同じセット内に存在する必要があります)。
階層マーキング・セットの目的は、アクセス権を評価するときに、優先順位をサポートすることです。階層マーキング・セットのマーキングによって、一連のセキュリティー・プリンシパルにアクセス権が明示的に付与されます。また、このマーキングによって、階層内の下位のすべてのマーキングに同じアクセス権が暗黙的に付与されます。マーキング・セットが階層型の場合、サーバーはオブジェクトへのセキュリティー・アクセスを計算するため、マーキング・セット内のマーキング値の階層パスをたどる必要があります。マーキング・セット内のマーキング値の数が非常に多い場合、この操作のパフォーマンスに影響する可能性があります。
最良の方法は、マーキング・セットが階層型または非階層型のいずれで定義されているかどうかに関係なく、マーキング・セット内のマーキング値の数を常に少なくしておくことです。多数のマーキング値が必要な場合は、少ない数のマーキング値を含むマーキング・セットを多数作成する方法が効率的です。定義されているマーキング・セットごとに、マーキング・セット・キャッシュ内に 1 つのエントリーを作成すると、各エントリーは少量のメモリーを占有します。ただし、この場合のシステムに対する影響は、1 つのマーキング・セット内に多数のマーキング値がある場合のパフォーマンスに対する影響に比べごくわずかです。
ActiveMarkings プロパティー
マーキングを割り当てることのできるすべてのオブジェクトは、ActiveMarkings プロパティーを持ちます。このプロパティーは、問題のオブジェクトに割り当てられたすべての ActiveMarking オブジェクトを戻すリスト値プロパティーです。このリストは Values コレクションであり、そのエレメントは、オブジェクトに割り当てられた ActiveMarking オブジェクトです。オブジェクトの ActiveMarkings プロパティーを使用すると、ActiveMarking オブジェクトを取得できます。このオブジェクト・インスタンスから getMarking を呼び出すと、問題のオブジェクトに割り当てられた実際の Marking オブジェクトを取得できます。コード・サンプルについては、「Marking オブジェクトの操作」を参照してください。
ConstraintMask プロパティー
オブジェクトの ConstraintMask プロパティーは、マーキングをオブジェクトに適用するときに影響を受けるアクセス権を表します。Marking オブジェクトを作成するときは、制約マスクが指定されます。マーキングをオブジェクトに適用する場合、制約マスクは、オブジェクトの事前の有効アクセス・マスクから、マスクのビット設定に対応するアクセス権を取り去るために機能します。
オブジェクトの事前の有効アクセス・マスクに制約マスクが適用されるかどうかは、マーキング用の「使用」アクセス権がセキュリティー・プリンシパルに付与されるかどうかによって決定されます。セキュリティー・プリンシパルに「使用」権限が付与された場合、制約マスクは適用されません。セキュリティー・プリンシパルに「使用」権限が拒否された場合、オブジェクトのアクセス・コントロールは、制約マスクに基づいて変更されます。例えば、マーキングを Document オブジェクトに適用するときに、制約マスクのすべてのビットが「オン」であり、ユーザーが AccessRight.USE_MARKING 権限を拒否された場合、制約マスクのビットは、Document オブジェクトの事前の 有効アクセス・マスクから取り去られます。計算後の結果 (有効アクセス・マスク) によって、ユーザーは、そのドキュメントにアクセスできなくなります。
マーキングをオブジェクトに割り当てる場合、マーキングの権限によってユーザーまたはグループに「使用」アクセス権 (AccessRight.USE_MARKING) が付与されていないときは、制約マスクのビットで表される権限が、認可サービスで計算された事前の有効アクセス・マスクから取り去られます (除去されます)。この減算結果が、オブジェクトの有効アクセス・マスクです。
制約マスクの値は、Marking インターフェースの get_ConstraintMask を呼び出すことにより取得できます。
オブジェクトのセキュリティー
新規作成するオブジェクトは、そのクラスから直接デフォルトの権限を取得します。ClassDescription インターフェースの get_DefaultInstancePermissions メソッドは、クラスに属するオブジェクトのデフォルトの権限を戻します。このメソッドを使用すると、クラスの権限がアプリケーションに適しているかどうかを判別したり、デフォルトの権限をユーザー・インターフェースに表示して、このクラスのオブジェクトを新規作成するときにユーザーが権限を変更できるようにすることが可能です。
オブジェクトは、継承やセキュリティー・ポリシーから権限を取得することもできます。
セキュリティーの継承
セキュリティーの継承は、継承されるセキュリティー関係に基づいてアクセス・コントロールを管理するカスタマイズ可能なメカニズムです。セキュリティー関係は、アプリケーション・オブジェクト・モデルに固有の関係を反映するように割り当てることができます。
Document または CustomObject オブジェクト (Versionable インターフェースを実装した任意のクラス) は、以下のソースに基づいてセキュリティーを継承できます。
- 子オブジェクトの SecurityFolder プロパティーのセキュリティーの親として識別される Folder オブジェクト。子オブジェクトのオブジェクト値プロパティーを使用して、複数の異なるセキュリティーの親 (フォルダー) を指定できます。
- セキュリティー・ポリシー。
- セキュリティーの親とセキュリティー・ポリシーの組み合わせ。
Folder オブジェクトは常に、その親フォルダーから権限を継承します。Document または CustomObject オブジェクトのセキュリティーの親は、その SecurityFolder プロパティーの値に反映されます。オブジェクトの SecurityFolder 値は、オブジェクトをフォルダーに格納する時点で間接的に設定できます。これを行うには、Folder.file メソッドを呼び出して、defineSecurityParentage パラメーターの値として DefineSecurityParentage を指定します。これにより、オブジェクトが格納されるフォルダーは、SecurityFolder 値として設定されます。
ただし、子オブジェクトの SecurityFolder プロパティーを単独で設定した場合は、指定された親の権限を子オブジェクトが継承することが保証されません。(抽象継承ツリーの) 子オブジェクトの深さ (レベル) まで継承可能な権限のみが継承されます。Permission インターフェースの set_InheritableDepth メソッドを使用すると、親オブジェクトのセキュリティーを継承できる深さを指定することが可能です。メソッドのパラメーターに、継承チェーン内のレベルに対応する値を設定します。継承可能レベルの値は、以下のとおりです。
- 0 - このオブジェクトのみ (継承なし)。
- 1 - このオブジェクトと直接の子のみ。1 よりも大きい他の正の値は、許可される継承の深さを示します (例えば 2 は、このオブジェクトと、直接の子および孫のみが、権限を継承できることを示します)。
- -1 - このオブジェクトとすべての子 (継承可能レベルは無限)。
- -2 - すべての子 (継承可能レベルは無限) に継承するが、オブジェクト自体は継承なし。
- -3 - 直接の子のみ継承するが、このオブジェクトは継承なし。-3 よりも小さい他の負の値は、許可される継承の深さを示します (例えば -4 は、オブジェクトの直接の子および孫のみが権限を継承し、オブジェクト自体は継承しないことを意味します)。
ACE がオブジェクトのチェーン内のオブジェクトによって継承されると、InheritableDepth プロパティー値は 1 ずつ減少します。
継承された権限のソースを確認するには、例えば、Permission.get_PermissionSource を呼び出して、Permission オブジェクトの PermissionSource プロパティーの値を取得します。PARENT (SOURCE_PARENT) がソースである権限項目が継承されています。
子オブジェクトに対するセキュリティーの継承は動的に、すなわち、子オブジェクトでアクセス・チェックが実行されるとき、または子オブジェクトに関連付けられた Permissions コレクションが取得されるときに、常に計算されます。継承されるアクセス・コントロール項目 (ACE) は、子オブジェクトのアクセス・コントロール・リスト内で永続化されませんが、子オブジェクトの SecurityFolder プロパティーに指定されたセキュリティーの親の継承可能な ACE から計算されます。
セキュリティーの親は、オブジェクト値プロパティーを使用して指定することもできます。SecurityProxyType 定数には、INHERITANCE 設定を使用します。SecurityProxyType は、PropertyTemplateObject.set_SecurityProxyType を使用して設定できます。
INHERITANCE タイプのセキュリティー・プロキシーを使用すると、オブジェクトに複数のセキュリティーの親を指定できます。これを行うには、オブジェクトの複数のオブジェクト値プロパティーに SecurityProxyType.INHERITANCE 値を割り当てます。オブジェクトに対する結果のセキュリティー記述子は、各種のセキュリティーの親の継承可能な ACE と、子オブジェクトの永続化された ACE とをマージすることにより計算されます。
セキュリティー継承のルールについては、『Content Engine Security』マニュアルの「Understanding security inheritance」トピックを参照してください。
セキュリティー・ポリシー
セキュリティー・ポリシーを使用すると、標準のセキュリティーよりも高度な方法で、オブジェクトのセキュリティーを管理することができます。例えば、セキュリティーの親を通じてセキュリティーを継承したオブジェクトの代わりに、セキュリティー・ポリシー機能を使用すれば、オブジェクトの状態の変更に基づいて、アクセス権を割り当てることができます。
セキュリティー・ポリシーでは、以下の 2 つのセキュリティー管理メカニズムがサポートされます。
- サーバー管理のバージョン状態ベースのセキュリティーの変更
- アプリケーション管理の状態ベースのセキュリティーの変更
バージョン状態のセキュリティー
バージョン状態のセキュリティーを有効にすると、オブジェクトの状態が変化したときに、バージョン管理可能なオブジェクト (Document およびそのサブクラス) にアクセス権が自動的に適用されます。この動作は、2 レベルのバージョン管理で実行されます。この管理では、ドキュメントが 4 つの事前定義の状態で移行すると、そのドキュメントへのアクセスが状態ごとに変わります。これらの 4 つの事前定義のドキュメントの状態は、処理中、リリース済み、予約、および置換済みです。例えば、ドキュメントがリリース済みの状態に入ると (現在のメジャー・バージョンになると)、すべてのユーザーにそれを表示することができます。しかし、ドキュメントがより新しいバージョンによって置換されると、そのドキュメントは、ドキュメント所有者にしか表示できません。
アプリケーション管理の状態のセキュリティー
アプリケーション管理のセキュリティーを選択することもできます。このセキュリティーでは、バージョン管理可能なオブジェクトとバージョン管理不可能なオブジェクト (例: CustomObject、または Folder オブジェクト) の両方に対する状態ベースの変更が、ある状態から別の状態にオブジェクトが遷移するときに適用されます。この場合、状態変更の定義は、完全にアプリケーションで定義されます。例えば、アプリケーションは、状態変更を、オブジェクトが最後に変更されてから特定の期間が過ぎたときに発生するものとして定義できます。オブジェクトの状態が変化すると、アプリケーションは、セキュリティーを変更すべき時点を識別し、選択したセキュリティー・テンプレートで指定されたアクセス権を明示的に適用することにより、そのオブジェクトへのアクセスを制御します。このプロセスは、間接性と抽象性のレベルを提供する点で、さまざまな時点でアクセス権を直接変更するアプリケーションとは異なります。アプリケーションは、依然としてアクセス権の変更の特性とタイミングを制御しますが、変更に関する特定の詳細は、セキュリティー・ポリシーから分離されています。
セキュリティー・ポリシー
セキュリティー・ポリシーは、オブジェクトの状態が変化したときに、そのオブジェクトへのアクセスを制御するメカニズムです。セキュリティー・ポリシーは、一連のセキュリティー・テンプレートを保持するコンテナーです。テンプレートは、Document、CustomObject、または Folder の各オブジェクトに適用できる事前定義の権限のコレクションを保持しています。テンプレートでは、そのテンプレートをオブジェクトに適用したときに発生するセキュリティーの変更を厳密に定義します。
セキュリティー・ポリシーを作成したら、デフォルトのセキュリティー・ポリシーを Document、CustomObject、および Folder の各クラスに割り当てることができます(通常、これらのタスクは、Content Engine 管理者によって実行されます)。オブジェクトのセキュリティー・ポリシーは、その SecurityPolicy プロパティーの値に反映されます。適切な権限を持つユーザーは、クラスからセキュリティー・ポリシーを除去したり、クラスのセキュリティー・ポリシーを変更したりできます。これらのクラスのいずれかのサブクラスを新規作成する場合、サブクラスは、その親クラスのセキュリティー・ポリシーを継承します。しかし、サブクラスが正常に作成された後、そのセキュリティー・ポリシーは、オブジェクトの SecurityPolicy プロパティーを設定して除去または変更することができます。これは、その他のすべてのオブジェクト値プロパティーを設定するときと同じ方法で行うことができます。
セキュリティー・ポリシーでは、オブジェクトのセキュリティーを柔軟に制御します。
- 単一のセキュリティー・ポリシーで、さまざまなクラスのオブジェクトを管理できます。例えば、単一のセキュリティー・ポリシーを作成し、それを Document、Folder、および CustomObject の各クラスまたはそのサブクラスの任意の組み合わせに割り当てることができます。
- 同じクラスのオブジェクトのさまざまなグループで、複数のセキュリティー・ポリシーを使用できます。例えば、複数の Document オブジェクトを作成し、それぞれのオブジェクトに異なるセキュリティー・ポリシーを割り当てることができます。
- 単一のセキュリティー・ポリシーを多数のオブジェクトで共有できます。例えば、単一のセキュリティー・ポリシーを作成し、それを 0 個以上の Document、Folder、CustomObject オブジェクト、またはこれらのオブジェクト・タイプの任意の組み合わせに割り当てることができます。
セキュリティー・ポリシーは、一連のセキュリティー・テンプレートから構成されます。各セキュリティー・テンプレートは、オブジェクトの状態に対応しています。それぞれのテンプレートには、アクセス権が含まれています。これらのアクセス権は、テンプレートを適用した結果、オブジェクトに割り当てられます。バージョン可能なオブジェクト (Document など) が、あるバージョン状態から別のバージョン状態に (例えば、処理中からリリース済みに) 移行すると、適切なセキュリティー・テンプレートがセキュリティー・ポリシーから取得され、それがオブジェクトに自動的に適用されます。この文脈における「適用」とは、セキュリティー・テンプレートに定義された権限がオブジェクトに割り当てられることを意味します。このとき、以前セキュリティー・テンプレートから継承された権限はすべて置換されます。アプリケーションでは、バージョン管理可能なオブジェクトまたはバージョン管理不可能なオブジェクトにテンプレートを明示的に適用することもできます。詳細については、「セキュリティー・テンプレートの適用」を参照してください。
セキュリティー・ポリシーは、Content Engine API から SecurityPolicy オブジェクトと SecurityTemplate オブジェクトを通じて管理および操作します。これらのオブジェクトの詳細については、SecurityPolicy オブジェクトおよび SecurityTemplate オブジェクトを参照してください。
SecurityPolicy オブジェクト
SecurityPolicy オブジェクトは、SecurityTemplate オブジェクト・セット用のコンテナー・オブジェクトであり、別個に永続化、およびサブクラス化することが可能です。各 SecurityPolicy オブジェクトには、0 個以上のアプリケーション・セキュリティー・テンプレート、および 0 から 4 個のバージョン管理可能なセキュリティー・テンプレートを含めることができます。SecurityPolicy オブジェクトの複数のオブジェクト値を持つ SecurityTemplates プロパティーには、ポリシー内のセキュリティー・テンプレートが含まれています。SecurityPolicy オブジェクトは 1 つ以上の Document、CustomObject、Folder オブジェクト、または共通のアクセス・コントロール方式を共有する、上の任意のオブジェクトの組み合わせと関連付けることができます。SecurityPolicy オブジェクトをオブジェクトに関連付けると、ポリシーに含まれているテンプレートをオブジェクトに適用できます。単一の SecurityPolicy オブジェクトには、バージョン管理可能なセキュリティー・テンプレートとアプリケーション・セキュリティー・テンプレートのいずれか一方、または両方を含めることができます。
適切な権限を取得すると、新しい SecurityPolicy オブジェクトの作成、または既存の SecurityPolicy オブジェクトの取得、変更、および保存ができます。また、以下の操作を行うこともできます。
- 新しい SecurityTemplate オブジェクトを SecurityPolicy オブジェクトに追加する。
- 既存の SecurityTemplate オブジェクトを SecurityPolicy オブジェクトから削除する。
- SecurityPolicy オブジェクトに含まれている SecurityTemplate オブジェクトを変更する。
既存の SecurityPolicy オブジェクトの変更内容は、そのポリシーを参照するオブジェクトに伝搬されません。
SecurityPolicy オブジェクトをインスタンス化する方法については、参照ヘルプの SecurityPolicy インターフェースの説明を参照してください。
セキュリティー・ポリシーの割り当て
SecurityPolicy オブジェクトを Document、CustomObject、または Folder オブジェクトに関連付けるには、このオブジェクトの SecurityPolicy プロパティーを設定します。このオブジェクトを作成するときは、最大 1 つのセキュリティー・ポリシーを割り当てることができます。クラス定義または単一のオブジェクト・インスタンスでは、複数のセキュリティー・ポリシーは許可されません。新しいオブジェクトの作成時にセキュリティー・ポリシーを割り当てない場合は、クラスの SecurityPolicy プロパティーの説明内にデフォルトとして指定された値がオブジェクト・インスタンスにコピーされます (デフォルト値が指定された場合)。セキュリティー・ポリシーが関連付けられているクラスのサブクラスが作成されると、新しいサブクラスはセキュリティー・ポリシーをその親クラスと共有します。
バージョン管理可能なオブジェクトのバージョン状態が変更されると、その権限は、セキュリティー・ポリシーに基づいて変更されます。バージョン管理可能なオブジェクトにセキュリティー・ポリシーが関連付けられていない場合は、そのバージョン状態が変更しても、権限は変更されないままになります。Document オブジェクトの SecurityPolicy プロパティーを最初に設定した場合、または別のセキュリティー・ポリシーを参照するようにこのプロパティーを変更した場合は、バージョン・シリーズのうち、ドキュメントの現在 (最新) のバージョンに新しいポリシーが適用されます。
Document、CustomObject、または Folder オブジェクトのクラスを変更したときも、オブジェクトのセキュリティー・ポリシーが変更される場合があります。オブジェクトの SecurityPolicy プロパティーの値は、その他のプロパティーの場合と同じルールに従って変更されます。詳細については、changeClass メソッドの参照ヘルプを参照してください。
セキュリティー・ポリシーの除去
オブジェクトからのセキュリティー・ポリシーの除去、またはオブジェクト・ストアからのセキュリティー・ポリシー・オブジェクトの除去が可能です。
オブジェクトからセキュリティー・ポリシーを除去するには、オブジェクトの SecurityPolicy プロパティーに null を設定します。これにより、セキュリティー・ポリシーのテンプレートから継承されたすべての権限がオブジェクトから除去されます。
適切な権限を取得すると、オブジェクト・ストアからセキュリティー・ポリシーを削除できます。これを行った場合は、SecurityPolicy オブジェクトと、それに含まれているすべての SecurityTemplate オブジェクトが除去されます。使用中の SecurityPolicy オブジェクトは削除できません。SecurityPolicy オブジェクトは、このオブジェクトに対する未解決の参照がある場合は、使用中であると見なされます。未解決の参照が含まれるのは、それがクラスのデフォルト値として識別された場合、または Document、CustomObject、または Folder の少なくとも一つのオブジェクトの SecurityPolicy プロパティーに、削除する SecurityPolicy オブジェクトが設定されるときです。Document、CustomObject、または Folder オブジェクトで以下のいずれかのイベントが発生した場合、関連する SecurityPolicy オブジェクトは、使用中であるとは見なされず、削除することができます。
- オブジェクトの SecurityPolicy プロパティーが、別の SecurityPolicy オブジェクトを参照するように変更された。
- オブジェクトの SecurityPolicy プロパティーに null が設定された。
- オブジェクト自身が削除された。
SecurityTemplate オブジェクト
SecurityTemplate オブジェクトは、従属的に永続可能なオブジェクトであり、オブジェクトに適用する権限が含まれます。このオブジェクトのインスタンスは、親である SecurityPolicy オブジェクトから独立して作成または永続化することはできません (新しい SecurityTemplate オブジェクトを作成する方法、または既存の SecurityTemplate オブジェクトを取得する方法については、リファレンス・ヘルプの VersioningSecurityTemplate または ApplicationSecurityTemplate インターフェースの説明を参照してください)。SecurityTemplate オブジェクトのメソッドを使用して、そのプロパティーと権限を設定してから、それを SecurityPolicy オブジェクトに追加します。SecurityPolicy オブジェクトの SecurityTemplates プロパティーは、ポリシーに含まれているテンプレートを反映しています。
SecurityTemplate オブジェクトが表す権限の説明は、このオブジェクトの TemplatePermissionDescriptions プロパティーの値を取得することにより得られます。このプロパティーから、テンプレートの AccessPermissionDescription オブジェクトを確認できます。これらの各オブジェクトは、アクセス権またはレベルの説明情報を提供します。この情報を使用して、ユーザー・インターフェースのセキュリティー編集ダイアログを設定できます。また、この情報は、権限のアクセス・マスク、権限タイプ、および表示名から構成されます。
SecurityTemplate オブジェクトは、アプリケーション・セキュリティー・テンプレート、またはバージョン管理セキュリティー・テンプレートを表すことができます。この 2 つのタイプは、同じオブジェクト・タイプを持ちますが、クラス ID (GUID) および使用法によって区別されます。これらのセキュリティー・テンプレート・タイプのクラス ID は、APPLICATION_SECURITY_TEMPLATE および VERSIONING_SECURITY_TEMPLATE という 2 つの定数で定義されます (参照ヘルプの FileNet.Api.Constants 名前空間または filenet.com.api.constants パッケージを参照してください)。
アプリケーション・セキュリティー・テンプレート
アプリケーション・セキュリティー・テンプレートは、オブジェクトの状態が変更するときに、アプリケーションによってオブジェクトのセキュリティーを管理する場合に使用します。アプリケーション・セキュリティー・テンプレートは、Document、CustomObject、または Folder オブジェクトに適用できる権限の事前定義のコレクションです。アプリケーション・セキュリティー・テンプレートは、自動的には適用されません。明示的にオブジェクトに適用する必要があります。
アプリケーション・セキュリティー・テンプレートの ApplyStateId プロパティーは、アプリケーションで定義された特定の状態にテンプレートを関連付けます。アプリケーションはオブジェクトがその状態に遷移したことを確認すると、ユーザー定義の GUID または事前定義のバージョン状態 GUID のいずれかを applyStateId パラメーターの値に指定して、オブジェクトの applySecurityTemplate メソッドを呼び出すことができます。このメソッドは、GUID を使用して、オブジェクトに関連付けられている SecurityPolicy オブジェクト内のテンプレートから、適用すべき適切なテンプレートを検索および選択します。
オブジェクトのセキュリティーを変更する権限 (AccessRight.WRITE_ACL) を所有するユーザーまたはグループは、SecurityPolicy オブジェクトに含まれている有効な SecurityTemplate オブジェクトをどれでも明示的に適用することにより、オブジェクトのセキュリティーを変更できます。
バージョン管理セキュリティー・テンプレート
バージョン管理セキュリティー・テンプレートは、Document オブジェクトのバージョン状態が変更されたときにオブジェクトの権限を自動的に更新するために排他的に使用されます。デフォルトのバージョン管理セキュリティー・テンプレートは、ドキュメント・バージョンが遷移できる状態 (処理中、リリース済み、予約、置換済み) ごとに用意されています。テンプレートの ApplyStateId プロパティーには、各状態に対応する、静的に定義された 4 つの GUID のいずれかの値が含まれています。GUID は、以下のように、VersionStatusId クラスの定数として定義されています。
- IN_PROCESS (処理中)
- RELEASED (リリース済み)
- RESERVATION (予約)
- SUPERSEDED (置換済み)
バージョン管理可能なオブジェクトの状態が変更されると、変更された状態に対応するテンプレートが SecurityPolicy オブジェクトのテンプレートから検索され、自動的にオブジェクトに適用されます。
例えば、Document オブジェクトのバージョン状態が処理中からリリース済みに変更されると、関連付けられた SecurityPolicy オブジェクトで、ApplyStateId プロパティーに VersionStatusId.RELEASED が設定されたバージョン管理可能なセキュリティー・テンプレートが検索され、そのテンプレートで定義された権限が自動的にオブジェクトに適用されます。バージョン管理可能なオブジェクトにセキュリティー・テンプレートが既に適用された場合は、自動的に適用されたバージョン管理テンプレートの権限によって、既に適用された権限が置換されます。
オブジェクトのセキュリティーを変更する権限 (AccessRight.WRITE_ACL) を所有するユーザーまたはグループは、SecurityPolicy オブジェクトに含まれている有効な SecurityTemplate オブジェクトをどれでも明示的に適用することにより、オブジェクトのセキュリティーを変更できます。
テンプレートの有効化および無効化
SecurityPolicy オブジェクトのテンプレートは、必要に応じて個々に無効にすることができます。テンプレートを無効にすると、その IsEnabled プロパティーに false が設定されます。無効にしたテンプレートは、その SecurityPolicy オブジェクト・コンテナーの一部として残りますが、オブジェクトに適用することはできません。セキュリティー・ポリシーを構成するセキュリティー・テンプレートをテストまたは開発するときは、テンプレートの無効化が役立ちます。
以下の状況では、該当するタイプの有効なテンプレートがオブジェクトに適用されます。
- デフォルトのセキュリティー・ポリシーを持つクラスからオブジェクト・インスタンスを作成するとき (自動)。
- バージョン管理可能なオブジェクトのバージョン状態が変更されたとき (自動)。
- オブジェクトの applySecurityTemplate メソッドを明示的に呼び出したとき。
- オブジェクトの changeClass メソッドを明示的に呼び出したとき。
セキュリティー・テンプレートの適用
バージョン管理可能オブジェクトの SecurityPolicy プロパティーを最初に設定するとき、または別の SecurityPolicy オブジェクトを参照するように変更するときは、ドキュメントの現在のバージョン状況に対応するテンプレートが SecurityPolicy オブジェクトで検索され、そのテンプレートが適用されます (すなわち、テンプレートで定義された権限がオブジェクトに割り当てられます)。
アプリケーションは、Document、CustomObject、または Folder インターフェースの applySecurityTemplate メソッドを呼び出すことにより、オブジェクトの既存のセキュリティーを変更できます。このメソッドは、applyStateId パラメーターで指定された個々のセキュリティー・テンプレートをオブジェクトに適用します。このパラメーター値を使用して、メソッドは、ApplyStateId プロパティーがこのパラメーター値に対応した SecurityTemplate オブジェクトを検索します。
このメソッドは、テンプレートを特定すると、そのテンプレートをオブジェクトに適用します (すなわち、テンプレートに定義された権限がオブジェクトに割り当てられます)。テンプレートからの権限は、以下の順序でオブジェクトに適用されます。
- オブジェクトのセキュリティー・ポリシーから継承された古い権限が削除されます。
- 関連する SecurityPolicy オブジェクトの PreserveDirectPermissions プロパティーを false に設定した場合、メソッドは継承されていない権限 (すなわち、オブジェクトに直接設定された権限) を削除し、継承された権限のみを維持します。true に設定した場合、メソッドは継承されていない (直接設定された) 権限を維持します。
- オブジェクトのセキュリティーの親から継承された既存の権限、および継承されていない既存のすべての権限に、SecurityTemplate からの新しい権限が追加されます。