ユーザー中心のアクセス管理の実現を目指すUser Managed Access：デジタル・アイデンティティ技術最新動向（8）（1/2 ページ）

今回は、ユーザー中心のアクセス管理やサービスを超えたデータ共有の実現を目指して策定が進むアクセス管理プロトコル、「User Managed Access」について紹介します。

[ritou（OpenID Foundation Japan），＠IT] PC用表示関連情報

LINE

Hatena

「ウーマ」ってなーんだ？

　今回は「User Managed Access」、略して「UMA」（読み方は「ウーマ」）というWebベースのアクセス管理プロトコルを紹介します。

　これまでの連載を読まれた方は、アクセス管理というと「OAuth」を思い浮かべるでしょう。OAuthにより、あるサービス上のユーザーデータへのアクセス権限を、外部のアプリケーションに安全に付与できます。

　しかし、OAuthがサポートしているのはユーザーが外部アプリケーションを通して自分のデータにアクセスするユースケースのみであり、他人とデータを共有するというユースケースは想定されていません。

　他人とのデータ共有というと、設定を変更してサービス内の公開範囲を限定したり、秘密のURLを教え合うことで、アクセス可能なユーザーを制限する手法が一般的です。しかし、前者には共有対象が同一サービス利用者に制限されてしまう、後者には秘密のURLの漏洩により意図せぬ公開の可能性があるなど、サービスを超えたデータ共有には課題があります。

　UMAはオンラインサービスにおけるデータ共有やリソースアクセスの認可処理をユーザーがコントロールする世界を目指しています。本稿ではOAuthとの違いを中心に、UMAの概要を紹介します。

OAuthの前提

　UMAの特徴を理解するに当たって、OAuthの前提をいくつか振り返っておきましょう。

ClientはResource Ownerの「代わり」としてリソースにアクセス

　現在、OAuthを用いたさまざまなアプリケーションが提供されています。「この画像をSNSの友人に共有する」といった機能を利用すると、OAuthにより第三者へのデータ共有が行われているように感じられますが、アプリケーションはあくまで“ユーザーの代わりにSNSに投稿”しているだけであって、友人に共有しているのはSNSの機能です。

　OAuth 2.0の用語で表現すると、Authorization Code GrantやImplicit Grantでは、ユーザー（Resource Owner）が、外部のアプリケーション（Client）に対し、自らのデータへのリソースアクセスを許可します。言い換えると、OAuthではユーザーが自分以外の第三者に対してリソースアクセスを許可することを想定していません。

　よって、「AさんがBさん（別のユーザー）にプライベートな画像を共有」「Cさんが雇用先である企業（組織）に対して決済サービスに登録済みの住所情報を公開」といった機能は、OAuth単体では実装できません。

Authorization Server中心のアクセス管理

　複数のSNSに投稿を行うアプリケーションを利用する場合、ユーザーはそれぞれのサービス上でアプリケーションにリソースアクセスを許可する必要があります。

　OAuthでは、ユーザーデータ（Protected Resource）とアクセス管理を行うAuthorization Serverは、一意にひも付いています。複数のAuthorization Serverを横断的に利用している場合、管理しなければならないアクセス許可はAuthorization Serverごとに分散されてしまいます。よって、アプリケーションの利用が増えるに従い、ユーザーの管理コストがますます大きくなってしまいます。

図1　分散するリソースアクセス管理

　また、アクセス範囲や有効期限などのリソースアクセスに関するポリシーは、Authorization Serverにより決められています。ClientはAuthorization Serverが定めたPermissionの中から自らのアプリケーションに必要なものを選び、Resource Ownerにアクセス権限を要求します。一方ユーザーはClientから要求されているPermissionを確認し、Authorization Serverが定めたポリシーに対して許可を与えます。このようなAuthorization Server中心の仕組みでは、ユーザーの意図しないアクセス許可が行われる、などのリスクもあります。

【関連記事】

「OAuth」の基本動作を知る

http://www.atmarkit.co.jp/fsecurity/rensai/digid01/01.html

RFCとなった「OAuth 2.0」――その要点は？

http://www.atmarkit.co.jp/ait/articles/1209/10/news105.html

UMAの前提とユースケース

　上記の説明を踏まえて、UMAの前提とサポートするユースケースを紹介します。OAuthと共通する部分、そして異なる部分を見ていくことで、UMAの狙いがよりはっきり見えてくるのではないでしょうか。

リソースアクセスを行う主体を拡張（Request Party）

　UMAは、Clientを通してリソースアクセスを行う主体を“Resource Owner以外の第三者や組織”にまで拡張し、「Request Party」として定義することで、OAuth単体では実装できないさまざまなユースケースのサポートを目指しています。


名称	ユースケース
Person-to-self sharing	Clientを利用する自分自身にリソースアクセスを許可する。OAuthで定義されているユースケースと同じ
Person-to-person sharing	Clientを利用する別のユーザーにリソースアクセスを可する
Person-to-organization sharing	Clientを利用する特定の組織もしくはその組織に属する人物に対してリソースアクセスを許可する

図2　UMAがサポートするデータ共有

Resource ServerとAuthorization Serverを分離し、アクセス許可を一元管理

　UMAでは、アクセス対象のProtected ResourceをホストしAPIなどを提供する「Resource Server」と、アクセス許可を管理する「Authorization Server」が分離されています。Resource Ownerは、特定のAuthorization Serverに複数のProtected Resourceをひも付けることで、Clientへのアクセス許可を一元管理できます。

Resource Ownerの定めた認可ポリシーとRequestorのクレームにより定められるアクセス権限

　UMAでは、「誰に対してアクセスを許可するか」「有効期限などを、どのように許可するか」というポリシーをResource Ownerが自ら設定します。Authorization Serverは、Clientを通してリソースアクセスを要求するRequest Partyの識別子や属性情報と「誰に」というポリシーを突き合わせて、認可の対象かどうかを判断します。

　このように、UMAではOAuthとは異なる前提を持つことで、さまざまなデータ共有のユースケースをサポートします。