例えば、Tomは、SystemA CR で作業するときには Team Leader 権限 (提出者、割り当て者、レビューアー) を備えているが、SystemB CR では Contributor 権限 (提出者) しか備えていないものとします。 作業しているプロジェクトに応じて、Tom は異なる権限を備えることになります。 CR が存在するデータベースは関係ありません。重要なのは、プロジェクト・メンバーシップです。 プロジェクトはコンテキストおよび権限を設定し、これを可能にします。
ユーザーは多くの場合、組織内で異なるロールを持っています。 前の例では、Tom はあるプロジェクトで Team Leader であるが、別のプロジェクトでは単なる Contributor でした。 従来のデータベース・セキュリティーは、1 つのデータベース当たり 1 つの権限セットに制限されます。 プロジェクトを別々のデータベースに分離して、適切なアクセス・レベルを確保する必要があります。 さもないと、より制限されたアクセスが必要なプロジェクトに対して不当な権限を付与しなければなりません。 どちらのソリューションも最適ではありません。
ユーザー管理は複数の製品で分割されます。 アカウントは、IBM Rational Directory Server で管理されますが、権限は Rational Change で割り当てられます。 さらに、ユーザーにフル管理アクセスを付与せずにユーザー管理を分散する手段はありません。
論理的に関係した権限をロールにグループ化することで、管理が単純化します。
Rational Change ユーザーの追加が、Rational Directory Server でユーザーに適切なグループを割り当てるのと同じくらい簡単になります。 ロールおよび権限は、Rational Change でプロジェクト定義を使用して自動的に付与されます。
各プロジェクトの管理を適切なユーザーに委任できます。
プロジェクト・セキュリティーによってもたらされるユーザー管理の簡単さは、スタンドアロン・モードよりセントラル・モードで、より十分に実感できます。 Rational Synergy を使用して ccm users で Rational Change ユーザーを定義する必要がありません。 データベース・アクセスは、Rational Change 権限によって全面的に制御されます。 スタンドアロン・モードでは、ユーザーは CR にアクセスするにはそのデータベースに定義されている必要があります (データベースが特別に指定されている場合を除く)。
プロジェクト・セキュリティーは 変更依頼プロセスの管理 に定義されたセキュリティー・ルールおよび権限と連携します (ライフサイクル・セキュリティー)。 これらのルールは遷移、および個別属性の修正方法を制御します。これに対し、 読み取り/書き込みセキュリティー (アクセス制御リスト (ACL) を使用) は、CR 全体が表示されるかどうか、修正可能かどうかを制御します。 読み取り/書き込みセキュリティーで CR を修正できる場合は、その遷移および個別属性は、ライフサイクル・セキュリティーおよびプロジェクト・セキュリティーによって制御されます。
属性を修正でき、遷移が許可されるようにするために、CR プロセスで権限が使用されます。 ロールは、権限セットです。
任意の数のプロジェクトを定義できます。また、サブプロジェクトの作成も可能です。 サブプロジェクトは既存のプロジェクトから派生されますが、より狭いスコープを持ちます。