この特集のトップページへ
＞
Chapter 4：データストア層の構築
4.3 COM＋のセキュリティ機構
これまでに説明したように，COM＋アプリケーションを登録すること自体は，さほど難しいことではない。ただし，List 4-1とList 4-2で実装したCOMコンポーネントは，COM＋の機能をまったく使っていないので，その動作はCOM＋アプリケーションとして登録してもしなくても変わらない。
しかし，COM＋アプリケーションとして登録すると，プログラム側でCOM＋について特に何も考えなくても，セキュリティ機能とリモート呼び出し機能を使用できるようになる。
まずは，COM＋のセキュリティ機構から説明しよう。COM＋には，実際のユーザー名と仮想的なユーザー名とをマッピングする機能が提供されている。この機能を用いてユーザー名をマッピングすることで，複数のユーザーに対してCOMコンポーネントの利用権限を与えることができるようになっている。
4.3.1 ロール
COM＋では，権限の設定にロール（Role：役割）という仕組みが用いられる。ロールとは，仮想的なユーザー情報のことであり，COM＋では，ロールに対してセキュリティを設定することになる。つまり，ドメイン（WindowsドメインのほかActive Directoryドメインを含む）のユーザーアカウントに対して直接の権限を与えるのではなく，ロールに対して権限を割り当てるのである（Fig.4-24）。直接ドメインのユーザーアカウントに権限を割り当てるのではなく，ロールという抽象概念に権限を割り当てることにより，サーバーの環境やユーザーの登録状況といった実環境に依存することなく，柔軟性の高いビジネスロジックを構築できるようになる。
Fig.4-24 ロール
詳しくは次章で説明するが，「どのロールのユーザーによってメソッドが呼び出されたのか」あるいは「どのロールのユーザーによってプロパティが参照されたのか」ということは，COMコンポーネント側から知ることができる。そのため，たとえば「clerkというロールに属するユーザーからCOMコンポーネントが呼び出された場合は1000万円までの額しか扱えないのに対して，managerというロールに属するユーザーからCOMコンポーネントが呼び出された場合は1000万円を超える額も扱える」といった制御を，プログラム側で設定することもできる。
プログラム側では，直接ユーザーアカウントを扱うのではなく，ロールで抽象化してユーザーを扱うことができるため，サーバー環境に左右されずに開発できるというメリットがある。たとえば，上述したようにclerkとmanagerという2つのロールを使って，ユーザーによる利用をプログラム側で制限したとしよう。この場合，サーバーの管理者がコンポーネント管理ツールを適切に使ってclerkロールとmanagerロールに実際のユーザーを割り当てることで，「どのユーザーにどの機能の利用を許可するか」を管理サイドで決定できるようになる。当然ながら，人事異動や入退社などに伴ってユーザーの構成が変わったり，サーバーの環境が変わったりしても，ロールを適切に設定し直せば，プログラム側の変更は一切必要ない。
 |
Chapter 4 6/16 |  |
