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

この記事は https://docs.evolveum.com/iam/myths/universal-provisioning-interface/ の翻訳です。

アイデンティティ管理 (IDM) は統合がすべてです。ネットワーク越しにデータを移動しサービスを invoke するだけですよね。それこそ統合ツールが行うよう設計されたことです。統合のために設計されたシステムは多数あります。サービス bus、messaging システム、microservice coordinator、serverless integrator などです。エンタープライズサービス Bus (ESB) は、Service-Oriented アーキテクチャ (SOA) が流行していた頃、そのような統合システムでした。ここでは ESB と SOA を例として使い、統合ツールを使ってアイデンティティ管理をどう「改善」するかを示します。 IDM に統合ツールを使うのは完全に理にかなっています。それとも、本当にそうでしょうか。

いいえ。実際には違います。

"IDM over ESB"、"IDM over messaging"、あるいは "Microservice IDM" の基本考え方は次のようなものです。ユーザー管理の汎用サービスを設計しましょう。私たちの integrated solution に接続したいすべてのシステムは、そのサービスを実装しなければなりません。そのサービスを ESB 上で expose し、他の構成要素に使わせましょう。次のように見えるはずです。

この方法は理論上は sound に見えます。多くのサービスで再利用される単一インターフェイスです。うまく機能するはずです。理論上は。しかし機能しません。なぜでしょうか。

一般的なインターフェイス

"汎用プロビジョニングインターフェイス" が問題です。そのようなインターフェイスをどう設計するのでしょうか。実際には操作を設計するのは非常に簡単です。それらは主に基本 four CRUD 操作です。しかし操作パラメーターとなると、本当に複雑なになります。単純さのため、作成という1つの操作に焦点を当てましょう。この操作のパラメーターは何であるべきでしょうか。いくつかの識別子といくつかの属性です。では、正確にはどの属性でしょうか。アプリケーションごとに異なる属性が必要です。では、すべてのアプリケーションに fit する標準データモデルを作ろうとしましょう。素晴らしい考え方です。そんなに難しいはずはありませんよね。実は、これはかなり昔に試され、それほど昔ではない時期にも再び試され、さらに最近の attempt もあります。これらの実験には中身があり、実践的な利用もあるかもしれませんが、1つの側面を非常にはっきり示しています。実践的なシステムは標準スキーマだけを使って構築することはできません。実践的なソリューションは標準を extend する必要があります。システムが動作するために不可欠な、予期しない属性 foo や bar が常に必要になるからです。さらに興味深いことに、アプリケーション A1 は属性 foo を必要とし、アプリケーション A2 は属性 bar を必要とし、アプリケーション A3 も bar という名前の属性を必要としますが、それはアプリケーション A2 が必要とする bar とはまったく異なる属性です。

しかし心配はいりません。これはまさに統合ツール、たとえば ESB が扱うよう設計されたことです。そうですよね。 Nice な XSLT や scripting を使って、これらすべてのシステムのサービスパラメーターである申請と属性を変換できます。しかし待ってください。私たちの nice 汎用プロビジョニングインターフェイスはどうなるのでしょうか。同じ操作を持っていますが、instance ごとにまったく異なるパラメーターを持っています。それはあまりに汎用なので、もはやインターフェイスではなくなっているようです。RESTafarian の bell が鳴りませんか。したがってここには再利用の効果はほとんどありません。新しいシステムの統合は、誰も実際に何が起こっているのか分からないほど、ESB fabric の中で大量の XSLT とスクリプトによって処理される必要があります。

では drawing board に戻りましょう。インターフェイスという考え方に固執します。 Fixed 操作を持ち、属性も固定しましょう。少なくとも形式的には。それらを key-value pair として表しましょう。それで十分なはずです。そして ESB レベルでは十分です。しかしこれはシステムの反対側で統合されたインターフェイスを失ったことを意味します。セルフサービスアプリケーションはアプリケーション A1 に使う属性名をどうやって知るのでしょうか。そして状況はさらに悪化します。アプリケーションは属性種類をどうやって知るのでしょうか。そうです、すべてを string として表せます。それで十分でしょう。しかしアプリケーションは string "2011-02-03 04:05:06+0000" と "2011-02-03 05:05:06+0100" が同じ価値を表すことをどう知るのでしょうか。また識別子 "foo" と "Foo" が equivalent と見なされるべきことをどう知るのでしょうか。そしてさらに悪化します。すぐに、操作さえ本当には fixed にできないことが判明します。アプリケーション A1 はアカウント識別子が作成操作のパラメーターとして提供されることを期待します。しかしアプリケーション A2 は識別子を生成し、それを作成操作から return し、その後変更できません。アプリケーション A3 の識別子もアプリケーションによって生成されますが、アカウントが名前変更d されるたびに変わります。

単純汎用プロビジョニングインターフェイスという考え方全体が素朴なです。それは結局、役に立たなくなほど trivial になるか、実装が非常に高価なほど複雑になります。適切なバランスを取るのは非常に困難です。また、多くの動的部分、実行時にしか利用できず時間とともに変わるスキーマを持つ、非常に柔軟な定義が必要です。 SOA ツールはこの種の動的でデータ中心の統合シナリオのために設計されていません。これは Service-Oriented アーキテクチャであり、Data-Oriented アーキテクチャではありません。そして失敗します。ひどく。

