プロビジョニングインターフェイスの濫用
この記事は https://docs.evolveum.com/iam/myths/provisioning-interface-abuse/ の翻訳です。
私たちには、この輝かしい万能のアイデンティティ管理システムがあります。 それには、すべてのユーザーに関する情報をリアルタイムで提供できる、とても優れたインターフェイスがあります。 新しいアプリケーションをすべてこのインターフェイスに接続すれば、認証し、ユーザープロファイルを読み取れるようになります。 これは elegant で、architecturally clean で、大量の作業を節約できます。
しかし一般的な場合、それは解決する問題よりも多くの問題を生みます。
プロビジョニングインターフェイス
重要な IDM システムには、IDM システムに保存されたデータに関する情報へアクセスするためのリモートインターフェイスがあります。 これは典型的にはユーザーに関する情報です。 多くの IDM システムは、IDM システムの背後にあるリソースから取得したアカウントに関する情報も公開します。 そのため IDM システムは、本質的には仮想ディレクトリとして機能できます。 これは統合の方法として非常に魅力的に見えるかもしれません。 結局のところ、非常に便利な「何でもできるインターフェイス」ではないでしょうか。
しかし、そこには代償があります。 IDM システムは複雑な存在です。 多くの対応付け、データ変換機構、ポリシーを含んでいます。 インターフェイスが適切に使われない場合、このすべてのロジックによって利用コストが非常に高くなります。
通常、性能が低下します。 IDM システムは性能を最優先として作られていません。 単一のアカウントが1秒でプロビジョニングされるか0.01秒でプロビジョニングされるかは、通常は重要ではありません。 しかし、10000個のアカウントをそれぞれ1秒で取得するか0.01秒で取得するかは非常に重要です。 プロビジョニングインターフェイスは高スループット用に作られておらず、通常そのように使うべきではありません。
可用性も低下する可能性があります。 IDM システムはミッションクリティカルとは見なされていないため、通常は大規模な HA クラスタリング向けには作られていません。 また、多くの IDM システムは「仮想アイデンティティ」モデルに基づいており、オフラインリソースをうまく扱えないため、プロビジョニングシステムが提供するデータが常に完全であるとは限りません。
簡単に言えば、プロビジョニングインターフェイスの目的はアイデンティティを 管理 することであり、多数のアプリケーションにアイデンティティデータを公開することではありません。 プロビジョニングインターフェイスの想定クライアントは、ユーザープロファイルを読み取りたい一般的なアプリケーション ではありません。 想定クライアントは、監視システム、セキュリティ分析システム、セルフサービスシステムなどです。 これらは特殊目的のシステムであり、2つの共通点があります。多くのシステムから集約されたデータを必要とし、比較的少数の複雑な申請を行うことです。 大量の単純な申請は、IDM システムインターフェイスが作られている用途ではありません。
これらは IDM システムの理論上の制限ではありません。 実際、この目的に使えるスケーラブル、可用、信頼できる IDM システムを実装することは十分可能です。 しかし、それは高価です。 非常に高価です。 非常に適切なエラー処理、強力な キャッシュ、性能チューニング などが必要です。 そして多くの IDM ベンダーは、経済的な観点からあまり意味がないため、その方向には進みません。
インターフェイスの適切な利用
このアプローチが部分的に実現可能になる方法が1つあります。IDM システムがローカルに保存しているデータだけを query することです。 これは通常、「アカウント」データではなく「ユーザー」データだけを query することを意味します。 「ユーザー」データは信頼できる部分です。 適切な IDM システムはこのデータを自身のデータベースに保存し、必要に応じて「アカウント」と同期します。 これらのデータはローカルに保存され、標準のデータモデルを使い、通常は 後処理 に複雑なロジックを必要としません。 したがって、そのようなデータの読み取りは比較的安価です。 状況によっては、これらのデータを効率的に読み取ることが可能かもしれません。 しかし、限界を超えないように細心の注意が必要です。
ディレクトリサービスと組み合わせる
IDM ソリューションには、はるかによい方法があります。それぞれのツールを設計されたとおりに使うことです。 IDM システムは柔軟性と複雑なロジックを扱うために設計されています。 性能のために設計されているわけではありません。 一方でディレクトリサービスは、特に性能と拡張性のために設計されています。 したがって、この2つのシステムを組み合わせ、それぞれの利点を強調しましょう。
この場合、IDM システムは最も得意なこと、すなわちデータの同期を行います。 ソースシステムからデータを取り込み、必要に応じて変換し、ディレクトリサービス（LDAP）へ公開します。 データは、アプリケーションがすぐに使える形で公開されます。 IDM システムはまた、データが十分に新鮮であることを保証します。 データを継続的に維持します。
ディレクトリサービスは巨大なデータベースにすぎません。 単純であるため、優れた性能を持ちます。 重いロジックはなく、データはディレクトリサービスに公開される前に IDM システムによってすでに 前処理 されています。 ディレクトリサービスは massive 拡張性のためにも設計されています。 そのため、ほぼ無制限の負荷を受けられます。 LDAP プロトコルには部分的に標準化されたデータモデルもあり、多くのアプリケーションが LDAP と seamless に統合できる可能性があります。
実際、この場合のディレクトリサーバーは、IDM システムからのデータを保持する巨大でスケーラブルな高性能キャッシュにすぎません。
この構成は通常、ソリューション全体の品質を大きく高めます。性能を改善し、標準化された LDAP スキーマによってデータモデルを開き、ほぼ無制限で安価な拡張性を可能にします。 ディレクトリサービスの追加コストは通常ごくわずかです。 この場合、ディレクトリサーバーに特別な機能は必要ありません。 そのため、既存のほぼすべてのディレクトリサービスを使えます（例: Active Directory）。 また、優れたオープンソースディレクトリサーバーの代替もいくつかあります。
アクセス管理
ディレクトリサービスは優れた技術です。 しかし、すべての技術と同様に、これにも限界があります。 したがって、ソリューションにもう1つ構成要素を追加することを検討する価値があります。それがアクセス管理です。
アクセス管理システムは通常、ディレクトリサービスを back-end として使うため、同様の性能と拡張性の特性を持ちます。 アクセス管理システムは、認証、セッション管理、認可などにもはるかに適しています。 これにより、かなり完全なソリューション が形成されます。