Skip to content

SCIM Troubles

この記事は https://docs.evolveum.com/iam/iga/identity-provisioning/scim-troubles/ の翻訳です。

What Is SCIM?

System for Cross-domain Identity Management (SCIM) は、アイデンティティプロビジョニングのための RESTful サービスに関する IETF 仕様化 (RFC7642) です。 SCIM 仕様化は、ユーザーとグループに関するデータを作成、read、更新、削除、別名 "CRUD" するサービスを describe しています。 SCIM サービスは、独自データベースを持つアプリケーションやクラウドサービスプロバイダーなど、アイデンティティデータをストアするシステムによって提供されます。 SCIM サービスはアイデンティティを管理する必要があるソフトウェアシステムによって呼び出されます。

汎用プロビジョニングインターフェイス

SCIM は、すべてのアプリケーションが使えるアイデンティティプロビジョニングの汎用インターフェイスを define するという noble 考え方の上に構築されています。 これは great 考え方に聞こえます。実際、考え方としてはそうです。 問題は、そのようなインターフェイスを実装することが見かけよりはるかに難しいことです。 この方法は 過去に何度も試され、SCIM と非常によく似た プロトコル仕様化の試み も含まれます。 そのような労力は過去に成功ful ではありませんでした。 実際、そのような attempt はしばしばシステムに additional 複雑性を introduce し、long run では維持管理悪夢につながります。 ほぼ20年にわたり、人々が同じ方法を繰り返し試しているのを見てきました。 結果は常に同じです。

これは非常に counter-intuitive に見えます。 インターフェイス を作成することは well-known で、通常は非常に useful な architectural パターン です。 そのようなベストプラクティスがアイデンティティプロビジョニングでは機能しないことが、どうしてあり得るのでしょうか。 Answer は簡単ではないため、いくつかの例で illustrate するのが最善でしょう。

相互運用性

SCIM はユーザー、より正確にはアカウントのための nice スキーマを specify します。 SCIM notation では、すべてのユーザーは次のように見えるべきです。

SCIM におけるユーザー表現の例（簡略版）

{
  "userName":"jdoe",
  "name":{
    "formatted": "John Doe, PhD.",
    "familyName": "Doe",
    "givenName": "John",
    "honorificSuffix": "PhD."
  },
  "emails":[
    {
      "value":"john.doe@example.com",
      "type":"work",
      "主な": true
    }
  ]
}

これは非常に nice と sane に見えます。 しかし、すべてのシステムが同じではありません。 ユーザー名前という一見単純な概念を見てみましょう。 一部のシステムでは名前が first 名前と last 名前などの構成要素に neatly separated されています。 他のシステムははるかに単純で、すべてを1つの複雑で整理されていない string に combine しています。

SCIM は名前 表現の variation を許可します。 システム A は次を return するかもしれません。

{
  "userName":"jdoe",
  "name":{
    "familyName": "Doe",
    "givenName": "John",
    "honorificSuffix": "PhD."
  },
  ...
}

一方、システム B は次を return するかもしれません。

{
  "userName":"jdoe",
  "name":{
    "formatted": "John Doe, PhD."
  },
  ...
}

ここまでは問題ありません。 しかし、システム A とシステム B の両方でアカウントを create したいときに trouble が起こります。 SCIM には、システム A が familyName と givenName を必要とし、システム B が formatted 名前を必要とすることを indicate する方法がありません。

システム B にとっては大きな問題ではないかもしれません。 SCIM サービス end点 は名前の両方の形式を accept できるほど smart かもしれません。構成要素からフルネームを形式するのは簡単だからです。 しかし、poor システム A は Hrabě Felix Teleke z Tölökö のような formatted 名前を受け取ったらどうすればよいのでしょうか。 どの部分が名で、どの部分が姓で、middle 名前はどこで、どの部分が honorific title なのでしょうか。 Formatted 名前だけを送るクライアントは、SCIM スキーマがこれを許可するため fully SCIM-compliant です。 サービス A も fully SCIM-compliant です。 それでも相互運用できません。 Correct behavior はクライアントに設定済みまたは hardcoded される必要があります。 これにより相互運用性の achieve はかなり困難になります。

