User-Managed Access

索引トップ用語の索引ランキングカテゴリー

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/08/06 15:46 UTC 版)

実装と採用の状況

UMA core プロトコルには、いくつかのオープンソース実装を含めて、いくつかの実装がある^[8]。活発かつ入手可能なオープンソース実装には、アルファベット順にForgeRock^[9]、Gluu^[10]、MITREid Connect^[11]、Atricore、Node-UMA^[12]、Roland Hedbergがある^[13]。 Kantara Initiativeのワーキンググループは、開発者がUMAのprotection APIや認可APIをアプリケーション、サービス、デバイスに取り入れることを支援するFOSS（free and open-source software）の開発作業をいくつかの身近なプログラミング言語で行っている^[14]。

UMA可動製品は、Gluu^[15]、Jericho Systems^[16]、ForgeRock^[17]から入手できる。

OAuth 2.0との比較

次の図では、UMAがOAuth 2.0に追加した点を強調してある。

図UMA仕様に巻き込まれる実体と関係の概観

典型的なOAuthフローにおいて、クライアントアプリケーションを運用している人間であるRO（Resource Owner）は、ログインするためにAS（Authorization Server）にリダイレクトされ、クライアントアプリケーションが機能としてROの代わりにRS（Resource Server）の一定範囲にアクセスできるようにアクセストークンの発行に承諾する。 RSとASは、一般的に同一のセキュリティドメイン内で運用されており、それらの間の通信は、OAuthの主仕様によっては標準化されていない。

UMAは、3つの主要コンセプトと対応する構造とフローを追加する。

UMAは、ASにおいてRSがしゃべりかける標準化されたAPI（protection APIと呼ばれるもの）を定義する。このことは、複数のRSがひとつのASと通信できるようにし、その逆もできるようにし、そのAPI自体がOAuthによってセキュアになっているのでペアの間にフォーマルな信頼を確立できるようにする。これはまた、ASがROに対して中心となるユーザインタフェイスを提供できるようにする。
UMAは、ROからは自律的なアクセス要求者（RqP：Requesting Party）を正式に定義する。これはparty-to-party間の共有やアクセス認可の代理を可能にする。ROは、トークン発行をランタイムに承諾する必要がなく、ポリシーをASに設定することができ、RqPがいつでもアクセスを試みられるようにする。
UMAは、アクセス要求者の信頼度（の格上げのプロセス）に基づいて、認可データと関連付けられたアクセストークンを発行できるようなアクセスのしくみを可能にし、例えば、アクセス要求者からアイデンティティクレームもしくは他のクレームを収集することを可能にする。

適用可能なユースケース

UMAのアーキテクチャは、様々な顧客によるユースケースや企業によるユースケースを提供できる。 UMAグループは、ケーススタディをそのwiki上に集めている ^[18]。

ユースケースの例は、「healthcare IT」や「consumer health」にある。「OpenID Foundation」の組織内において、「HEART（Health Relationship Trust）」^[19]と呼ばれるWGは、「個人が、RESTfulなhealth関連データ共有APIに対するアクセス認可を制御できるようにするプライバシーとセキュリティの仕様群を、調和をはかりながら開発する」という作業を、数ある標準の中でUMAの上に築く作業として行っている。

UMAの開発に当初から影響を受けてきたユースケースの他の例には、ベンダー関係管理の形態におけるパーソナルデータ・サービスの分野である。この概念において、個人が、リソース共有の管理能力を備えるダッシュボードを提供するために、様々な顧客が面するデジタルリソースを格納するコンピュータからの連携を許可する認可サービスの運用者を選択できる。

脚注