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

<< 目次を表示 >>

ページ位置:  プロジェクトの作成と管理 > リファレンス情報 > リファレンス情報の入出力 > リファレンス情報をリポジトリ間で共有 >

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

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

 

 

 

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

 

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

 

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

 

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

 

 

SSOでの認証

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

 

 

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

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

 

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