これは本当の問題ではないと思うかもしれません。 実際、今日の一般的アイデンティティ管理実務を前提にすれば、それは正しいかもしれません。 人々は、新しいシステムとの統合が遅い と 痛ましいプロセスであることに慣れています。 しかし SCIM は today の必要性のためだけに作業するものではないはずでした。 SCIM は 改善 であるはずでした。 その点で、SCIM はかなり不足しています。

この particular 問題はユーザー名前に関してはそれほど悪くないかもしれません。 名前を正しく扱うには、いずれにせよユーザーとのやり取りが必要になります。 残念ながら、同じ問題は SCIM スキーマ全体に permeate しています。

新しいユーザーを作成するためにパスワードは 必要とd でしょうか。 パスワードをどう encode/hash すべきでしょうか。 ユーザー有効化 status はどうでしょうか。ユーザーは enabled か 無効化 か。 サービスは有効化機構をサポートしているのでしょうか。 Archived アカウントやその他アカウントライフサイクル状態を indicate する方法はあるのでしょうか。 有効化日、有効開始、有効終了 はどうでしょうか。 どの filter 運用者 がサポートされるのでしょうか。 Multi-valued 属性に複数価値を present できるのでしょうか。また valid な "種類" は何でしょうか。 Rename 操作はサポートされるのでしょうか。 これらは mediocre なアイデンティティ管理機構でさえ必要とする minimum です。 残念ながら、SCIM はこれら問題のどれにも answer を持っていません。

これらすべては相互運用性、あるいはその欠如に帰着します。 SCIM は SCIM server の実装をかなり easy にするよう obviously 設計されています。 これは責任をすべて SCIM クライアントに shift することで achieved されています。 SCIM クライアントは適切に機能するために、サービスに関する 帯域外の詳細を大量に知る必要があります。 Consequence は、実践的な SCIM クライアントの大多数が particular サービスと作業するよう developed され、そのサービス only と作業することです。 Other サービスに portable ではありません。 相互運用可能 ではありません。 これは標準プロトコルに期待するものではありませんよね。

アイデンティティ管理の標準スキーマ

SCIM の価値 proposition の1つは標準化されたアイデンティティスキーマのはじめにです。 しかし SCIM がそれを行う方法は 大量の問題を作成します。 標準化されたアイデンティティスキーマは良いことですよね。 どうして問題になるのでしょうか。

Common アイデンティティスキーマは原則としては良いものです。 問題は、コミュニティや導入ごとに何が common かについて異なる考え方を持っていることです。 たとえば LDAP コミュニティは アカウントを無効化 する方法についてまだ合意できていません。LDAP はほぼ30年存在しているにもかかわらずです。 LDAP には公式なグループ化機構が3〜4個あり、それに加えてほぼすべての LDAP サーバーが独自のものを持っています。標準なものには問題があるからです。 一般的スキーマに agree するのは本当に hard です。 それを standardize するのはさらに hard です。 これは SCIM author にも obviously clear だったのでしょう。SCIM 標準スキーマは very 曖昧 です。

さらに 既存ソフトウェアシステムの山 があります。 一部は inetOrgPerson や eduPerson スキーマを持つ LDAP based です。 これらは SCIM スキーマと strictly 互換性があるではありません。Multi-value LDAP cn を SCIM name で express する reasonable 方法がないからです。 もちろん、multiple 価値を持つ cn は非常に rare sight です。 しかしこれは、LDAP と SCIM の両方の標準に fully 準拠な bridge を作れないことを意味します。 Corner を cut しなければなりません。 さらに独自スキーマを持つシステムがあり、それらも SCIM-compatible ではありません。 SCIM-compliant インターフェイスを公開するには、さらに多くの corner を cut しなければなりません。 そのような compromise はそれぞれ fidelity の loss を意味します。 SCIM ではできないことが生じる、または SCIM 標準を bend するか dirty hack に resort する必要がある、ということです。 アイデンティティに関しては、one スキーマ does not ルール them all です。

