プロビジョニング標準
この記事は https://docs.evolveum.com/iam/iga/identity-provisioning/provisioning-standards/ の翻訳です。
アイデンティティプロビジョニング は アイデンティティガバナンスおよび管理（IGA） の一分野であり、対象システムにユーザーアカウント、グループ、その他のオブジェクトを作成する技術的側面を扱います。 これは、多数のアイデンティティストアを同期し、統合し、維持するための技術です。 アイデンティティプロビジョニングは、ユーザーライフサイクル全体にわたる技術的作業を扱います。新しい従業員が採用されたとき、責任範囲が変わったとき、または会社を離れるとき（デプロビジョニング）です。
ほぼすべてのアプリケーションとシステムは、ユーザー、エンタイトルメント、アクセス管理のためにインターフェイス（API）を公開しています。 伝統的に、そのような provisioning interfaces は非常に異種混在でした。 各アプリケーションは独自のインターフェイスの流儀を実装し、それぞれ独自のデータモデル、操作、固有の詳細を持っていました。 当然ながら、異種混在のインターフェイスは統合を 非常に 難しくします。
標準化の歴史
アイデンティティプロビジョニングインターフェイスの異種混在は、かなり望ましくありません。 当然のことながら、インターフェイスを揃え、プロビジョニング標準を導入しようとする試みがありました。 最初の試みは1990年代後半から2000年代初頭にさかのぼりますが、ほとんど注目されず、一般には歴史の中に埋もれています。 おそらくこの時代から残った唯一の遺産は、LDAP とその XML ベースの派生である DSML をプロビジョニングインターフェイスの形として使おうとした試みです。 アイデンティティ分野には、LDAP を本来提供するはずのなかった機能に濫用する長い伝統がありますが、このアプローチは今回失敗しました。 LDAP をプロビジョニングインターフェイスに無理やり押し込むことはできません。
その後、2000年代にはサービスプロビジョニング Markup 言語（SPML）の2つのバージョンが相次いで登場しました。 この2つの SPML バージョンは非常に異なっており、標準化されたアイデンティティプロビジョニングに対して2つの異なるアプローチを試みました。 しかし、両バージョンには共通点が1つありました。どちらも見事に失敗し、実質的な価値をもたらさなかったことです。
2010年代には、単純クラウドアイデンティティ管理（SCIM）という形で、標準化されたプロビジョニングインターフェイスへの独自の取り組みが登場しました。 SCIM の初期リリースは SPML の足跡をたどったため、SCIM 1.0 があまり成功しなかったのは驚くことではありません。 幸いなことに、SCIM 1.0 はすぐに SCIM 2.0 に置き換えられ、ようやくある程度の支持を得ました。 SCIM は最終的に System for Cross-domain Identity Management へ改名されましたが、元の名前の方がはるかに適切でした。
SCIM 2.0
System for Cross-domain Identity Management（SCIM）は、アイデンティティプロビジョニングのための RESTful サービスに関する IETF 仕様（RFC7642）です。 SCIM 仕様化は、ユーザーとグループに関するデータを作成、read、更新、削除（いわゆる CRUD）するサービスを記述しています。 SCIM サービスは、独自データベースを持つアプリケーション、クラウドサービスプロバイダーなど、アイデンティティデータを保存するシステムによって提供されます。 SCIM サービスは、IGA プラットフォームのようにアイデンティティを管理する必要があるソフトウェアシステムから呼び出されます。
全体として、SCIM 2.0 仕様化はかなり曖昧です。 厳密なインターフェイス仕様というよりも、大まかなフレームワークを提供しています。 多くの問題のある部分があり、標準状態で 相互運用性を事実上台無しにしています。
SCIM 2.0 は相互運用性を保証できる仕様ではありませんが、一定の価値はあります。 SCIM 2.0 はプロビジョニングインターフェイスの統合を多少容易にします。 SCIM クライアントは個々の SCIM サービスごとにカスタマイズする必要がありますが、そのようなカスタマイズは完全に独自のインターフェイスに対するクライアントを実装するよりは簡単です。
SCIM 2.0 の実装が 標準状態で で相互運用できる可能性は非常に低いです。 しかし、すべての実装が共通の SCIM 仕様化に着想を得ているため、相互運用させるために必要な労力は多少減ります。 これが SCIM 2.0 の本当の価値です。 大きなものではありませんが、それでも何もないよりはましです。
コネクター
相互運用可能なアイデンティティプロビジョニングインターフェイスは、まだ存在しません。 それでも、IGA プラットフォームのアイデンティティプロビジョニング機構は動作しなければなりません。 実際、それは2000年代初頭から比較的うまく動作しています。
包括的な IGA プラットフォームはすべて、内部に共通のプロビジョニングインターフェイスを持っています。 このインターフェイスは、各プラットフォームで connectors、適応ers、integrations などと呼ばれるものをサポートするために使われます。 これらのインターフェイスはかなりうまく機能します。 しかし、欠点もあります。
第一に、インターフェイスは platform-specific です。 すべてのコネクターインターフェイスは特定の IGA プラットフォームに結びついており、コネクターは再利用できません。 例外は1つだけあります。ConnId コネクターフレームワーク です。 ConnId は、いくつかの IGA プラットフォームで使われているオープンソースアイデンティティコネクターフレームワークです。 しかし、それでも「標準」になるわけではありません。
第二に、コネクターインターフェイスは、単なる仕様として一般的なものよりもはるかに柔軟で動的です。 しかし、それはインターフェイスを 複雑 にもします。 柔軟性を支える大量のコードがあり、それによって複雑さが管理可能になっています。 コネクターの作成と保守は、今でも完全に簡単というわけではありません。 それでも実現可能であり、ほぼ 標準状態で の相互運用性を提供します。
結論
アイデンティティプロビジョニング標準は、見た目よりも はるかに 難しいものです。 数多くの試みにもかかわらず、私たちはまだ「標準」と呼べるものには到達していません。 少なくとも3回の失敗を経て、SCIM 2.0 は即座に失敗しなかった最初の試みです。 しかし、SCIM 2.0 も相互運用性の提供にはあまり成功していません。
今のところ、アイデンティティプロビジョニング相互運用性には、依然として包括的な IGA プラットフォームが必要です。 IGA プラットフォームが提供するコネクターフレームワークと強力なデータ対応付け機能が、相互運用性を提供し、自動化を可能にするために必要です。 これが予見可能な将来に変わるかどうかを予測するのは非常に困難です。 しかし、プロビジョニング標準の過去の実績と最新の反復を見る限り、あまり希望は持てません。
当面の間、IGA プラットフォームが最良の選択肢です。 それらはアイデンティティプロビジョニング統合だけでなく、はるかに多くのものを提供します。 ポリシー、自動化、アクセス制御モデル、コンプライアンス管理などが含まれます。 どのようなプロビジョニング標準の将来にかかわらず、IGA プラットフォームは必要です。