カタログでは決して分からないID管理製品の選択基準：今、見直されるアイデンティティ管理（1/3 ページ）

現在市場に出回っているID管理製品は、大まかに情報を格納するリポジトリのタイプによって分けられる。ID管理データの参照元として、ディレクトリとデータベースのどちらが良いのか。また、ID管理とSSO（シングルサインオン）のどちらを先に導入すべきだろうか。

[�ﾔ嶋秀規、岡本 孝，ITmedia]

本記事の関連コンテンツは、オンライン・ムック「今、見直されるアイデンティティ管理」でご覧になれます。

�ﾔ嶋（ぬてじま）秀規、岡本 孝（アクシオ）

　前回は技術面からアイデンティティ管理（IDM）製品の機能を解説したが、今回は現在市場に出回っているIDM製品をタイプ別に紹介する。また、IDMとともにID統合管理基盤の構成要素となるアクセス管理、特にSSOとIDMとの関係について解説する。

連携タイプによるIDM製品の分類

　前回紹介したように、IDM製品によるアカウント連携の形態には、次の3つの方法がある。

アカウント連携の形態

連携方法	説明
プロトコルベース	LDAPなどの標準的なプロトコルや連携先アプリケーションのコマンド発行により連携する
APIベース	Notesのような独自の考えでユーザー情報を保持するシステムに対してAPIを利用して連携する
ファイルベース	ユーザー情報をCSV形式などのファイルを利用して連携する

　管理対象システムのエージェントソフトの有無により、「エージェント型」または「エージェントレス型」としてIDM製品を分類している場合もあるようだが、実際には各製品で「APIベース」と「プロトコルベース」の両方のインタフェースを用意している場合が多く、IDM製品自体をエージェントの有無により分類することは難しい。例えば、一般的にエージェント型と分類されているノベルの「Novell Identity Manager」でも、ADなどと連携する場合には専用ソフトが必要となるが、標準的なLDAPドライバなどは用意されており、エージェントは不要となる。

　また、専用ドライバが用意されていないレガシーアプリケーションなどでは、CSVファイルなどで連携をとる「ファイルベース」のプロビジョニングが一般的だ。このファイルベースタイプでは、IDM管理コアと管理対象システム間は疎結合となり、IDMコア側で管理対象サーバを直接的に管理することができない。このためか、サン・マイクロシステムズの「Sun Java System Identity Manager」などではこのファイルベースでの連携は意識されておらず、カスタマイズにより対応する形となっている。

IDMコアとしてのディレクトリとDB

　IDM製品はIDMとしての情報格納リポジトリ（IDMコア）がNovell Identity Managerや「Microsoft Identity Integration Server 2003」のようなディレクトリベースであるか、Sun Java System Identity Managerや「Oracle Identity Access Management Suite」のようなDB（データベース）ベースかという基準によって分類される。

　IDMコアが連携起点であり、かつIDMコアにデータを参照しにくるシステムがある場合は、ディレクトリベースが優位となることが多い。しかし、参照を行うシステムがなければディレクトリとDBのどちらでもよくなる。また、最近のトレンドであるワークフロー処理などは、リポジトリに対するトランザクション処理が増えるため、DBの方が優位と考えられる。さらにディレクトリベースは、即時同期性に優れる半面、スケジュール同期を取るようなタイマー処理には不向きという短所もあるため、ディレクトリとDBのどちらが良いかは一概にはいえない。つまり、目的に合った製品を選定すべき、ということである。