アイデンティティ管理の dark history に少し脱線しましょう。 同様の問題は、2000年代に Sun Microsystems が作ったアイデンティティコネクターフレームワーク (ICF) にも存在しました。 ICF は人物の 名前 や address をどう present すべきかまで define しようとはしていませんでした。 ICF が mandated したのは、各アカウントが2つの識別子を持つことです。

  • pass:[__UID__] は 一意 で、可能であれば immutable であるべきです。 これは LDAP entryUUID やデータベース autoincrement column の価値と想像できます。 アカウントが作成されるシステムによって 生成される場合があります。
  • pass:[__NAME__] はアカウントが作成されるときにユーザーによって提供されます。 これは通常ユーザー名または login 名前です。

これは minimal で非常に reasonable な要件に聞こえるかもしれません。しかしそうではありません。 Minimal でも reasonable でもないことが分かります。 pass:[__UID__] をまったく持たないシステムがあります。 pass:[__NAME__] をまったく持たないシステムがあります。 pass:[__NAME__] が 一意 である必要のないシステムがあります。 アカウントを 一意ly 特定するために複数識別子の組み合わせが必要なシステムがあります。 pass:[__UID__] と pass:[__NAME__] の両方を使うものの、アカウントを 変更する識別子として pass:[__UID__] が 必要とd なシステムがあります。 両方を使うものの、変更する識別子として pass:[__NAME__] が 必要とd なシステムもあります。 選択肢と変種は非常に多く、しかもまだ単純識別子について話しているだけです。 これはアイデンティティ管理の最も基本的な部分です。 それ以外はすべてさらに hard になります。

アイデンティティコネクターフレームワークは10年以上前に死んだです。 しかしその労力を引き継ぐ ConnId プロジェクトがあります。 私たちは長年にわたり ConnId design とコードに多くの 改善 を加えてきました。 しかし、このような小さな hardcoded 識別子スキーマでさえ、常に私たちを悩ませました。 アイデンティティ管理インターフェイスの hardcoded スキーマは作業しません。 作業できません。

ちょっと待ってください。 midPoint には hardcoded アイデンティティスキーマがあります。 ほとんどすべてのアイデンティティ管理プラットフォームにはそのようなスキーマがあります。 では、アイデンティティ管理システムはどうして作業するのでしょうか。

簡単に言えば、アイデンティティ管理システムは system だから機能します。 紙に書かれただけの mere 仕様化ではありません。 コードがあります。それも 巨大な コードの山です。 MidPoint には純粋な development 作業だけで man-何十年 worth があり、それに テスト、文書、communication、管理オーバーヘッド、その他すべての労力が加わっています。 コードにより、midPoint は incompatible スキーマ間でデータを map できます。 MidPoint はまさにそれを行うよう設計されています。 MidPoint はスキーマがどのように見えるかを dynamically 発見できます。 MidPoint はそれらを wire できます。 MidPoint にはスキーマが進化したときに対応付けを迅速に変更するツールがあります。 MidPoint は missing または non-standard 機能を simulate できます。 MidPoint は標準違反に適応し、アイデンティティ playbook 内の dirty hack すべてを行えるほど柔軟です。 しかし pay すべき price があります。 SCIM ベースの統合ソリューションを開発するために何十人年も費やしたくはないでしょう。

長い話を short にすると、アイデンティティ管理 system で作業するものは、アイデンティティ管理 インターフェイス で作業するものと同じではありません。

SCIM は現在 second version であり、third revision についての talk があります。 SCIM の前には2つの SPML version があり、その前にも 少数のプロビジョニングプロトコルがありました。 それらの attempt はほぼ20年遡ります。 SCIM には learn できる previous failure が多数ありました。 したがって、SCIM にまだこれほど多くの課題が deeply embedded されていることは、かなり surprising です。

ビジネス面ではには、私たちはおそらく現在の SCIM の状態、hype などについて happy であるべきなのでしょう。 互換性のない SCIM end点 が多いということは、アイデンティティ管理システムへの strong 必要性があるということです。 MidPoint サブスクリプション を truck負荷で sell できます。 しかし エンジニアing 観点 からこれほど誤りなものについて、私たちは happy にはなれません。

