HOME情報セキュリティ資料・報告書・出版物調査・研究報告書情報セキュリティ技術動向調査(2010 年上期)

本文を印刷する

情報セキュリティ

情報セキュリティ技術動向調査(2010 年上期)

5 User Managed Access

工藤 達雄

1. はじめに

  本報告では 2010 年上半期のアイデンティティ管理技術に関する動向として、User Managed Access [1] の動きを概観する。

2. User Managed Access とは

2.1 背景

  分散環境におけるアクセス管理は、古くて新しい課題である。組織や企業の内部、あるいは信頼関係のある組織間では、ポリシーに基づいてどのようなアクセスを許可するかを判断するサービスをPDP(Policy Decision Point:ポリシー決定点)、PDPの判断に基づいて実際にアクセス制御を実行するサービスをPEP(Policy Enforcement Point:ポリシー実行点)とし、アクセス管理の大元を PDP に集約することが一般的であった。しかしインターネット・サービス同士の Web API による疎結合な連携に対しては、このような旧来の中央集権的なモデルをそのまま当てはめることが難しい場合も少なくない。
  Web API によるインターネット上のサービス連携が広まる中、ユーザの判断に基づくアクセス制御を実現するための仕様として、OAuth [2] [3] の採用が進んでいる。OAuth は、クライアント(Client)がユーザー(Resource Owner)の許可を得てサーバ(Resource Server)内のリソース(Protected Resource)へアクセスするための方法を規定しているが、同仕様では、いくつかの前提を置いている。
  まず Protected Resource の管理権限を持つユーザとClient 側にいるユーザが別の人物であるようなユースケースは、OAuth 仕様では基本的に想定されていない。すなわち Client は Resource Owner の指示を受けて、「その Resource Owner の Protected Resource」に対してアクセスを行うのであり、「別の Resource Owner に属する Protected Resource」にアクセスするものではない。
  次に Resource Server は Client からのアクセスに関してAuthorization Serverにアクセス可否や範囲の決定を委ねるが(つまり前者が PEP、後者が PDP となる)、「Resource Server がどの Authorization Server を信用するか」は事前に Resource Server 自身が選定しており、Resource Owner に選択の余地は無い。このように Resource Server と Authorization Server(多くの場合、Resource Server と同一のドメインに存在する)が密接に結びついているということは、「ユーザは複数の Authorization Server と複数の Client との組み合わせの数だけ、認可管理を行う必要がある」ということを意味する。
  この結果、アクセス許可を求める Client と、実際にサービスを提供する Protected Resource との間の関係管理が、ユーザにとって新たな負担となることは、想像に難くない。たとえば Twitter や Facebook などのサービスと、それらと連携して動作する外部アプリケーションとの間の n 対 n の関係は広がる一方であり。ユーザはどのアプリケーションにどのようなアクセス権限を許可したか、個々のサービスを逐一確認しなくてはならなくなっている。

2.2 User Managed Access のアプローチ

  UMA( User Managed Access )は、データ共有とサービス・アクセスに関する認可をユーザがコントロールできるようにするための Web プロトコルである。前述の課題を解決するために、UMA では次のふたつのコンセプトを導入する。
  第1に、Client に Protected Resouce へのアクセスを試みるよう指示する主体を、Resource Owner とは別のユーザや組織であると定義する。さらに Client へのアクセス権限の付与について、あらかじめ定められたポリシーと、Client が提示した Claim によって、Resource User 不在の状況でも行うことを定義している。これにより、Resource Owner が Client の指示者とは別個の主体であるようなケースにも対応可能としている。
  第2に、Resource Server と Authorization Server との分離である。そして Resource Server がどの Authorization Server と連携するかは、Resource Owner が選択できるようにする。これにより Resource Owner は、権限管理について、自身が選択した Authorization Managerのみを扱えば良いことになる。

3. UMA Core プロトコル概要

  UMA の仕様は、現在 IETF にて議論・策定が進む OAuth 2.0 プロトコル仕様 [4](以下 OAuth 2.0)をベースとしている。ただし、関係するエンティティの役割を以下のように拡張している(図 1)。(なお現時点の UMA 仕様では OAuth 2.0 と異なる名称を用いているが、将来的には OAuth 2.0 に準拠する可能性もある。)


図 1:UMAの登場人物


  • Authorizing User: OAuth 2.0 における Resource Owner。Host 内の Protected Resource に関するアクセス・ポリシー(Requester からのアクセスをどのように許可するか)を Authorization Manager に設定する。

  • Authorization Manager: 同 Authorization Server。Authorizing User の設定したアクセス・ポリシーに従い、Protected Resourceへのアクセス認可決定(policy decision)を行う。

  • Host: 同 Resource Server。Protected Resourceを管理し、Authorization Manager のアクセス認可決定をRequesterに強制(policy enforcement)する。

  • Requester: 同 Client。Requesting Party(Authorizing User、または別のユーザや組織)の指示により、Protected Resource へのアクセスを試みる。

  UMA のプロトコル [5] は、主に次の3 ステップからなる(図 2)。

