Access」について紹介します。Access」、略して「UMA」(読み方は「ウーマ」)というWebベースのアクセス管理プロトコルを紹介します。これまでの連載を読まれた方は、アクセス管理というと「OAuth」を思い浮かべるでしょう。OAuthにより、あるサービス上のユーザーデータへのアクセス権限を、外部のアプリケーションに安全に付与できます。OAuthがサポートしているのはユーザーが外部アプリケーションを通して自分のデータにアクセスするユースケースのみであり、他人とデータを共有するというユースケースは想定されていません。他人とのデータ共有というと、設定を変更してサービス内の公開範囲を限定したり、秘密のURLを教え合うことで、アクセス可能なユーザーを制限する手法が一般的です。前者には共有対象が同一サービス利用者に制限されてしまう、後者には秘密のURLの漏洩により意図せぬ公開の可能性があるなど、サービスを超えたデータ共有には課題があります。UMAはオンラインサービスにおけるデータ共有やリソースアクセスの認可処理をユーザーがコントロールする世界を目指しています。本稿ではOAuthとの違いを中心に、UMAの概要を紹介します。OAuthの前提UMAの特徴を理解するに当たって、OAuthの前提をいくつか振り返っておきましょう。Ownerの「代わり」としてリソースにアクセス現在、OAuthを用いたさまざまなアプリケーションが提供されています。「この画像をSNSの友人に共有する」といった機能を利用すると、OAuthにより第三者へのデータ共有が行われているように感じられますが、アプリケーションはあくまで“ユーザーの代わりにSNSに投稿”しているだけであって、友人に共有しているのはSNSの機能です。Owner)が、外部のアプリケーション(Client)に対し、自らのデータへのリソースアクセスを許可します。言い換えると、OAuthではユーザーが自分以外の第三者に対してリソースアクセスを許可することを想定していません。よって、「AさんがBさん(別のユーザー)にプライベートな画像を共有」「Cさんが雇用先である企業(組織)に対して決済サービスに登録済みの住所情報を公開」といった機能は、OAuth単体では実装できません。複数のSNSに投稿を行うアプリケーションを利用する場合、ユーザーはそれぞれのサービス上でアプリケーションにリソースアクセスを許可する必要があります。Serverは、一意にひも付いています。Serverごとに分散されてしまいます。よって、アプリケーションの利用が増えるに従い、ユーザーの管理コストがますます大きくなってしまいます。Serverにより決められています。Ownerにアクセス権限を要求します。Serverが定めたポリシーに対して許可を与えます。2.0」——その要点は?http://www.atmarkit.co.jp/ait/articles/1209/10/news105.htmlUMAの前提とユースケース上記の説明を踏まえて、UMAの前提とサポートするユースケースを紹介します。OAuthと共通する部分、そして異なる部分を見ていくことで、UMAの狙いがよりはっきり見えてくるのではないでしょうか。Party」として定義することで、OAuth単体では実装できないさまざまなユースケースのサポートを目指しています。sharingClientを利用する自分自身にリソースアクセスを許可する。Server」が分離されています。Resourceをひも付けることで、Clientへのアクセス許可を一元管理できます。Ownerが自ら設定します。Partyの識別子や属性情報と「誰に」というポリシーを突き合わせて、認可の対象かどうかを判断します。このように、UMAではOAuthとは異なる前提を持つことで、さまざまなデータ共有のユースケースをサポートします。Initiative/IETFのワーキンググループにおいて進められています。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。