sidebarIdM実験室いろんなアイデンティティ管理系製品やサービスの実験の記録をしていきます。後は、関連するニュースなどを徒然と。2009年5月1日金曜日オブジェクト保持構造における各社アプローチ一般的な業務アプリケーションと比べてIdM製品のデータの持ち方(構造)で一番特徴的なのが「データを縦に持つ」という点だと思います。123-456-789という様にデータを横に並べて1レコードが1エントリという構造にします。これは視覚的にもわかりやすいですし、昔からアプリケーションはレコード単位で処理を行うことが容易な形でライブラリなどが作られてきたためです。このデータ構造の弱点としてレコードへの属性(列)の追加/削除/変更という作業が発生した場合、アプリケーションそのものへの影響がとても大きい、という点でした。そのため、設計段階での仕様固めが非常に大切でした。IdMやディレクトリ分野においては割と気軽に属性の追廃改が行われがちですし、製品としてあらかじめハンドリング可能な属性を固定的に決めてしまうことはできません。IDライフサイクル管理という意味でのIdMに関しては接続先システムの増減により必要となる属性が変化するのは日常的な話と言えるでしょう。その点、LDAPのデータ構造は理にかなっていて、objectClassの追加により割と自由に属性を持つことができます。ゆえにNovellやExgenなどのIdM製品はレポジトリにLDAPを選択しているのだと思います。ビジネスロジックを実装する上でLDAPだと限界があるのも確かなので、RDBにこだわるベンダもいて、インテックの結人/束人やSAP(旧MaXware)はパフォーマンスに問題が出るのを承知で無理やり縦構造のテーブルを作ったりしています。123-456-789マイクロソフトのFIM(ILM)に関してMetaverseの構造は別の機会に解説するとして、FIMが新しく利用するようになったWebサービスにおいても同様の思想が継承されており、WS-TransferでハンドリングされるResourceも以下のような拡張がされています。McNealy</rm:displayName></AttributeValue><AttributeType>telephoneNumber</AttributeType><AttributeValue><rm:telephoneNumber>123-456-789</rm:telephoneNumber></AttributeValue></PartialAttribute>このように各社さまざまなアプローチで製品としてはどんなデータが入るかわからない器の実装をしているようです。最近はなかなか時間がとれなくて実験らしいことができていませんので、そろそろ久しぶりにFIMを触ってみようかと思います。Webサービス周りのアーキテクチャの整理もまだできていないので、そのあたりの整理もかねて。よりアクセス解析を行っています。品質向上のみを目的とし、個人の特定などを目的とはしておりません。中で公開されることはあります。問い合わせ不明点等は管理人までご連絡ください。本プライバシーポリシーは予告なく変更/削除することがあります。プライバシーに関するトラブルについては一切の責任を負いかねますのでご了承ください。