3.1 トークンの信頼

  まず、Authorizing User によって、Host を Authorization Manager に登録する処理が行われる。これを紹介(introduction)と呼ぶ。紹介によって、Host は Authorization Manager が発行するトークンを「信頼」することになる。
  紹介は、Authorizing Userが Host に対し、自身が利用する Authorization Manager を Host に通知することが起点となる。Host は Web Host Metadata [6] に基づき、Authorization Manager からメタデータを取得する。
  Host はメタデータに記述されているエンドポイント等の情報を利用し、Authorization Manager に、Protected Resource の登録を試みる。まず Authorizing User の同意に基づいて Authorization Manager からトークン(Host Access Token)を取得し、次に Protected Resource の情報を Authorization Manager に登録する。
  もし Host と Authorization Manager が事前に連携したことがない場合には、Host が自身の情報を Authorization Manager に動的に登録し、Authorization Manager が Host にクライアント ID(およびシークレット)を返却する処理(dynamic registration)[7] が行われることになる。


図 2:UMAプロトコルの3つのステップ

3.2 トークンの取得

  Requester は Requesting Party(Protected Resource の所有者(Authorizing User)本人であるケース、それ以外の第三者(個人もしくは組織・法人)であるケースの、どちらもありうる)の指示を受けて、Protected Resource へのアクセスを試みる。
  Protected Resource へのアクセス試行を受けた Host は、Requester が Protected Resource へのアクセスに必要な access token を提示してきたかどうかを確認する。もし access token が存在しない場合には、Host は Requester を Authorization Manager に誘導する。
  Requester は Authorizaiton Manager に、どのようなアクセスを行いたいか(scope)を提示し、access token の取得を試みる。この要求に対する Authorization Manager の応答は 3 種類あり、access token の発行、発行拒否、さらなる情報(Claim)の要求、のいずれかとなる。
  Authorization Manager の応答が「Claim の要求」であった場合、Requester は Authorization Manager が求める種類の Claim を準備し、Authorization Manager に提出する。Claim [8] は JSON 型式の文書であり、access token の取得に必要な情報が含まれる。Claim を受け取った Authorization Manager は Claim を確認し、再度、access token の発行、発行拒否、さらなる情報(Claim)の要求、を行う。

3.3 トークンの利用

  Authorizaiton Manager から access token の取得に成功した Requester はその access token を Host に提示し、Protected Resource へのアクセスを試みる。
  Host はその access token を自身で確認するか、Authorization Manager に検証を依頼し、有効であることを確認した上で、Protected Resource へのアクセスを許可する。
  以上のステップにより、Requester は Authorizing User の設定したポリシーに従い、目的の Protected Resource にアクセスすることができるようになる。

4. 現在の状況

  UMA の活動は、Kantara Initiative 内のワークグループ(WG)にて行われている。本 WG は 2009 年に開設され、PayPal 社の Eve Maler 氏が議長となり、ユースケース定義や仕様策定を進めている。
  今年に入り、ニューカッスル大学の SMART(Student-Managed Access to Online Resources)プロジェクト [9] によるプロトタイプ実装が公開されるなどの進展が見られる。

5. まとめ

  OAuth 仕様、とくに現在策定が進行中のバージョン 2.0 は、今後コンシューマ / エンタープライズを問わず、様々な分野での適用が期待される。しかしそれは同時に、OAuth クライアントと OAuth によって保護されたリソースとの組み合わせが爆発的に増加することを意味する。
  これを管理可能な状態に維持するために、エンドユーザーにポリシーの管理を委ねることは、解決方法のひとつとして有力であろう。UMA ワークグループの取組みは、今後ユーザー中心のサービス連携を実現する上で、非常に有用であると考えられる。

以上

参考文献

[1] Home - WG - User Managed Access - Kantara Initiative
http://kantarainitiative.org/confluence/display/uma/Home
[2] 情報セキュリティ技術動向調査(2009 年上期) 8 アイデンティティ管理関連技術OAuthの動向
http://www.ipa.go.jp/security/fy21/reports/tech1-tg/a_08.html
[3] OAuth Community Site
http://oauth.net/
[4] The OAuth 2.0 Protocol
http://tools.ietf.org/html/draft-ietf-oauth-v2
[5] UMA 1.0 Core Protocol - WG - User Managed Access - Kantara Initiative
http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol
[6] Web Host Metadata
http://tools.ietf.org/html/draft-hammer-hostmeta
[7] OAuth Dynamic Client Registration Protocol
http://tools.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt
[8] Claims 2.0 - WG - User Managed Access - Kantara Initiative
http://kantarainitiative.org/confluence/display/uma/Claims+2.0
[9] Student-Managed Access to Online Resources
http://smartjisc.wordpress.com/

 

目次へ 次へ