Loading article…
ユーザー管理アクセス(UMA) は、当事者間の認証のためのOAuthベースのアクセス管理プロトコル標準です。 [ 1 ]この標準のバージョン 1.0 は、2015 年 3 月 23 日にKantara Initiativeによって承認されました。 [ 2 ]
UMAを開発したグループの憲章[ 3 ]に記載されているように、プロトコル仕様の目的は、「リソース所有者が、所有者に代わって、または所有者の許可を得て、自律的な要求者によってオンラインサービス間で行われるデータ共有やその他の保護されたリソースへのアクセスの承認を制御できるようにする」ことです。この目的は、標準化グループの参加者から提供された事例研究集で検討されているように、 Webアプリケーションやモノのインターネット（IoT）のプライバシーと同意に影響を与えます。 [ 4 ]
[ 5 ]の図（右図参照）は、UMAがOAuth 2.0に加えた重要な追加事項を強調している。
一般的なOAuthフローでは、リソース所有者（RO）、つまりクライアントアプリケーションを使用する人間が、認証サーバー（AS）にリダイレクトされ、ログインしてアクセストークンの発行に同意します。このアクセストークンにより、クライアントアプリケーションは、リソース所有者に代わって、将来的にリソースサーバー（RS）へのAPIアクセスを取得できるようになります。このアクセスは、おそらくスコープ付き（制限付き）で行われます。リソースサーバーと認証サーバーは、多くの場合同じセキュリティドメイン内で動作し、両者間の通信は、主要なOAuth仕様によって必ずしも標準化されているわけではありません。
ユーザー管理アクセスは、主に3つの概念とそれに対応する構造およびフローを追加します。
Kantara InitiativeのUMAワーキンググループ[ 3 ]は、2009年8月6日に最初の会議[ 6 ]を開催しました。UMAの設計原則と技術設計は、 Sun Microsystemsの従業員が2008年3月に開始したProtectServeと呼ばれるプロトコルに関する以前の作業に基づいています。一方、ProtectServeは、ベンダー関係管理運動の目標と、フィードベースのVRMと呼ばれる派生的な取り組みの影響を受けています。
ProtectServeとUMAの初期バージョンは、OAuth 1.0プロトコルを利用していました。Web Resource Authorization Protocol（WRAP）仕様の公開、そしてその後のOAuth 2.0のドラフト化によってOAuthが大きく変化するにつれ、UMA仕様もそれに合わせて進化し、現在ではいくつかの主要なプロトコルフローでOAuth 2.0ファミリーの仕様を使用しています。
UMAは、ユーザー認証手段としてOpenID 2.0を使用または依存していません。ただし、オプションとして、OAuthベースのOpenID Connectプロトコルを使用して、要求元からIDクレームを収集し、認証ユーザーのアクセスポリシーを満たすよう試みます。
UMA は、ユーザー ポリシーのエンコードやポリシー決定の要求手段として、拡張アクセス制御マークアップ言語 ( XACML ) を使用したり、依存したりしません。ポリシー評価は UMA の観点からは認可サーバー (AS) 内部で行われるため、UMA はポリシーのフォーマットを規定しません。通常、XACML は AS 内部でポリシーを実装するために使用されます。その実装は UMA の範囲外です。アクセス権限を要求する UMA プロトコル フローには、XACML プロトコルと共通する機能がいくつかあります。
UMA グループは Kantara Initiative [ 7 ]で活動しており、UMA 標準化作業の最終的な拠点として、インターネット技術タスクフォース(IETF)に一連のインターネット ドラフト仕様も提供してきました。この目的のために、ワーキンググループは、検討のためにいくつかの個別のインターネット ドラフトを IETF に提供しました。これらのうちの 1 つは、OAuth の動的クライアント登録の仕様[ 8 ]であり、最終的に OAuth 用に開発されたより汎用的なメカニズムの入力として機能しました。[ 8 ] UMA は、2019 年 3 月に開催された IETF 104 会議で OAuth ワーキンググループ[ 9 ]に発表されましたが[ 10 ]、IETF によって UMA 仕様が採用されることはありませんでした。
UMA コア プロトコルには、いくつかの実装があり、[ 11 ]いくつかのオープンソース実装も含まれています。現在アクティブで利用可能なオープンソース実装のソースには、ForgeRock、[ 12 ] Gluu、[ 13 ] IDENTOS Inc.、[ 14 ] MITREid Connect、[ 15 ] Atricore、Node-UMA、[ 16 ] Roland Hedberg、[ 17 ] Keycloak、[ 18 ]および WSO2 Identity Server があります。[ 19 ] Kantara Initiative グループは、「開発者が UMA 保護および認証 API の有効化をアプリケーション、サービス、およびデバイスに組み込むことを可能にする、いくつかの一般的なプログラミング言語でのフリーでオープンソースのソフトウェア(FOSS)」の開発に取り組んでいます。[ 20 ]
UMA対応製品は、Gluu [ 21 ] Jericho Systems [ 22 ] ForgeRock [ 23 ] IDENTOS Inc. [ 24 ]および WSO2 Identity Server [ 19 ]から入手可能です。
UMAプロトコルには複数の実装があります。ForgerockはOpenUMAの下で最初のオープンソース実装を提供しています。[ 25 ]認証サーバーの最初の実装は、ナイトリービルドでOpenAMを使用してテストされる予定です。[ 26 ]
GluuはAPIへのアクセスを保護および管理するためにUMAを実装しました。[ 27 ] Cloud Identity Limitedは個人情報とWeb APIへのアクセスを保護および管理するための完全なUMA実装を持っています。その他数社がワーキンググループに対して実装と相互運用性テストへの関心を示しています。
UMAのアーキテクチャは、消費者向けおよび企業向けのさまざまなユースケースに対応できます。UMAグループは、そのwikiにケーススタディを収集しています。[ 28 ]
使用例の1つは、ヘルスケアITと消費者向けヘルスケアです。OpenID Foundation組織では、Health Relationship Trust（HEART）[ 29 ]と呼ばれるワーキンググループが、UMAなどの標準に基づいて、「個人がRESTfulな健康関連データ共有APIへのアクセスの承認を制御できるようにするプライバシーとセキュリティ仕様のセットを調和および開発する」作業を行っています。
UMAの開発に影響を与えたもう一つのユースケースの例は、ベンダー関係管理の手法を用いた「個人データストア」の分野です。この概念では、個人は、さまざまな消費者向けデジタルリソースホストからの接続を受け入れる認証サービスのオペレーターを選択し、リソース共有管理機能を備えたダッシュボードを利用できます。