もちろん、SCIM は改善されたできます。 SCIM は eventually 良いアイデンティティ管理インターフェイスに変換ed できるように見えます。 Future SCIM version は、サービスがクライアントに必要なすべての情報を公開する means を提供するかもしれません。 しかし、そこが universal アイデンティティプロビジョニングインターフェイス の考え方が本当に複雑になるところです。 サービス機能、認証情報種類 と 形式、有効化選択肢、エンタイトルメント scheme の組み合わせは plethora です。 Fully-compliant SCIM クライアントはそれらすべてをサポートし、正しい選択肢がどれかを dynamically 発見し、自身の機能を適応する必要があります。 これは実質的に SCIM クライアントを small アイデンティティプロビジョニングシステムに変えます。

課題、課題、さらに課題

SCIM には user と group という prefabricated 概念があります。 グループメンバーシップがグループの members 属性によって制御されることは、ほとんど信じがたいことです。 これは少なくとも1990年代まで遡る well-known 方法です。 この方法が特によく知られているのは、常にかなり problematic だからです。 導入の大半 には組織のほぼすべてのユーザーを含むグループがあります。 つまり、多数の価値を members 属性に持つ Group SCIM オブジェクトができます。 数千から数百万ユーザーを持つグループはまったく rare ではありません。 SCIM クライアントがそれほど多くの member を持つグループを 一覧表示するとどうなるか、SCIM response がどれほど長くなるかを想像してください。 members を除くすべてのグループ属性を申請する workaround があり、reasonable クライアントは常にそうしたいでしょう。 しかし members 属性はグループ修正には依然として使う必要があります。 つまり、クライアントとサービスの両方が性能課題を避けるために very carefully に実装されなければなりません。 グループメンバーシップ 関係 が reversed され、user の groups 属性が使われていれば、すべてははるかに easy だったでしょう。 あるいはもっと良く、グループ mechanics が well-defined エンタイトルメントまたはロール管理機構の特殊なケースにすぎなければよかったでしょう。 これはユーザーの entitlements と roles 属性につながります。これらは mentioned されていますが、本当には defined されていません。 明らかに、SCIM にはここで多くの改善余地があります。

SCIM を serious 業務に使いにくくする smaller 課題は多数あります。 パスワードに関する情報、たとえば hashed 価値を reveal せずに、ユーザーがパスワードを持っていることを indicate する良い方法がありません。 しかしこの機能はしばしば必要です。たとえばユーザーがまだパスワードを持っていない場合にのみパスワードを集合したい場合です。 ユーザー名は mandatory であり、サービス内で globally 一意 でなければなりません。 しかしユーザー名は 一意ness を ensure するためにサービスによって 生成される場合があります。 その場合、作成操作にはユーザー名が present しないかもしれず、これはユーザー名が 必要とd であるという事実と somehow conflict します。 ユーザー名の global 一意ness は multi-tenant システムにとっても問題になり得ます。 そのようなシステムはユーザー名に内部構造を introduce するなどの workaround を使う必要があります。 一部のシステムはユーザー名をまったく必要としないかもしれません。 SCIM はそのようなシステムに id をユーザー名として重複させることを強制しますが、これも アンチパターン のように見えます。

課題はさらにありますが、それらすべてを 列挙 する意味はおそらくありません。 Big picture はもうかなり clear でしょう。 これら課題は、今日多くのプロトコルが developed される方法によって 原因d されているのかもしれません。 多くのプロトコルは standardization プロセスの前ではなく、その during に developed されます。 したがって、diverse 現実世界のシナリオで使ってプロトコルを validate するための時間 と opportunity が十分にありません。 SCIM は明らかにこの premature standardization 問題に苦しんでいます。

Future Of SCIM

かつて SPML がありました。 今は死んだです。 次に SPML2 がありました。 それも死んだです。 XML は SPML failure の主な reason ではありません。 SCIM 1.0 が次に来て、数年残っただけで、すぐに置き換えられました。 SCIM 2.0 はここで本当に tough act を follow しています。

