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

» 2013年05月08日 18時00分公開

[ritou（OpenID Foundation Japan），＠IT]

UMAの処理概要

　では、上記の特徴を踏まえて、UMAの処理の流れの内容を説明します。ここでは具体的なイメージを持っていただくために、「Aliceがプライベートな画像をBobに共有する」ユースケースを例にとって説明します。

登場人物（要素）と3つのフェーズ

　UMAでは、以下の五者により処理が行われます。ここではFlickr、Facebook、PicasaがUMAに対応していると仮定します。


主体	役割
Resource Owner	データアクセスの対象となるリソースの持ち主（Alice）
Resource Server	Resource Ownerのリソースを管理しているサービス（Flickr）
Authorization Server	リソースアクセスを管理するサービス（Facebook）
Requesting Party	データアクセスを行う主体（Bob）
Client	Requesting Partyにデータアクセスを提供するサービス／アプリケーション（Picasa）

　ここでの互いの関係は、以下のようになります（引用元：Kantara Initiative）。

図4　Aliceがプライベートな画像をBobに共有するケースでの各者の関係

　UMAの処理には3つのフェーズがあります。

フェーズ1：protect resources（リソース登録）
フェーズ2：get authorization（認可処理）
フェーズ3：access resource（リソースアクセス）

　以下、それぞれのフェーズでどんな処理が行われるかを見ていきましょう。

フェーズ1：protect resources

　Aliceは初めに、Flickrの共有設定画面などで、アクセス管理サービスとしてFacebookを指定します。このフェーズはResource Server（Flickr）-Resource Owner（Alice）-Authorization Server（Facebook）の三者間の処理となります。

Resource Serverは、Authorization Serverに自らを登録する（事前に登録、もしくは動的な登録）
Resource Ownerは、Authorization Server上でResource Serverにリソースを登録させるための許可を与える（Facebookは、AliceにFlickrの画像をアクセス管理することを確認する）
Resource Serverは、Authorization Serverにリソースを登録する（Aliceの画像をアクセス管理の対象にする）
Resource Ownerは、Authorization Serverに登録されたリソースの認可ポリシーを設定する（Facebook上で「この画像はBobのみに一定期間共有する」のように設定する）

　1でResource ServerとAuthorization Serverの事前のひも付けがない場合、OAuth 2.0のDynamic Client Registrationを用いた動的な登録が行われます。なお、3で登録されるリソースとアクセス方法、4のポリシー設定方法などはUMAの仕様対象外です。ユースケースによっては、3のAPI仕様まで標準化されることもあるかもしれません。

　またResource Server/Authorization Serverには、ユーザーの意思決定に基づくアクセスコントロールを可能にする実装が求められます。

　ここまでの処理で、AliceがFlickrで管理している画像のアクセス管理をFacebookで行うための手続きは完了です。

フェーズ2：get authorization

　Aliceはメールやメッセージサービスなどで、Bobに「Flickr」の画像のURLを教えます。BobはAliceから受け取ったURLを「Picasa」に入力し、画像の閲覧を試みます。このフェーズはResource Server、Authorization Server、Client、Request Partyの四者による処理となります。

Request Partyからの指示を受け、ClientはResource Serverにアクセスする（PicasaはFlickrのURLにHTTP GETでアクセスする）
Resource Serverは、Authorization Serverなどの情報を返す（Flickrは画像がFacebookによりアクセス管理されていることを伝える）
Clientを利用するRequest Partyは、リソースにひも付くAuthorization Serverにリダイレクトされる（BobはFacebookにリダイレクトされる）
Authorization Serverは、Resource Ownerが事前に設定したポリシーに沿って認可処理を行う（FacebookはBobのメールアドレスなどでAliceが設定した共有相手であることを確認）

　ここでも、1のClientからResource Serverへのアクセス方法、4の認可処理の詳細はUMAの仕様対象外となります。