費用

実用的で汎用なプロビジョニングインターフェイスを設計できると、しばらくの間仮定しましょう。かなりありそうにありませんですが。そのようなインターフェイスがあっても、まだ大して先には進んでいません。インターフェイスは abstraction です。単なる定義です。コードではありません。それ自体では動作しません。実装されなければなりません。次のようにです。

そしてアプリケーションの数だけ実装されなければなりません。インターフェイスの実装はアプリケーションの一部であり、したがってアプリケーション開発者の責任だからです。アプリケーション開発者は cross-application reuse が慢性的に苦手であるため、同じコードが各アプリケーションで何度も実装される可能性が非常に高いです。これはソリューション全体の費用を dramatic に増加させます。アプリケーションはまた、さまざまなプラットフォームとオペレーティングシステムを頻繁に使用しており、開発者が望んだとしてもコード reuse は実質的に prohibited されます。インターフェイスにはコードがないため、インターフェイスの reference 実装のようなものがない限り、実装をテストすることは極めて困難です。これはソリューションテストと統合バグ修正の費用を増加させます。これはプロジェクトで最も高価なテストとバグ修正フェーズであり、遅延と予算超過の最も頻繁な原因でもあります。これはまた、インターフェイス設計者が自分たちの定義が非常に曖昧であり、ソリューションが設計どおりには機能しないことに気づく時でもあります。そのため "glue コード"、つまり dirty hack がシステムに導入されます。これは長期維持管理悪夢を作ります。

インターフェイスという考え方は費用を削減するように見えるかもしれませんが、現実はしばしば逆です。インターフェイスは費用をいくつかの断片に分割しているだけです。個々の断片は元の費用より低くなります。しかしそれらすべてを組み合わされたすると、resulting 費用は astronomical になります。

そもそも機能するのか

良いインターフェイスを設計するのは非常に困難です。そしてそのようなインターフェイスを実装するのはさらに困難です。インターフェイスの "positive" side はしばしば簡単な部分です。これは、すべてがうまく動くときインターフェイスが何をするかを define します。しかし私たちは統合、networking、分散したシステムについて話しています。 Hic sunt leones。ネットワークでは物事がひどく間違います。物事は parallel に起こります。操作は失敗したりタイムアウトしたりします。その後 re-tried されますが、その時点はしばしば数時間後であり、システム状態はすでに changed されています。これらすべてが good インターフェイスの定義に reflect される必要があります。すべての corner ケース、race condition、parallelism、エラー処理、そしてそれらすべてがうまく実装される必要があります。

ここには major pitfall が1つあります。これはあらゆる分散したシステムにおける crucial 課題です。 Experienced ソフトウェア architect はこれをよく知っています。しかし、あまりに多くのエンジニアがこれを無視しており、その結果ソフトウェアシステムのライフタイム中に深刻な損害が生じます。もちろん整合性の話です。ネットワーク上のデータは本当には moved されたり passed along されたりできません。 Copied されるだけです。コピーが多いほど、それらが同じでなくなる、または全体として見たとき意味を失うリスクが高くなります。これがデータ不整合です。そしてそれは非常に簡単に起こります。アプリケーション A1 にアカウントを作成しようとして操作が時間 out したと仮定しましょう。操作は failed し、アカウントは作成されなかったと仮定できるでしょうか。それとも操作は実際には succeeded しており、ac知識メッセージだけがネットワーク上で lost したのでしょうか。操作を re-try すべきでしょうか。 Re-try してアカウントが作成されていたなら、re-try は fail します。 Re-try せず、アカウントが作成されていなかったなら、missing アカウントが1つあります。そしてこれは実際には最も単純なシナリオの1つです。

整合性は厄介です。正しく扱うのは極めて困難です。整合性に対処する従来の方法はトランザクションの使用です。しかし SOA ソリューションではトランザクションは現実的ではありません。トランザクションは通常、システム間に密結合を導入するからです。ネットワーク越しのトランザクションは、運用観点からもかなり脆弱になりがちです。物事を遅くし、データの一部をロックし、手作業での解決が必要な状態に陥り、デッドロックのリスクが常にあります。密結合と脆弱さは、サービス指向アーキテクチャで絶対に望まないものです。そして問題はここにあります。整合性問題は本質的にデータ中心であり、SOA は本質的にサービス中心であるため、SOA における整合性には簡単なソリューションがありません。

これは SOA ベースのアイデンティティ管理にとって悪い知らせです。アイデンティティ管理の主な経済的目的は費用と労力を削減することです。しかし不整合の小さなリスクでさえデータ size によって multiplied されます。したがって規模が小さい、たとえば小規模エンタープライズでは整合性課題はそれほど重要なではないかもしれません。しかし規模が増える、たとえばクラウドサービスでは、はるかに悪化します。大規模サービスは、1つのトランザクションが間違って重要なデータ片をロックアウトしたためにシステム全体が停止するリスクを許容できません。クラウドサービスは、ネットワーク障害による不整合を手作業で解決するサービスデスクへの問い合わせの費用を許容できません。また、システムが自己修復できなければ効率的にスケールできません。そしてインターネット時代におけるスケーラブルでないシステムの成功に、私は自分のお金を賭けません。