SCIM 2.0 は間違いなく SPML と SCIM 1.0 より 改善 です。 SCIM 2.0 は better です。 しかし、それは適切な問題ではありません。 Question は、SCIM 2.0 が good enough かどうかです。

SCIM 2.0 は、多くの failure の後に来た good 出発点 かもしれません。 しかし、それは start にすぎません。 Major 改善が必要です。 Cleaner、richer、more 動的でなければなりません。 それでも、そのようなものを得るには大きな price を払う必要があります。 新しい複雑性が生まれます。 大量の複雑性です。 したがって単純汎用 SCIM クライアントのことは忘れてください。 クライアントは単純か汎用のどちらかであり、両方ではありません。

Pragmatic Look At SCIM

ここまで述べたすべてにもかかわらず、SCIM 2.0 は still useful になり得ます。 Reasonably に使い、制約を aware し、expectation を正しく集合する必要があるだけです。 私たちの推奨は次のとおりです。

  • これから始めるなら、SCIM 2.0 から始めるのは良い考え方かもしれません。 すべてを reinvent するより、SCIM から始める方が良いです。特にアイデンティティ管理に慣れていない場合です。 アイデンティティ管理は見かけよりはるかに複雑です。 自分の方法でやろうとすると、SCIM よりはるかに悪いものに 行き着く可能性があります。 SCIM 2.0 は悪い 出発点 ではありません。
  • SCIM がすべての問題を solve するとは expect しないでください。 サービスが any SCIM クライアントから accessible になるとは expect しないでください。 そうはなりません。 SCIM に based できる特殊なクライアントが必要になります。 しかし、そのクライアントは自分で develop する必要があります。 クライアントが arbitrary SCIM サービスにアクセスできるとは expect しないでください。 できません。 新しいサービスごとにクライアントを適応しなければなりません。 実際、実践的な相互運用性は本当に low になると expect してください。 それでもゼロベースでサービスやクライアントを 構築するよりは、SCIM 2.0 を使う方が良いかもしれません。
  • Avoid できるなら SCIM グループは使わないでください。 SCIM がグループメンバーシップを扱う方法は よく知られたアンチパターンであり、遅かれ早かれ多くの問題を引き起こすことになります。 代わりに独自のエンタイトルメント機構を作成してください。
  • Pre-fabricated User 種類の使用も避けるのが良い考え方かもしれません。 User の fixed スキーマは目的に合わないかもしれません。 クライアントがどうせ LDAP に translate back するなら、LDAP eduPerson スキーマを SCIM User に translate する 点 はありません。 Scratch から独自の EduUser リソースを作成する方がずっと良いかもしれません。
  • 既存アイデンティティプロビジョニングインターフェイスを SCIM 2.0 に migrate する労力には、おそらく値しません。 アイデンティティプロビジョニングインターフェイスが本当に primitive でない限り、SCIM に必要なことをさせるのに苦労します。 大量の専用 SCIM 拡張を作成する必要があります。 Behavior を変更する必要があります。 おそらく最終的には SCIM 仕様化に violate することになります。 SCIM adoption の効果は、SCIM インターフェイスを見たことがある人々にとって API を理解しやすくなることです。 しかし彼らはいずれにせよ専用拡張を理解する必要があり、ほぼ確実に専用クライアントコードを書き込む必要があります。 その効果が特定のケースに値するかどうかは自分で判断しなければなりません。 Proper 考慮 をしてください。 "標準" だからという理由だけで blind に SCIM 2.0 を grab しないでください。

SCIM の制約をすべて aware しており、それでも必要性を satisfy するなら、SCIM adoption は効果をもたらすかもしれません。 制約を持つことは SCIM の主な問題ではありません。 すべての技術には制約があり、SCIM は多くの単純ソリューションに good fit になり得ます。 Real 問題は、SCIM について massively inflated expectation があることです。 アイデンティティ管理の経験が limited な多くの エンジニアは、SCIM を silver bullet と見ます。 そうではありません。 それは development の初期段階にある ordinary 技術にすぎません。

