セキュリティ(アクセス権)に関する情報の共有

リファレンス情報をリポジトリ間で共有する場合に、セキュリティ(アクセス権)に関するテーブルを共有する場合には注意が必要です。以下の点に基づいて検討する必要があります。

それぞれの利用者を認証する方法。外部のシングルサインオン (SSO) の仕組みを利用するか、Enterprise Architect独自のユーザーIDとパスワードを利用するか
全てのリポジトリで同じ情報を共有するのかどうか
全てのリポジトリ間でユーザーのパスワードを同期するのかどうか
全てのリポジトリで、それぞれのユーザーのアクセス権は同一で良いのか

セキュリティ機能(アクセス権)に関するテーブルには、2つのグループがあります。1つはユーザーとグループの定義、もう1つはアクセス権に関する定義です。両方を共有することもできますし、どちらかのみを共有することもできます。以下の2つのシナリオが考えられます。

シナリオ 1.

全てのリポジトリには同じユーザーが登録され、アクセス権もリポジトリによらず共通とします。ユーザーとグループの定義に関するテーブルとアクセス権定義に関するテーブルの両方を共有します。ユーザーの一覧やアクセス権は、中心となるリポジトリで管理します。

シナリオ 2.

全てのリポジトリには同じユーザーが登録されますが、アクセス権はリポジトリにより異なるように設定します。ユーザーとグループの定義に関するテーブルのみを共有します。ユーザーの一覧は、中心となるリポジトリで管理しますが、アクセス権は個々のリポジトリで管理します。

どちらのシナリオの場合も、ユーザーのパスワードは個々のリポジトリで管理されます。このユーザーのパスワードの管理を個々で行うことを避けるためには、SSOを利用するか、Proクラウドサーバを利用し、全体として認証を行うかのいずれかとなります。

SSOでの認証

SSOでの認証を行う場合には、Enterprise Architectは入力されたユーザー情報が正しいかどうかの判断は行いません。OpenIDやWindows NTLMがその責を負うことになります。判断した結果がEnterprise Architectに通知され、Enterprise Architectはその通知を正しいものとして受け入れます。その後、認証に利用されたユーザーIDの情報を利用し、利用可能な機能を決定します。それぞれのリポジトリには、有効なユーザーIDの一覧が必要です。ただし、ユーザーIDの情報を同期している場合には、中心となるリポジトリで管理します。

個別認証と全体認証の比較

Proクラウドサーバで定義したポートを利用して通信し、認証をProクラウドサーバで行うことも可能です。入力されたユーザーIDとパスワードはProクラウドサーバに渡されます。その後、認証に利用されたユーザーIDの情報を利用し、利用可能な機能を決定します。この方法の場合には、それぞれのリポジトリに個別にユーザー情報などを定義し保持することができます。しかし、ユーザー情報に変更がある場合には、関係する全てのリポジトリを更新する必要があります。

この方法の場合でも、指定したリファレンス情報のみを中心となるリポジトリと共有し、必要な内容のみを個別に管理することができます。