ユーザー中心のアクセス管理の実現を目指すUser Managed Access：デジタル・アイデンティティ技術最新動向（8）（2/2 ページ）
今回は、ユーザー中心のアクセス管理やサービスを超えたデータ共有の実現を目指して策定が進むアクセス管理プロトコル、「User Managed Access」について紹介します。
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）。
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）を紹介します。
【関連記事】
「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
「OpenID Connect」を理解する
http://www.atmarkit.co.jp/ait/articles/1209/27/news138.html
著者プロフィール
▼Ryo Ito（ritou）
OpenID Foundation Japan Evangelist。OpenID Connectのコントリビュータとして仕様策定に関わっている。 業務ではアイデンティティ技術を用いたSNSサービスの強化を検討しており、個人ブログではOpenID／OAuthについて情報発信を行っている。
Copyright © ITmedia, Inc. All Rights Reserved.