SCIM In MidPoint

MidPoint は非常に長い間 SCIM を使っていませんでした。 MidPoint は SCIM より古いです。 SCIM がまだ developed されていた頃、midPoint にはすでに rich API がありました。 MidPoint API は SCIM よりはるかに rich で、動的環境のために構築され、より多くの機能を持っています。 SCIM の numerous 制約により、SCIM を私たちの API として adopt することは大きな downgrade になります。 SCIM は 相互運用可能 実装をサポートすることを意図していないため、midPoint で SCIM サーバーを提供する 点 はないと考えています。

NOTE: Clever reader は、midPoint が SCIM スキーマに very 類似 なユーザースキーマを持つことに気づくでしょう。 理由は、midPoint スキーマと SCIM スキーマが VCARD や FOAF など同じ仕様化に基づいていることです。 しかしスキーマは 類似 であっても、same ではありません。 SCIM スキーマと midPoint スキーマは直接互換性があるではありません。

しかし SCIM はアプリケーションアイデンティティ管理 API を提供する広く使われている choice になりつつあります。 これら SCIM 実装は strictly 相互運用可能 ではありません。 ある SCIM サーバーと作業するクライアントが別の SCIM サーバーと flawlessly に作業する可能性は非常に低いです。 それでも SCIM-based API はすべて 類似 に見えます。 したがって arbitrary REST API をサポートするより、SCIM-based サービスのクライアントを実装する方がはるかに easy です。 この effect は、現在 developed されており midPoint 4.11 に計画されている SCIM/REST コネクターフレームワークで utilized されました。

SCIM/REST コネクターフレームワークは、新しい SCIM-based コネクターを迅速に 構築するために low-code 方法を使います。 フレームワークは particular SCIM サーバーに関する詳細を specify することで、新しい SCIM-based コネクターを作成するために使えます。 これら詳細は SCIM プロトコルでは自動的に 検出された できないため、コネクター declaration の形式で提供される必要があります。 一部のコネクターは専用機能を fully サポートするために、さらに専用コードを certainly 必要と するでしょう。 そのような機能は専用スクリプトの形式でコネクターに追加できます。

これはすべて間違いです!

__ これはすべて間違いです! SCIM is a 標準! You should behave と サポート the 標準. Come on! midPoint に SCIM サービスを実装する。 さて! __

まあ、technically には SCIM は標準ではなく informational RFC です。 しかし標準だったとしても、本当に機能しない標準の価値は何でしょうか。 私たちは、標準を持つ主な reason は 相互運用性 だと考えています。 SCIM はその面で驚くほどうまくいっていません。

ただし、私たちの SCIM assessment が誤りである可能性は認めます。 その場合は私たちに contact し、何を exactly 誤りとしているのかを知らせてください。 修正します。 将来 SCIM サポートへの方法を reconsider するかもしれません。 しかし条件が2つあります。

  1. SCIM は mature しなければなりません。 SCIM が useful になるには、行うべき 改善 が多数あります。

  2. Incentive が必要です。 SCIM インターフェイスの development と maintenance の両方に funding が 安全d される必要があるか、midPoint subscriber から大きな demand がある必要があります。 Hype だけでは大きな motivation ではありません。 少なくとも私たちにとってはそうです。

Community に判断してもらいましょう。 SCIM の考え方と SCIM が提供するソリューションが好きなら、どうぞ使ってください。 それが本当にケースであれば、私たちは SCIM について間違っていたことを喜んで admit します。 MidPoint で SCIM を使うことが useful だと思うなら知らせてください。 ただし、私たち全員のためにお願いがあります。SCIM について語る前に、SCIM を使ってみてください。 SCIM の評価が現実世界の経験に基づいていること、hype や inflated expectation に駆動されているだけではないことを確認してください。 私たちに必要なのは堅牢 エンジニアing ソリューションであり、television show ではありません。 Slide show や talk ではすべてが perfectly に機能します。 しかし私たちはそれらを導入 と run するわけではありませんよね。