　ここまでの処理によって、Bobからのリソースアクセスの要求であることを確認したFacebookは、Picasaに認可を与えます。OAuth 2.0と同様に、Clientはこのフェーズを通してリソースアクセスのためのトークンを取得します。

フェーズ3：access resource

　ここでようやく、PicasaはBobの代わりにFlickrからAliceの画像を取得します。このフェーズはResource Server、Authorization Server、Clientの三者による処理となります。

Clientは、Resource Serverにトークンを提示してリソースアクセス（Picasaはフェーズ2で取得したトークンをリクエストに含む）
Resource Serverは、受け取ったトークンと自らの情報をAuthorization ServerのToken検証用エンドポイントに渡し、認可内容を確認する（FlickrはFacebookにトークンの有効性を問い合わせる）
有効なトークンであることが確認できたら、Resource ServerはClientにリソースを渡す（FlickrはPicasaに画像データを渡す）

　ここまでの流れで、Resource OwnerのAliceがAuthorization Serverやポリシーを決定し、データ共有がなされるまでのフローを紹介しました。

実装に向けた取り組みと接続性の検証

　すでにUMAの実装に取り組んでいるプロジェクトとして、学生情報のアクセス管理を目的とした「SMART project」、エンタープライズ分野のユースケースを検討する「OXAuth Project」などがあります。

　こうしたプロジェクトではユースケースの検討だけではなく、Java、Pythonなどオープンソースのライブラリ開発やInterop（相互接続性の検証）も行われています。OpenID Connectの仕様策定と同様、さまざまなユースケースに導入しやすく、かつ実装が簡単なプロトコルとするべく策定が進められている印象を持ちます。興味を持たれた方は、ぜひ、下記の情報を参考にしてみてください。

【関連リンク】

UMA Implementations

http://kantarainitiative.org/confluence/display/uma/UMA+Implementations

UMA Interop 1

http://osis.idcommons.net/wiki/UMA1:UMA_Interop_1

UMAとOAuth 2.0、OpenID Connectの関係

　最後に、UMAとOAuth 2.0、OpenID Connectといった仕様どうしの関係についても整理しておきましょう。

　まずUMAとOAuth 2.0の関係ですが、全体の処理の中で三者間のリソースアクセスとなる部分には、OAuth 2.0のAuthorization Code Grantが利用されています。

　一方OpenID Connectとの関係については、Authorization ServerがOpenID ConnectのRPとなり、取得した属性情報をRequest Partyへの認可可否の判断に利用するという連携が検討されています。Resource Server、Authorization Server、Clientが動的に連携する場合は特に、標準的なクレーム定義を利用できるメリットは大きくなるでしょう。

　Kantara Initiative UMA WGのChairであるEve Malerは、自らのブログ記事で、これら3つのプロトコルの関係を説明しています。OAuth 2.0以外はまだ仕様策定中ではあるものの、APIエコノミーにおけるアクセス管理に関するプロトコルとして、今後ますます注目が集まると考えられます。

【関連リンク】

A NEW VENN OF ACCESS CONTROL FOR THE API ECONOMY

http://blogs.forrester.com/eve_maler/12-03-12-a_new_venn_of_access_control_for_the_api_economy

最後に

　OAuth 2.0による外部アプリケーションからのリソースアクセスが普及し始めているコンシューマ分野において、UMAが目指している「サービスを超えたデータ共有」へのニーズはたくさんあるでしょう。クラウドサービスとの連携が進んでいるエンタープライズ分野でも、UMAがサポートするユーザー対企業のデータ共有のユースケースは魅力的に映るでしょう。本稿をきっかけとして、OAuth、OpenID Connectとともに、UMAにも興味を持っていただければ幸いです。

　次回は、特にエンタープライズ分野で企業内の人事DBとクラウドサービスとの連携手段として注目を集めているSCIM（System for Cross-Domain Identity Management）を紹介します。