User-Managed Access

User-Managed Access （UMA）は、OAuthに基づくアクセス管理プロトコル標準である。 この標準のバージョン1.0は、2015年3月23日、Kantara Initiativeによって承認された。

UMAを開発したグループの憲章^[1]に記述されているように、プロトコル仕様の目的は「リソースオーナー（RO）が、オンラインサービス間で行われるデータ共有や他のリソースに対するアクセス認可を制御できるようにすること」にあり、これは、「POの代わりに、あるいは、ROによる認可 を伴って自律的なアクセス要求者（RqP）によって」行われる。 この目的には、標準化グループの参加者によって行われたケーススタディの収集によって探求されたように、WebアプリケーションとIoT（Internet of Things）についてのプライバシーと承諾が考慮されている ^[2]。

経緯と背景

Kantara InitiativeのUMA Work Group^[3]は、2009年8月6日にその最初の会合を開催した^[4]UMAの設計原則と技術的な設計は、2008年3月に始まったProtectServeと呼ばれたプロトコルについてのサン・マイクロシステムズ社の従業員による以前の作業によって知らされていた。 今度はProtectServeが、ベンダー関係管理（VRM）の動向と、「feeds-based VRM」と呼ばれる副次的活動の目標によって、影響を受けた。 

ProtectServeとUMAの初期バージョンは、OAuth 1.0プロトコルを応用していた。 OAuthは、WRAP（Web Resource Authorization Protocol）仕様や、以降のOAuth 2.0のドラフトの発行を通じて大幅な変更を経たが、UMA仕様は追随し、現在、いくつかの主要プロトコルフローのためにOAuth 2.0系の仕様を使っている。 

UMAは、OpenID 2.0をユーザ認証の手段として使ったり依存したりしない。 しかし、オプションとしてアクセス要求者（RqP）からアイデンティティクレーム（claim）を収集する手段として、認可を行うユーザのアクセスポリシーを満たすようにするために、OAuthに基づくOpenID Connect プロトコルを使う。

またUMA はXACML（eXtensible Access Control Markup Language）を、ユーザポリシーの符号化にも、アクセス認可のリクエストの手段としても、使ったり依存したりしない。 UMAは、ポリシーのフォーマットを指定しない。 UMAの観点からは、ポリシーに照らした判定は、ASにとって最初に行われるからである。 しかし、アクセス許可をリクエストするためのUMAプロトコルフローは、XACMLプロトコルといくつか共通の機能をもつ。 

標準化状況

UMAグループは、Kantara Initiativeにおいて作業を行っており ^[5]、UMAの標準化作業についての本家としてIETF（Internet Engineering Task Force）における一連のInternet-Draft 仕様にも貢献してきた。 こちらでは、このWGは、IETFに対して、考慮に値するいくつかの個別のInternet-Draftに貢献してきた。 これらのひとつであるOAuth dynamic client registration^[6] のための仕様は、より一般化されたメカニズムについて入力する役割を果たし、結局、OAuthの開発につながった^[7]。

実装と採用の状況

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つの主要コンセプトと対応する構造とフローを追加する。

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

適用可能なユースケース

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

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

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

参考文献

• 工藤 達雄 (2010年). “User Managed Access”. 情報セキュリティ技術動向調査（2010 年上期）. IPA. 2016年2月12日閲覧。