Authentication is "solved"
The authentication world has mature specifications that are universally adopted, such as OAuth2 and OpenID Connect. This has helped the industry solve "single sign-on for the web".
認証は「解決済み」
認証の世界には、OAuth2 や OpenID Connect など、広く採用されている成熟した仕様があります。これにより、業界は「Web のシングル サインオン」の問題を解決できました。
OAuth 2.0は置いておいて、認証の世界はOpenID ConnectやSAMLなどのID連携のための仕組みによりシングルサインオンの実現など、複雑性を解決してきました。
Authorization is next
The authorization world has lagged behind. Today, each application has its own way of assigning permissions to users, what we call an "N * M problem".
次は認可です
認可の世界は遅れています。現在、各アプリケーションはユーザーに権限を割り当てる独自の方法を持っており、これを「N * M 問題」と呼びます。
著者がn*m問題として記載している通り、アプリケーションが個々にユーザの権限を管理せざるを得ない、という状況が確かに存在しています。実際、認可を集中管理しにくかった理由としては、アプリケーションごとに保持しているリソースや権限の粒度はバラバラかつ変化が激しく、集中管理するには複雑すぎる、ということがしばしば挙げられます。まさにn*m問題です。
But help is one the way! OpenID AuthZEN aims to become the "OpenID Connect of authorization", and has just entered the review phase for the first Implementer's Draft of the Authorization API version 1.0.
Having served as co-chair of the WG and co-editor of the spec, this means a lot to us at Aserto. Why?
しかし、助けは必ずあります! OpenID AuthZEN は「認可の OpenID Connect」になることを目指しており、Authorization API バージョン 1.0の最初の実装者ドラフトのレビュー段階に入ったところです。
WG の共同議長および仕様の共同編集者を務めた Aserto にとって、これは大きな意味を持ちます。なぜでしょうか?
わくわくしますね！この問題が解けると確かに大きなインパクトです。
Why standardize authorization?
Standards efforts are multi-year affairs, so we don't take them lightly. Standardizing a developer technology needs three things to succeed:
- It addresses a significant pain point.
- Competing technology providers find areas where standardization doesn't erode differentiation, but accelerates adoption.
- It provides significant benefits to consumers and end-users of the technology, which drives adoption.
認可を標準化する理由は何ですか?
標準化の取り組みは数年にわたる作業であるため、私たちはそれを軽視しません。開発者テクノロジーの標準化を成功させるには、次の 3 つのことが必要です。
- それは重大な問題点に対処します。
- 競合するテクノロジー プロバイダーは、標準化によって差別化が損なわれることなく、導入が加速される領域を見つけます。
- これは、テクノロジーの利用者とエンドユーザーに大きなメリットをもたらし、採用を促進します。
これはAuthorization APIに限らず、すべての標準仕様について言えることだと思いますが、実装するプロバイダの競争領域と協調領域の特定から始める必要があるわけです。当然のことながら競争領域では各ベンダが差別化をしていくポイントなので、その領域に関して情報開示はしないわけです。ただ協調した方が全体にとってメリットがある部分は必ず存在するので、そこを特定して標準化をしていくわけです。また、これらのテクノロジーはコンシューマ（実装する人たち）やエンドユーザにとってメリットがなければ設計しても使われることはありません。
ODBC
Early in my career, around 1993, I witnessed this first hand with Open Database Connectivity, or ODBC. Consumers wanted data-centric applications (Excel, Access, Visual Basic, Powerbuilder, and countless more) to be able to talk to a bunch of data sources (Oracle, Sybase, SQL Server, DB2, Informix, and many others).
This is what we call an "N * M" problem: N applications need to build connectors to M data sources. Wasteful and expensive.
ODBC addressed this challenge by defining a universal data access API, which database vendors could implement, and applications could consume, transforming it into an "N + M" problem. All of the sudden, any data application could immediately talk to a whole bunch of data sources simply by being a consumer of ODBC.
My startup, NEON Systems, bet on this standard and rode its success by integrating data-centric applications with a wide variety of enterprise data sources. NEON was so successful it went public in 1999.
ODBC
キャリアの初期、1993 年頃に、私は Open Database Connectivity (ODBC) でこれを直接目にしました。消費者は、データ中心のアプリケーション (Excel、Access、Visual Basic、Powerbuilder など数え切れないほど) が、多数のデータ ソース (Oracle、Sybase、SQL Server、DB2、Informix など) と通信できることを望んでいました。
これは「N * M」問題 と呼ばれるもので、 N 個のアプリケーションがM 個のデータ ソースへのコネクタを構築する必要があります。これは無駄が多く、コストもかかります。
ODBC は、データベース ベンダーが実装し、アプリケーションが使用できるユニバーサル データ アクセス API を定義することでこの課題に対処し、これを「N + M」問題に変換しました。突然、ODBC のコンシューマーになるだけで、あらゆるデータ アプリケーションが大量のデータ ソースとすぐに通信できるようになりました。
私のスタートアップ企業である NEON Systems は、この標準に賭け、データ中心のアプリケーションをさまざまなエンタープライズ データ ソースと統合することで成功を収めました。NEON は大成功を収め、1999 年に株式を公開しました。
ODBC！今となっては懐かしいですね。。私もめちゃくちゃ使ってました。まさにデータベース管理システム（OracleとSQL Serverなど）が乱立している時代（今もか）にユニバーサルなAPIは必須アイテムでした。まぁ、もちろん固有の機能を使うには各社のクライアントを使う必要があったりしたわけですが。
Open ID Connect
Two decades after ODBC, OpenID Connect (OIDC) became a standard that solved a similar problem. N SaaS applications needed to integrate with M corporate identity providers. By adopting the OIDC protocol, each SaaS app allows its users to sign-in with their corporate identity provider (Okta, Azure AD, Google Workspace, Ping ID, etc).
Admins no longer have to worry about corporate users creating their own logins on each SaaS application - they can use a single corporate login across all these applications. Onboarding and offboarding become a breeze!
At Microsoft, our vision for this started with SAML, WS-Security, and WS-Federation in the early 2000's, but it wasn't until 2013 that OIDC reached its tipping point. The journey took a while, but the result has been nothing short of transformational.
まぁ、この辺りまでは歴史の話ですな。OpenID Connect
ODBC の 20 年後、OpenID Connect (OIDC) が同様の問題を解決する標準になりました。N個のSaaS アプリケーションをM個の企業 ID プロバイダーと統合する必要がありました。OIDC プロトコルを採用することで、各 SaaS アプリのユーザーは企業 ID プロバイダー (Okta、Azure AD、Google Workspace、Ping ID など) を使用してサインインできるようになります。
管理者は、企業ユーザーが各 SaaS アプリケーションで独自のログインを作成することを心配する必要がなくなりました。管理者は、これらすべてのアプリケーションで単一の企業ログインを使用できます。オンボーディングとオフボーディングが簡単になります。
Microsoft では、このビジョンは 2000 年代初頭に SAML、WS-Security、WS-Federation から始まりましたが、OIDC が転換点に達したのは 2013 年になってからでした。この道のりには時間がかかりましたが、その結果はまさに変革をもたらすものでした。
Open ID AuthZEN
Fast forward a decade to 2024: the same "N * M" problem exists in the authorization space. Every corporate application has its own way of assigning permissions to users. And the solution is similar to how applications have externalized authentication to an OIDC-compliant IDP: externalizing authorization to an AuthZEN-compliant Policy Decision Point (PDP).Applications that do this not only save a bunch of time and effort rolling out their own bespoke authorization. They also allow IT administrators to enforce common policies across applications, ensure compliance across applications, and answer questions like "which users have access to which resources" across applications.While authorization vendors want to differentiate on expressing policies, ensuring compliance, facilitating forensics, and managing authorization at scale, none of us really care about what the authorization API actually looks like. We all have similar APIs that are arbitrarily different, and they are not a real source of differentiation.Standardizing the way a policy enforcement point (PEP) such as an application or API gateway calls an authorization platform (PDP) greatly reduces the friction of integrating the PEP with a wide variety of authorization solutions. It helps everyone:
- Applications and API gateways can integrate with a bunch of externalized authorization systems using a single API, instead of creating bespoke integrations with each.
- Authorization platforms become relevant to a broader set of applications and other policy enforcement points.
- IT Administrators have a single "Authorization control plane" to manage policies and entitlements, and answer questions such as "what resources does this user have access to".
OpenID AuthZEN
10 年後の 2024 年、同じ「N * M」問題が認可の分野で存在します。すべての企業アプリケーションには、ユーザーに権限を割り当てる独自の方法があります。そして、その解決策は、アプリケーションが認証を OIDC 準拠の IDP に外部化する方法と似ています。つまり、認可を AuthZEN 準拠のポリシー決定ポイント (PDP) に外部化します。
これを実行するアプリケーションは、独自のカスタム認証を展開する時間と労力を大幅に節約するだけではありません。IT 管理者は、アプリケーション間で共通のポリシーを適用し、アプリケーション間でコンプライアンスを確保し、アプリケーション間で「どのユーザーがどのリソースにアクセスできるか」などの質問に答えることもできます。
認可ベンダーは、ポリシーの表現、コンプライアンスの確保、フォレンジックの促進、大規模な認可の管理で差別化を図りたいと考えていますが、認可 API が実際にどのようなものであるかについては、誰も気にしていません。ベンダーは皆、任意に異なる類似の API を持っており、それらは差別化の本当の源ではありません。
アプリケーションや API ゲートウェイなどのポリシー適用ポイント (PEP) が認可プラットフォーム (PDP) を呼び出す方法を標準化すると、PEP をさまざまな認可ソリューションと統合する際の摩擦が大幅に軽減されます。これにより、すべての人が次のメリットを享受できます。
- アプリケーションと API ゲートウェイは、それぞれにカスタマイズされた統合を作成する代わりに、単一の API を使用して多数の外部認証システムと統合できます。
- 認可プラットフォームは、より広範なアプリケーションやその他のポリシー適用ポイントに関連するようになります。
- IT 管理者は、ポリシーと権限を管理し、「このユーザーはどのリソースにアクセスできるか」などの質問に答えるための単一の「承認コントロール プレーン」を持ちます。
まぁ、この手の仕組みとして非常にオーソドックスなアプローチですね。PDPを一箇所に集めて、PEPはそのAPIを通じて呼び出すという仕掛けですね。
What does this milestone mean?
So standardizing authorization is important. Why celebrate this milestone?
We started the OpenID AuthZEN WG in late October 2023. In one short year, we've been able to define a number of iterations of our first spec, the PEP-PDP API. We now have 13 interoperable implementations of a preview version of this spec.
We've learned quite a bit from the interop events we conducted at Identiverse 2024 and EIC 2024, and now have a candidate Implementer's Draft.
This milestone means that vendors can safely incorporate AuthZEN into their products, without worrying that the spec will "move under them". This also means that Policy Enforcement Points, such as API Gateways, SaaS applications, and identity providers can start calling out to AuthZEN PDPs to make authorization decisions.
このマイルストーンは何を意味するのでしょうか?
したがって、認可の標準化は重要です。なぜこのマイルストーンを祝うのでしょうか?
私たちは、2023 年 10 月下旬に OpenID AuthZEN WG を開始しました。わずか 1 年で、最初の仕様であるPEP-PDP APIの反復を何度も定義することができました。現在、この仕様のプレビュー バージョンの相互運用可能な実装が 13 個あります。
私たちは、Identiverse 2024 と EIC 2024 で実施した相互運用イベントから多くのことを学び、現在は実装者ドラフトの候補が揃っています。
このマイルストーンは、ベンダーが仕様が「自分たちの下に移る」ことを心配することなく、AuthZEN を自社の製品に安全に組み込むことができることを意味します。これはまた、API ゲートウェイ、SaaS アプリケーション、ID プロバイダーなどのポリシー適用ポイントが、AuthZEN PDP を呼び出して承認の決定を下せるようになることも意味します。
そう、このAuthZENワーキンググループはまだ1年経ってないんですよね。1年未満でImplementer's draftが出てくるのは異常なスピード感ですね。また、書いてある通り13の相互運用性が確認できる実装があるのもすごいことです。
ちなみに相互運用性検証の結果はこちらで見れます。
What's next?
The review and voting period extends through November 9, 2024. At that point, we will have a formal Implementer's Draft.
Aserto is committed to incorporating AuthZEN in a first-class way into our authorization engine, Topaz, as well as our commercial products.
In addition, we're looking forward to working with the community to create developer SDKs for a wide variety of languages, and working with API gateway vendors to make it trivial to call an AuthZEN-compliant PDP from a request filter.
The next AuthZEN interop event is at Authenticate 2024 on October 15, 2024. We plan on testing the next iteration of the spec, which defines how to send multiple evaluations in a single request, facilitating scenarios such as turning on and off features in a web or native UI based on a user's permissions.
次は何ですか？
レビューと投票期間は 2024 年 11 月 9 日までです。その時点で、正式なImplementer's draftが作成されます。
Aserto は、AuthZEN を当社の認証エンジンTopazおよび商用製品に最高レベルの方法で組み込むことに尽力しています。
さらに、私たちはコミュニティと協力してさまざまな言語向けの開発者 SDK を作成し、API ゲートウェイ ベンダーと協力してリクエスト フィルターから AuthZEN 準拠の PDP を簡単に呼び出せるようにすることを楽しみにしています。
次の AuthZEN 相互運用イベントは、2024 年 10 月 15 日の Authenticate 2024 です。私たちは、単一のリクエストで複数の評価を送信する方法を定義し、ユーザーの権限に基づいて Web またはネイティブ UI で機能をオン/オフにするなどのシナリオを容易にする、仕様の次のイテレーションをテストする予定です。
先にも書きましたが相互運用性テストが継続的に行われているのはとても良いことですね。DCP WGのVerifiable Credentials関連の仕様や、SSFでも相互運用性テストが積極的に実施されているのと同様に仕様を作りつつ実装で試験をしていくという流れは標準化にとって非常に重要な意味を持ちます。
Future work
We have lofty goals for AuthZEN. We will define a search API which standardizes answering questions like "which resources does this user have access to", and "which users can access this resource".
We also plan on defining ways in which upstream data sources can send data updates to policy decision points and policy information points, so that PDPs can have the latest user, group, and relationship information when evaluating access decisions.
今後の仕事
AuthZEN には高い目標があります。 「このユーザーはどのリソースにアクセスできるか」や「どのユーザーがこのリソースにアクセスできるのか」といった質問への回答を標準化する検索 API を定義します。
また、上流のデータ ソースがポリシー決定ポイントとポリシー情報ポイントにデータ更新を送信する方法も定義する予定です。これにより、PDP はアクセス決定を評価する際に最新のユーザー、グループ、関係情報を取得できるようになります。
今後の動きに期待です！楽しみですね。
今回はイントロということでしたので、次から実際の仕様を見ていこうと思います。
0 件のコメント:
コメントを投稿