ソリューション

ではソリューションは何でしょうか。それは単純であり複雑でもあります。

単純です。職務に合った正しいツールを使うことです。 Data-centric 問題にはデータ中心ソリューションが最適です。良い IDM システムはそれを行うように設計されています。また、インターフェイスよりはるかに多くのものが必要です。インターフェイスはコードを持たない abstraction にすぎないため、それ自体では何も解決しません。その職務を行うには implementation が必要です。そして繰り返しますが、良いアイデンティティプロビジョニングシステムはそのような実装です。ここで複雑になります。アイデンティティプロビジョニングシステムはアプリケーションスキーマの difference に対処する必要があります。それらを実行時でプロセス、評価し、属性を対応付けし、価値を比較と変換する必要があります。これは複雑性を意味します。実装の複雑性と設定の複雑性の両方です。しかし良いアイデンティティプロビジョニングシステムは、その複雑性の大部分を実装内に隠します。そのようなシステムは、設定複雑性を効率的に扱えるよう、容易に設定・管理できるよう設計されています。

プロビジョニングシステムが導入されると、全体像は少し変わります。

もはや "汎用" インターフェイスはありません。むしろ "統合された" インターフェイスがあります。これは1つの実装を持つ1つのインターフェイスです。インターフェイスは、この特定の導入用にカスタマイズされた統合されたデータモデルを提供します。これは通常、標準スキーマの一部といくつかの専用拡張の組み合わせです。しかし拡張は practically fixed であるため、ESB 上のサービスはデータモデルが何であり、何を expect すべきかを正確に知っています。

インターフェイスの実装は内部的に非常に複雑です。それはプロビジョニングシステム自体です。また非常に柔軟でもあります。 ESB サービスが使う "標準" 属性を、アプリケーション側の特定の属性に対応付けします。良いインターフェイスがそうすべきように、"実装詳細" を隠します。

プロビジョニングシステムはエラーやデータ不整合を処理し、リソース上の変更に対応し、全体としてデータ整合性を良好に guarantee します。そうするよう設計されています。 Design 上データ中心です。

新しいシステムがソリューションに接続されると、そのスキーマは既存 "標準" スキーマに対応付けされます。可能な限りです。しかしこれはプロビジョニングシステムの内部で起こり、他の SOA サービスからは隠されていますです。既存スキーマに対応付けできないが必要な extra 属性がある場合、標準スキーマを backward-compatible な方法で extend できます。したがってシステムの残りの部分は影響を受けず、新しいシステムの統合は容易です。

プロビジョニングシステムはコネクターを使ってアプリケーションと talk します。それらを "データベース driver" と考えてください。コネクターは通常非常に単純であり、行うことはプロトコル translation だけです。属性とデータ種類対応付けの magic はすべてプロビジョニングシステム "実装" によって行われます。

プロビジョニングコネクターはサービスのように見えるかもしれません。そして非常に多くの SOA architect はそれらをサービスとしてモデル化しがちです。しかしこの trap に陥らないでください。それらはサービスではありません。 Data アクセス driver です。そこには大きな違いがあります。もちろん、technically にはほとんどすべてのものをサービスと見なせるため、それらは service です。しかしそれは私には golden hammer の一撃に非常によく似て聞こえます。コネクターはデータを扱うよう設計されています。 CRUD セマンティクスは組み込みであり、それに最適化されています。たとえば効率的データ照合に不可欠な long iterative 検索をサポートするよう構築されています。コネクターはまた、不明動的スキーマを扱い、ネットワーク障害を想定して処理するよう設計されています。またコネクターはプロビジョニングシステムの環境で run するため、プロビジョニングシステムがすべてのコネクターに提供する一般的機能に rely できます。

プロビジョニングコネクターを作成する費用は、ESB-based 適応ation 構成要素を作成する費用に comparable かもしれません。基本的な "positive" 機能はほぼ同じ、つまり4つの基本 CRUD 方法を実装することなので comparable です。しかし品質には巨大な違いがあります。 ESB-based 構成要素は fragile になります。ESB 自体が誤り回復機能をほとんど提供しないからです。一方、プロビジョニングコネクターはプロビジョニングシステムの堅牢誤り回復機能に rely できます。覚えておいてください。ESB は処理しているデータを理解しません。サービス invocation のどの部分がデータを含むかさえ知りません。しかしプロビジョニングシステムはデータをほぼ完全に理解します。プロビジョニングシステムは、エラー回復、整合性保証、ポリシー強制、監査、認可などをはるかに良く行えます。 ESB-based プロビジョニング構成要素を構築することは、ほとんどリソースの無駄です。遅かれ早かれ失敗します。しかしプロビジョニングコネクターは作成費用がより高いわけではなく、何十年にわたり確実に動作します。