情報処理装置、情報処理方法
【課題】 OAuthクライアントがリソースプロバイダから動的にアクセス範囲情報を取得できるようになり、アクセス範囲情報の管理を容易にするための技術を提供すること。
【解決手段】 サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信し、サービス情報が表すサービスを選択可能に表示する為の表示情報を生成し、該生成した表示情報をユーザ端末装置に対して送信する。ユーザ端末装置側で選択されたサービスを示す選択サービス情報を該ユーザ端末装置から受信し、該受信した選択サービス情報から生成した認証要求を、該選択されたサービスをサーバ装置が提供する前に認証を行う認証サーバ装置に対して送信する。認証サーバ装置による認証が成功した場合には、サーバ装置に対して選択されたサービスを提供させるよう指示する。
【解決手段】 サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信し、サービス情報が表すサービスを選択可能に表示する為の表示情報を生成し、該生成した表示情報をユーザ端末装置に対して送信する。ユーザ端末装置側で選択されたサービスを示す選択サービス情報を該ユーザ端末装置から受信し、該受信した選択サービス情報から生成した認証要求を、該選択されたサービスをサーバ装置が提供する前に認証を行う認証サーバ装置に対して送信する。認証サーバ装置による認証が成功した場合には、サーバ装置に対して選択されたサービスを提供させるよう指示する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザによる認可処理に基づいて、Webアプリケーション間でユーザデータを交換する為の技術に関するものである。
【背景技術】
【０００２】
従来、ユーザはWebブラウザを用いてWebアルバムなどのWebアプリケーションを使用する際には、事前にユーザIDとパスワードを用いてユーザ認証を行うことで、個人データの取得や作成をすることができた。また、近年、写真やSNS、オフィス系サービスなど、複数のWebアプリケーションを日常的に使い分けるユーザが増えつつあり、異なるWebアプリケーション間でユーザデータを共有する機会が増えてきていた。
【０００３】
しかし、異なるWebアプリケーション間でユーザデータを共有するには、それら第３者のWebアプリケーションに、ユーザは秘匿性の高いユーザＩＤとパスワードを通知する必要する必要があった。もし、これらユーザIDとパスワードが漏えいした場合には、入手した第3者によってユーザデータを取得できてしまうというリスクがある。
【０００４】
そこで、近年では、IETF標準のThe OAuth 1.0 Protocol (http:／／tools.ietf.org／html／rfc5849)が注目されている。OAuthプロトコルを用いることによって、ユーザはアカウント情報を第3者のWebアプリケーションに通知することなく、Webアプリケーション間でセキュアにユーザデータを共有することができるようになる。
【０００５】
図１は、Webブラウザを用いたユーザと、印刷サービスと、オフィス文書サービスの3者間で、OAuthプロトコルを用いた認可処理のフローを示したものである。印刷サービス１０２はユーザ１０１によって指定された文書を印刷するインターネットのサービスであり、オフィス文書サービス１０４は、ユーザ１０１のオフィス文書を管理するインターネットのサービスと仮定する。
【０００６】
認可サーバ１０３は、オフィス文書サービス１０４と信頼関係が事前に結ばれており、オフィス文書サービス１０４は認証情報として受信したトークンを認可サーバ１０３に送信する。そして、認可サーバ１０３が受信したトークンを検証することによって、外部Webアプリケーションによるユーザデータへのアクセスが認可されているかどうか認可サーバ１０３を用いて確認する。OAuthプロトコルとしては、印刷サービス１０２はOAuthクライアントとなり、認可サーバ１０３はOAuthサーバとなり、オフィス文書サービス１０４はリソースプロバイダとなる。
【０００７】
まず、ユーザ１０１はWebブラウザを用いて、印刷サービス１０２にアクセスする(1)。そして、ユーザ１０１が、外部のオフィス文書サービス１０４内の文書の印刷を要求した場合には、印刷サービス１０２はオフィス文書サービス１０４へのアクセス認可を得るために、認可サーバ１０３にユーザをリダイレクトする(2)。
【０００８】
図２は、ユーザ１０１のWebブラウザへ送信されるHTTPリダイレクトの一例である。リダイレクト先のURLにはWeb APIへのアクセス範囲を示すscopeパラメータを含み、印刷サービス１０２は、このscopeパラメータの範囲内でのWeb APIの利用許可を求めるものである。
【０００９】
そして、ユーザ１０１が印刷サービス１０２によるオフィス文書サービスへ１０４のアクセスを認可した場合には、OAuthの認証コードを付与して、認可サーバ１０３がユーザ１０１を印刷サービス１０２にリダイレクトする(3)。そして、印刷サービス１０２は、発行された認証コードと引き換えに、認可サーバ１０３からOAuthのアクセストークンを取得する(4)。そして、印刷サービス１０２は、取得したアクセストークンを用いて、オフィス文書サービス１０４のWeb APIを呼び出し、ユーザ１０１個人のオフィス文書を取得して印刷できるようになる(5)。
【００１０】
この認可処理の過程において、ユーザ１０１のIDやパスワードは印刷サービス１０２に直接送信されることなく、印刷サービス１０２はユーザ１０１個人のオフィス文書にアクセスできるようになる。
【００１１】
先行技術として、信頼できる第3者認証機関に信用証明書を提示することによって、ユーザの代わりとなって、あるWebアプリケーションが別のWebアプリにアクセスできるように認可するものがあった(特許文献１)。また、あるサービスが、別サーバ内のユーザデータにアクセス要求する度に、ユーザに確認画面を出し、認可後にユーザデータを提供するものがあった（特許文献２）。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開2003-099401号公報
【特許文献２】US6601092
【発明の概要】
【発明が解決しようとする課題】
【００１３】
リソースプロバイダのバージョンアップによってWeb APIの仕様を変更した場合には、OAuthのscopeパラメータが不正になるため、OAuthクライアントは正しい認可メッセージをOAuthサーバに送信できなかった。
【００１４】
例えば図１の場合、オフィス文書サービス１０４のWeb APIがバージョンアップし、サービスを提供するWeb APIの提供範囲が変更された場合、印刷サービス１０２は図2におけるscopeパラメータを更新する必要があった。従来のOAuthクライアントとしては、このscopeパラメータは、リソースプロバイダのWeb APIの仕様に基づいて固定値として保存しておくものが一般的であった。もし、リソースプロバイダのWeb APIが変更された場合には、scopeパラメータをその都度手作業で更新する。もし、scopeパラメータを更新せずにOAuthの認可フローを実行すると、リソースプロバイダにアクセスした際にアクセス範囲エラーとなり、ユーザデータにアクセスすることができなくなる。
【００１５】
本発明は以上の問題に鑑みてなされたものであり、OAuthクライアントがリソースプロバイダから動的にアクセス範囲情報を取得できるようになり、アクセス範囲情報の管理を容易にするための技術を提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明の目的を達成するために、例えば、本発明の情報処理装置は、サーバ装置、ユーザ端末装置、認証サーバ装置、とデータ通信可能に接続されている情報処理装置であって、前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信する受信手段と、前記サービス情報が表すサービスを選択可能に表示する為の表示情報を生成し、該生成した表示情報を前記ユーザ端末装置に対して送信する手段と、前記ユーザ端末装置側で選択されたサービスを示す選択サービス情報を該ユーザ端末装置から受信し、該受信した選択サービス情報から生成した認証要求を、該選択されたサービスを前記サーバ装置が提供する前に認証を行う前記認証サーバ装置に対して送信する手段と、前記認証サーバ装置による認証が成功した場合には、前記サーバ装置に対して前記選択されたサービスを提供させるよう指示する手段とを備えることを特徴とする。
【発明の効果】
【００１７】
本発明の構成によれば、OAuthクライアントは、リソースプロバイダから動的にアクセス範囲情報を取得できるようになり、アクセス範囲情報の管理が容易になる。
【図面の簡単な説明】
【００１８】
【図１】従来のOAuthプロトコルを用いた認可フローの一例を示す図。
【図２】リダイレクトメッセージの一例を示す図。
【図３】システムの構成例を示す図。
【図４】情報処理装置２０１が行う処理のフローチャート。
【図５】ステップＳ１１２における処理の詳細を示すフローチャート。
【図６】ステップＳ２１０における処理の詳細を示すフローチャート。
【図７】システムの処理手順を示す図。
【図８】ＸＲＤ文書の一例を示す図。
【図９】アクセス範囲情報の取得要求、アクセス範囲情報、の一例を示す図。
【図１０】画面の表示例、選択用ＨＴＭＬページ、を示す図。
【図１１】ＧＥＴリクエストの一例、リダイレクトメッセージの一例、を示す図。
【図１２】情報処理装置２０１が行う処理のフローチャート。
【図１３】システムの処理手順を示す図。
【発明を実施するための形態】
【００１９】
以下、添付図面を参照し、本発明の好適な実施形態について説明する。なお、以下説明する実施形態は、本発明を具体的に実施した場合の一例を示すもので、特許請求の範囲に記載した構成の具体的な実施例の一つである。
【００２０】
［第１の実施形態］
先ず、本実施形態に係るシステムの構成例について、図３を用いて説明する。図３に示す如く、本実施形態に係るシステムは、情報処理装置２０１、サーバ（サーバ装置）２０７、認可サーバ（認証サーバ装置）２０８、ユーザ端末装置２０９，を有し、それぞれの装置はデータ通信が可能なように接続されている。それぞれの装置の構成やそれぞれの装置が行う処理については、以下に詳しく説明する。
【００２１】
情報処理装置２０１が行う処理について、同処理のフローチャートを示す図４のフローチャートを用いて説明する。なお、この説明では、情報処理装置２０１以外の各装置の動作についても説明する。
【００２２】
ユーザ端末装置２０９は、図７の手順（１）のように、Webブラウザを用いて情報処理装置２０１（印刷サービス）にアクセスし、サーバ２０７（外部のオフィス文書サービス）内に保存しているユーザのオフィス文書（ユーザデータ）の印刷を要求する。
【００２３】
この要求を受信した情報処理装置２０１は、サーバ２０７によって公開されているディスカバリーサービス（ここではhttps:／／docs.sample.org／discovery）に対して、後述するＸＲＤ文書の取得要求を送信する。
【００２４】
サーバ２０７はこの取得要求に応じてＸＲＤ文書を送信するので、ステップＳ１０２においてサービス情報解析部２０２は、このＸＲＤ文書を受信する。ステップＳ１０３においてサービス情報解析部２０２は、この受信したＸＲＤ文書を、XMLパーサを用いて解析する。ここで、印刷サービスは、この固定URLのディカバリサービスを用いることによって、常に最新のサービス内容を取得できるものとする。
【００２５】
このＸＲＤ文書の一例を図８に示す。図８に示したＸＲＤ文書には、オフィス文書サービスのWeb APIのアクセス範囲情報取得用URL、フィード文書取得用URL、認証コード取得用URL、アクセストークン取得用URL、が含まれている。これらのURLの種別は、各Service要素の子要素であるType要素の要素内容に基づいて識別することができる。
【００２６】
次に、ステップＳ１０４では、記述特定部２０３は、以下で用いる変数default_uriと変数scope_discoveryを適当な値に初期化する。次にステップＳ１０５では、記述特定部２０３は、ＸＲＤ文書中の全てのService要素について解析したか否かを判断する。この判断の結果、まだ解析していないService要素が残っている場合には、処理はステップＳ１０６に進み、全てのService要素を解析した場合には、処理はステップＳ１１１に進む。
【００２７】
ステップＳ１０６では、記述特定部２０３は、ＸＲＤ文書中において未解析のService要素のType要素の内容を解析する。そしてステップＳ１０７では、記述特定部２０３は、この解析したType要素の内容がアクセス範囲情報を提供するサービスであるか否かを判断する。この判断の結果、この解析したType要素の内容がアクセス範囲情報を提供するサービスである場合には、処理はステップＳ１０８に進む。一方、この解析したType要素の内容がアクセス範囲情報を提供するサービスではない場合は、処理はステップＳ１０９に進む。
【００２８】
ステップＳ１０８では、記述特定部２０３は、アクセス範囲情報を提供するサービスであることを示すType要素が属するService要素の子要素であるURI要素の要素内容を変数scope_discoveryに設定する。
【００２９】
ステップＳ１０９では、記述特定部２０３は、ステップＳ１０６で解析したType要素の内容が、ユーザのリソース情報を提供するサービスであるか否かを判断する。この判断の結果、ユーザのリソース情報を提供するサービスである場合には、処理はステップＳ１１０に進み、ユーザのリソース情報を提供するサービスではない場合には、処理はステップＳ１０５に戻る。
【００３０】
ステップＳ１１０では、ユーザのリソース情報を提供するサービスであることを示すType要素が属するService要素の子要素であるURI要素の要素内容を変数default_uriに設定する。ユーザのリソース情報は、RFC5023 The Atom Publishing Protocol(http:／／tools.ietf.org／html／rfc5023)に基づいて取得するものとする。
【００３１】
ステップＳ１１１では、アクセス範囲情報取得部２０４は、変数scope_discoveryに初期値以外の何らかの値が設定してあるか否かを判断する。この判断の結果、変数scope_discoveryに初期値以外の何らかの値が設定してある場合には、処理はステップＳ１１２に進む。一方、変数scope_discoveryに初期値以外の何らかの値が設定してない場合は、処理はステップＳ１１４に進む。
【００３２】
ステップＳ１１２では、アクセス範囲情報取得部２０４は、変数scope_discoveryに設定されているURIを用いて、アクセス範囲情報の取得要求をサーバ２０７に送信する。この取得要求、取得要求に応じてサーバ２０７から返信されるアクセス範囲情報、の一例を図９に示す。図９（ａ）は、情報処理装置２０１がサーバ２０７に対して送信する、アクセス範囲情報の取得要求の一例を示す。図９（ｂ）は、この取得要求に応じてサーバ２０７が情報処理装置２０１に対して送信するアクセス範囲情報の一例を示す。図９（ｂ）に示す如く、アクセス範囲情報はＸＭＬ形式のデータである。
【００３３】
図９（ｂ）のアクセス範囲情報には、３つのアクセス範囲情報が含まれており、各scope要素の要素内容がURL形式のアクセス範囲情報となる。図９（ｂ）では、この３つのXML形式のアクセス範囲情報のそれぞれは、文書サービス、スプレッドシートサービス、PDFサービス、に対応したものである。
【００３４】
また、scope要素のuse属性の値が”default”である場合、このscope要素に対応するサービス（アクセス範囲）の使用を、標準設定において指定してあることを示している。また、scope要素のuse属性の値が”optional”である場合、このscope要素に対応するサービス（アクセス範囲）の使用は標準設定では指定しておらず、ユーザによって任意に指定するものであることを示している。
【００３５】
また、scope要素のicon属性は、このscope要素に対応するサービス（アクセス範囲）を表現したアイコン画像へのURLを示している。
【００３６】
次に、上記のステップＳ１１２における処理の詳細について、図５のフローチャートを用いて説明する。なお、この説明では、情報処理装置２０１がサーバ２０７から図９（ｂ）に示したアクセス範囲情報を受信した場合を例にとっている。しかし、以下の説明は、図９（ｂ）に示したアクセス範囲情報以外のアクセス範囲情報を受信した場合であっても同様に適用することができる。
【００３７】
ステップＳ２０２では、アクセス範囲情報取得部２０４が送信した要求に応じてサーバ２０７から送信されたアクセス範囲情報を、アクセス範囲情報解析部２０５が受信する。そしてアクセス範囲情報解析部２０５が有する記述解析部が、この受信したアクセス範囲情報を解析する。
【００３８】
ステップＳ２０３では、アクセス範囲情報解析部２０５は、以下の処理で用いる変数scopeListをリスト型で初期化する。即ち、変数scopeListに対して複数個の構造体を格納できるようにする。
【００３９】
ステップＳ２０４では、アクセス範囲情報解析部２０５は、受信したアクセス範囲情報中における、ルートのscopes要素以下の全てのscope要素を解析したか否かを判断する。この判断の結果、全てのscope要素を解析した場合には、処理はステップＳ２１０に進み、まだ解析していないscope要素が残っている場合には、処理はステップＳ２０５に進む。
【００４０】
ステップＳ２０５では、アクセス範囲情報解析部２０５は、変数（構造体）scopeを適当な値に初期化する。ステップＳ２０６では、アクセス範囲情報解析部２０５の属性解析部が、未解析のscope要素のuse属性の値を、変数scopeのメンバー変数useに設定する。ステップＳ２０７では、アクセス範囲情報解析部２０５の属性解析部が、未解析のscope要素のicon属性の値を、変数scopeのメンバー変数iconに設定する。ステップＳ２０８では、アクセス範囲情報解析部２０５の属性解析部が、未解析のscope要素の要素内容を変数scopeのメンバー変数uriに設定する。
【００４１】
ステップＳ２０９では、アクセス範囲情報解析部２０５の属性解析部は、ステップＳ２０６〜Ｓ２０８で確定した変数scopeを、変数scopeListに追加登録する。
【００４２】
ステップＳ２１０では、アクセス範囲情報解析部２０５の選択画面生成部は、変数scopeListを用いて、サーバ２０７が提供可能なサービスを選択可能に表示する為の選択用ＨＴＭＬページ（表示情報）を生成する。そしてアクセス範囲情報解析部２０５の選択画面生成部は、この該生成した選択用ＨＴＭＬページを、ユーザ端末装置２０９に対して送信する。
【００４３】
ステップＳ２１０における処理の詳細について、図６のフローチャートを用いて説明する。なお、図６のフローチャートの各ステップにおける処理の主体は何れも、アクセス範囲情報解析部２０５の選択画面生成部である。
【００４４】
ステップＳ３０２では、ユーザ端末装置２０９に送信するレスポンスの出力ストリームを初期化する。ステップＳ３０３では、html要素の開始タグとhead要素を出力ストリームに対して出力する。ステップＳ３０４では、body要素の開始タグと、form要素の開始タグを出力ストリームに対して出力する。ステップＳ３０５では、変数scopeListに含まれる全てのscopeオブジェクトを解析したか否かを判断する。
【００４５】
この判断の結果、全てのscopeオブジェクトを解析している場合は、処理はステップＳ３１２に進み、まだ解析していないscopeオブジェクトが残っている場合は、処理はステップＳ３０６に進む。
【００４６】
ステップＳ３０６では、div要素の開始タグを出力ストリームに対して出力する。ステップＳ３０７では、未解析のscopeオブジェクトのメンバ変数useの値が”default”と等しいか否かを判断する。この判断の結果、等しい場合には、処理はステップＳ３０８に進み、等しくない場合は、処理はステップＳ３０９に進む。
【００４７】
ステップＳ３０８では、”checkbox”を値とするtype属性と、”scope”を値とするname属性と、scopeのメンバ変数uriを値とするvalue属性と、checked属性を含むinput要素を出力ストリームに対して出力する。
【００４８】
ステップＳ３０９では、”checkbox”を値とするtype属性と、”scope”を値とするname属性と、scopeのメンバ変数uriを値とするvalue属性と、を含むinput要素を出力ストリームに対して出力する。
【００４９】
ステップＳ３１０では、未解析のscopeオブジェクトのメンバ変数iconを値とするsrc属性を含むimg要素を出力ストリームに対して出力する。ステップＳ３１１では、div要素の終了タグを出力ストリームに対して出力する。
【００５０】
ステップＳ３１２では、form要素の終了タグと、body要素の終了タグと、html要素の終了タグを出力ストリームに対して出力する。そして、ステップＳ３１３では、レスポンスの出力ストリームをクローズする。
【００５１】
このようにして生成した出力ストリームを、上記の選択用ＨＴＭＬページとしてユーザ端末装置２０９に対して送信する。上記の処理により生成される選択用ＨＴＭＬページを図１０（ｂ）に示す。また、この選択用ＨＴＭＬページを受信したユーザ端末装置２０９の表示画面に表示される、選択用ＨＴＭＬページの画面の表示例を図１０（ａ）に示す。
【００５２】
図１０（ａ）に示した画面上には、form要素以下の各div要素に各サービスを利用するか否かのチェックボックスと、そのサービスを表現するアイコン画像とが配されている。図９（ｂ）においてサービスhttps:／／docs.sample.org／feedを含むscope要素のuse属性は”default”であるため、図１０（ａ）の画面でこのサービスに対応するチェックボックスは標準設定で選択状態にある。
【００５３】
ユーザ端末装置２０９のユーザは、図１０（ａ）の画面において、利用するサービスに対応するチェックボックスを指示し、その後「ＯＫ」ボタンを指示する。これによりユーザ端末装置２０９からは、form要素のaction属性で指定したCGIに対して、ユーザの選択したチェックボックスの内容がGETリクエストのクエリパラメータとして送信される。このクエリパラメータには、ユーザが図１０（ａ）の画面で選択したサービスに関するアクセス範囲情報が含まれている。
【００５４】
図１１（ａ）に、図１０（ａ）の画面において、ユーザが文書サービスとスプレッドシートサービスのチェックボックスを選択した場合に、CGIに送信されるGETリクエストの内容を示す。
【００５５】
ステップＳ２１１では、アクセス範囲情報解析部２０５の選択範囲解析部は、この送信されたクエリパラメータを受信する。そしてステップＳ２１２では、アクセス範囲情報解析部２０５の選択範囲解析部は、この受信したクエリパラメータを解析する。
【００５６】
ステップＳ１１３では、アクセス範囲情報解析部２０５の選択範囲解析部は、この解析により判明した「ユーザが選択したサービス」をOAuthのscopeパラメータに設定する。
【００５７】
一方、ステップＳ１１４では、アクセス範囲情報解析部２０５の選択範囲解析部は、変数default_uriのURIをOAuthのscopeパラメータに設定する。
【００５８】
ステップＳ１１５では、認可要求送信部２０６は、ユーザ端末装置２０９を認可サーバ２０８にリダイレクトすべく、認可サーバ２０８に対して、リダイレクトメッセージを送信する。
【００５９】
ステップＳ１１３の後にステップＳ１１５において送信されるリダイレクトメッセージを図１１（ｂ）に示す。このリダイレクトメッセージでは、ステップＳ１１２で取得したアクセス範囲情報をURLエンコード変換してscopeパラメータに設定している。
【００６０】
ステップＳ１１４の後にステップＳ１１５において送信されるリダイレクトメッセージを図２に示す。このリダイレクトメッセージでは、scopeパラメータには１つのURLを設定し、情報処理装置２０１は、１つのWeb APIへのアクセス許可を求める。
【００６１】
以降の処理は、図７のOAuthプロトコルの認可フローに従い、情報処理装置２０１によるサーバ２０７へのアクセスを認可した場合には、図７の手順（５）のように、ユーザ端末装置２０９を情報処理装置２０１にリダイレクトする。その際、認可サーバ２０８から取得した認証コードを用いて、図７の手順（６）のように、認可サーバ２０８からアクセストークンを取得する。そして、取得したアクセストークンを用いて、サーバ２０７から、そのユーザ個人の文書とスプレッドシートを取得し、印刷する。
【００６２】
なお、上記の情報処理装置２０１の構成は、文書を用いたサービスを前提としたものであり、下記の構成の一例に過ぎない。即ち、情報処理装置２０１は、サーバ装置、ユーザ端末装置、認証サーバ装置、とデータ通信可能に接続されていることを前提とする。この前提において情報処理装置２０１は、サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信し、サービス情報が表すサービスを選択可能に表示する為の表示情報を生成し、該生成した表示情報をユーザ端末装置に送信する。そして情報処理装置２０１は、ユーザ端末装置側で選択されたサービスを示す選択サービス情報を該ユーザ端末装置から受信する。そして、該受信した選択サービス情報から生成した認証要求を、該選択されたサービスをサーバ装置が提供する前に認証を行う認証サーバ装置に対して送信する。そして、認証サーバ装置による認証が成功した場合には、サーバ装置に対してこの選択されたサービスを提供させるよう指示する。
【００６３】
［第２の実施形態］
本実施形態では、OAuthクライアントによるリソースプロバイダへのアクセス要求に対して、トークン不正エラー通知を受信した場合に、動的にアクセス範囲情報を取得して認可処理を行う方法について説明する。
【００６４】
本実施形態における情報処理装置２０１が行う処理の流れを図１２に示す。また、ユーザ、印刷サービス、認可サーバ、オフィス文書サービス、のそれぞれの間における認可処理のフローを図１３に示す。
【００６５】
まず、図１３の手順（１）のように、ユーザ１０１がWebブラウザを用いて印刷サービス１０２にアクセスし、外部のオフィス文書サービス１０４内に保存しているユーザのオフィス文書の印刷を要求する。そして、印刷サービス１０２は、あらかじめ取得済みのアクセストークンを用いて、オフィス文書サービス１０４に対して、文書取得要求を送信する（ステップＳ４０２）。
【００６６】
そして、オフィス文書サービス１０４からのレスポンスを解析し、アクセストークンが不正であるというエラー通知を受信したか否かを判断する（ステップＳ４０３）。もし、アクセストークンが不正であるというエラー通知を受信しなかった場合には、オフィス文書サービス１０４から指定したオフィス文書を取得する（ステップＳ４０４）。
【００６７】
一方、アクセストークンが不正であるというエラー通知を受信した場合には、オフィス文書サービス１０４のディスカバリーサービスからXRD文書を取得する（ステップＳ４０５）。そして、ステップＳ１０３以降の処理を行うことで、認可サーバ１０３からアクセストークンを再発行し、オフィス文書サービス１０４から指定したオフィス文書を取得する。
【００６８】
［第３の実施形態］
図３に示した情報処理装置２０１を構成する各部はハードウェアで構成してもよいが、ソフトウェア（コンピュータプログラム）で実装してもよい。この場合、このソフトウェアや第１の実施形態で既知の情報として取り扱ったデータを格納するためのメモリと、このメモリに格納されているソフトウェアやデータを用いて処理を実行するＣＰＵと、を有する装置は情報処理装置２０１に適用することができる。このような装置には、例えば、一般のＰＣ（パーソナルコンピュータ）を適用することができる。
【００６９】
図３に示した情報処理装置２０１を構成する各部のうちのいくつかは統合してもよいし、いくつかを別個の装置としてもよい。即ち、第１の実施形態を実現するためのシステムの構成は、図１に示した構成に限るものではない。
【００７０】
（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【技術分野】
【０００１】
本発明は、ユーザによる認可処理に基づいて、Webアプリケーション間でユーザデータを交換する為の技術に関するものである。
【背景技術】
【０００２】
従来、ユーザはWebブラウザを用いてWebアルバムなどのWebアプリケーションを使用する際には、事前にユーザIDとパスワードを用いてユーザ認証を行うことで、個人データの取得や作成をすることができた。また、近年、写真やSNS、オフィス系サービスなど、複数のWebアプリケーションを日常的に使い分けるユーザが増えつつあり、異なるWebアプリケーション間でユーザデータを共有する機会が増えてきていた。
【０００３】
しかし、異なるWebアプリケーション間でユーザデータを共有するには、それら第３者のWebアプリケーションに、ユーザは秘匿性の高いユーザＩＤとパスワードを通知する必要する必要があった。もし、これらユーザIDとパスワードが漏えいした場合には、入手した第3者によってユーザデータを取得できてしまうというリスクがある。
【０００４】
そこで、近年では、IETF標準のThe OAuth 1.0 Protocol (http:／／tools.ietf.org／html／rfc5849)が注目されている。OAuthプロトコルを用いることによって、ユーザはアカウント情報を第3者のWebアプリケーションに通知することなく、Webアプリケーション間でセキュアにユーザデータを共有することができるようになる。
【０００５】
図１は、Webブラウザを用いたユーザと、印刷サービスと、オフィス文書サービスの3者間で、OAuthプロトコルを用いた認可処理のフローを示したものである。印刷サービス１０２はユーザ１０１によって指定された文書を印刷するインターネットのサービスであり、オフィス文書サービス１０４は、ユーザ１０１のオフィス文書を管理するインターネットのサービスと仮定する。
【０００６】
認可サーバ１０３は、オフィス文書サービス１０４と信頼関係が事前に結ばれており、オフィス文書サービス１０４は認証情報として受信したトークンを認可サーバ１０３に送信する。そして、認可サーバ１０３が受信したトークンを検証することによって、外部Webアプリケーションによるユーザデータへのアクセスが認可されているかどうか認可サーバ１０３を用いて確認する。OAuthプロトコルとしては、印刷サービス１０２はOAuthクライアントとなり、認可サーバ１０３はOAuthサーバとなり、オフィス文書サービス１０４はリソースプロバイダとなる。
【０００７】
まず、ユーザ１０１はWebブラウザを用いて、印刷サービス１０２にアクセスする(1)。そして、ユーザ１０１が、外部のオフィス文書サービス１０４内の文書の印刷を要求した場合には、印刷サービス１０２はオフィス文書サービス１０４へのアクセス認可を得るために、認可サーバ１０３にユーザをリダイレクトする(2)。
【０００８】
図２は、ユーザ１０１のWebブラウザへ送信されるHTTPリダイレクトの一例である。リダイレクト先のURLにはWeb APIへのアクセス範囲を示すscopeパラメータを含み、印刷サービス１０２は、このscopeパラメータの範囲内でのWeb APIの利用許可を求めるものである。
【０００９】
そして、ユーザ１０１が印刷サービス１０２によるオフィス文書サービスへ１０４のアクセスを認可した場合には、OAuthの認証コードを付与して、認可サーバ１０３がユーザ１０１を印刷サービス１０２にリダイレクトする(3)。そして、印刷サービス１０２は、発行された認証コードと引き換えに、認可サーバ１０３からOAuthのアクセストークンを取得する(4)。そして、印刷サービス１０２は、取得したアクセストークンを用いて、オフィス文書サービス１０４のWeb APIを呼び出し、ユーザ１０１個人のオフィス文書を取得して印刷できるようになる(5)。
【００１０】
この認可処理の過程において、ユーザ１０１のIDやパスワードは印刷サービス１０２に直接送信されることなく、印刷サービス１０２はユーザ１０１個人のオフィス文書にアクセスできるようになる。
【００１１】
先行技術として、信頼できる第3者認証機関に信用証明書を提示することによって、ユーザの代わりとなって、あるWebアプリケーションが別のWebアプリにアクセスできるように認可するものがあった(特許文献１)。また、あるサービスが、別サーバ内のユーザデータにアクセス要求する度に、ユーザに確認画面を出し、認可後にユーザデータを提供するものがあった（特許文献２）。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開2003-099401号公報
【特許文献２】US6601092
【発明の概要】
【発明が解決しようとする課題】
【００１３】
リソースプロバイダのバージョンアップによってWeb APIの仕様を変更した場合には、OAuthのscopeパラメータが不正になるため、OAuthクライアントは正しい認可メッセージをOAuthサーバに送信できなかった。
【００１４】
例えば図１の場合、オフィス文書サービス１０４のWeb APIがバージョンアップし、サービスを提供するWeb APIの提供範囲が変更された場合、印刷サービス１０２は図2におけるscopeパラメータを更新する必要があった。従来のOAuthクライアントとしては、このscopeパラメータは、リソースプロバイダのWeb APIの仕様に基づいて固定値として保存しておくものが一般的であった。もし、リソースプロバイダのWeb APIが変更された場合には、scopeパラメータをその都度手作業で更新する。もし、scopeパラメータを更新せずにOAuthの認可フローを実行すると、リソースプロバイダにアクセスした際にアクセス範囲エラーとなり、ユーザデータにアクセスすることができなくなる。
【００１５】
本発明は以上の問題に鑑みてなされたものであり、OAuthクライアントがリソースプロバイダから動的にアクセス範囲情報を取得できるようになり、アクセス範囲情報の管理を容易にするための技術を提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明の目的を達成するために、例えば、本発明の情報処理装置は、サーバ装置、ユーザ端末装置、認証サーバ装置、とデータ通信可能に接続されている情報処理装置であって、前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信する受信手段と、前記サービス情報が表すサービスを選択可能に表示する為の表示情報を生成し、該生成した表示情報を前記ユーザ端末装置に対して送信する手段と、前記ユーザ端末装置側で選択されたサービスを示す選択サービス情報を該ユーザ端末装置から受信し、該受信した選択サービス情報から生成した認証要求を、該選択されたサービスを前記サーバ装置が提供する前に認証を行う前記認証サーバ装置に対して送信する手段と、前記認証サーバ装置による認証が成功した場合には、前記サーバ装置に対して前記選択されたサービスを提供させるよう指示する手段とを備えることを特徴とする。
【発明の効果】
【００１７】
本発明の構成によれば、OAuthクライアントは、リソースプロバイダから動的にアクセス範囲情報を取得できるようになり、アクセス範囲情報の管理が容易になる。
【図面の簡単な説明】
【００１８】
【図１】従来のOAuthプロトコルを用いた認可フローの一例を示す図。
【図２】リダイレクトメッセージの一例を示す図。
【図３】システムの構成例を示す図。
【図４】情報処理装置２０１が行う処理のフローチャート。
【図５】ステップＳ１１２における処理の詳細を示すフローチャート。
【図６】ステップＳ２１０における処理の詳細を示すフローチャート。
【図７】システムの処理手順を示す図。
【図８】ＸＲＤ文書の一例を示す図。
【図９】アクセス範囲情報の取得要求、アクセス範囲情報、の一例を示す図。
【図１０】画面の表示例、選択用ＨＴＭＬページ、を示す図。
【図１１】ＧＥＴリクエストの一例、リダイレクトメッセージの一例、を示す図。
【図１２】情報処理装置２０１が行う処理のフローチャート。
【図１３】システムの処理手順を示す図。
【発明を実施するための形態】
【００１９】
以下、添付図面を参照し、本発明の好適な実施形態について説明する。なお、以下説明する実施形態は、本発明を具体的に実施した場合の一例を示すもので、特許請求の範囲に記載した構成の具体的な実施例の一つである。
【００２０】
［第１の実施形態］
先ず、本実施形態に係るシステムの構成例について、図３を用いて説明する。図３に示す如く、本実施形態に係るシステムは、情報処理装置２０１、サーバ（サーバ装置）２０７、認可サーバ（認証サーバ装置）２０８、ユーザ端末装置２０９，を有し、それぞれの装置はデータ通信が可能なように接続されている。それぞれの装置の構成やそれぞれの装置が行う処理については、以下に詳しく説明する。
【００２１】
情報処理装置２０１が行う処理について、同処理のフローチャートを示す図４のフローチャートを用いて説明する。なお、この説明では、情報処理装置２０１以外の各装置の動作についても説明する。
【００２２】
ユーザ端末装置２０９は、図７の手順（１）のように、Webブラウザを用いて情報処理装置２０１（印刷サービス）にアクセスし、サーバ２０７（外部のオフィス文書サービス）内に保存しているユーザのオフィス文書（ユーザデータ）の印刷を要求する。
【００２３】
この要求を受信した情報処理装置２０１は、サーバ２０７によって公開されているディスカバリーサービス（ここではhttps:／／docs.sample.org／discovery）に対して、後述するＸＲＤ文書の取得要求を送信する。
【００２４】
サーバ２０７はこの取得要求に応じてＸＲＤ文書を送信するので、ステップＳ１０２においてサービス情報解析部２０２は、このＸＲＤ文書を受信する。ステップＳ１０３においてサービス情報解析部２０２は、この受信したＸＲＤ文書を、XMLパーサを用いて解析する。ここで、印刷サービスは、この固定URLのディカバリサービスを用いることによって、常に最新のサービス内容を取得できるものとする。
【００２５】
このＸＲＤ文書の一例を図８に示す。図８に示したＸＲＤ文書には、オフィス文書サービスのWeb APIのアクセス範囲情報取得用URL、フィード文書取得用URL、認証コード取得用URL、アクセストークン取得用URL、が含まれている。これらのURLの種別は、各Service要素の子要素であるType要素の要素内容に基づいて識別することができる。
【００２６】
次に、ステップＳ１０４では、記述特定部２０３は、以下で用いる変数default_uriと変数scope_discoveryを適当な値に初期化する。次にステップＳ１０５では、記述特定部２０３は、ＸＲＤ文書中の全てのService要素について解析したか否かを判断する。この判断の結果、まだ解析していないService要素が残っている場合には、処理はステップＳ１０６に進み、全てのService要素を解析した場合には、処理はステップＳ１１１に進む。
【００２７】
ステップＳ１０６では、記述特定部２０３は、ＸＲＤ文書中において未解析のService要素のType要素の内容を解析する。そしてステップＳ１０７では、記述特定部２０３は、この解析したType要素の内容がアクセス範囲情報を提供するサービスであるか否かを判断する。この判断の結果、この解析したType要素の内容がアクセス範囲情報を提供するサービスである場合には、処理はステップＳ１０８に進む。一方、この解析したType要素の内容がアクセス範囲情報を提供するサービスではない場合は、処理はステップＳ１０９に進む。
【００２８】
ステップＳ１０８では、記述特定部２０３は、アクセス範囲情報を提供するサービスであることを示すType要素が属するService要素の子要素であるURI要素の要素内容を変数scope_discoveryに設定する。
【００２９】
ステップＳ１０９では、記述特定部２０３は、ステップＳ１０６で解析したType要素の内容が、ユーザのリソース情報を提供するサービスであるか否かを判断する。この判断の結果、ユーザのリソース情報を提供するサービスである場合には、処理はステップＳ１１０に進み、ユーザのリソース情報を提供するサービスではない場合には、処理はステップＳ１０５に戻る。
【００３０】
ステップＳ１１０では、ユーザのリソース情報を提供するサービスであることを示すType要素が属するService要素の子要素であるURI要素の要素内容を変数default_uriに設定する。ユーザのリソース情報は、RFC5023 The Atom Publishing Protocol(http:／／tools.ietf.org／html／rfc5023)に基づいて取得するものとする。
【００３１】
ステップＳ１１１では、アクセス範囲情報取得部２０４は、変数scope_discoveryに初期値以外の何らかの値が設定してあるか否かを判断する。この判断の結果、変数scope_discoveryに初期値以外の何らかの値が設定してある場合には、処理はステップＳ１１２に進む。一方、変数scope_discoveryに初期値以外の何らかの値が設定してない場合は、処理はステップＳ１１４に進む。
【００３２】
ステップＳ１１２では、アクセス範囲情報取得部２０４は、変数scope_discoveryに設定されているURIを用いて、アクセス範囲情報の取得要求をサーバ２０７に送信する。この取得要求、取得要求に応じてサーバ２０７から返信されるアクセス範囲情報、の一例を図９に示す。図９（ａ）は、情報処理装置２０１がサーバ２０７に対して送信する、アクセス範囲情報の取得要求の一例を示す。図９（ｂ）は、この取得要求に応じてサーバ２０７が情報処理装置２０１に対して送信するアクセス範囲情報の一例を示す。図９（ｂ）に示す如く、アクセス範囲情報はＸＭＬ形式のデータである。
【００３３】
図９（ｂ）のアクセス範囲情報には、３つのアクセス範囲情報が含まれており、各scope要素の要素内容がURL形式のアクセス範囲情報となる。図９（ｂ）では、この３つのXML形式のアクセス範囲情報のそれぞれは、文書サービス、スプレッドシートサービス、PDFサービス、に対応したものである。
【００３４】
また、scope要素のuse属性の値が”default”である場合、このscope要素に対応するサービス（アクセス範囲）の使用を、標準設定において指定してあることを示している。また、scope要素のuse属性の値が”optional”である場合、このscope要素に対応するサービス（アクセス範囲）の使用は標準設定では指定しておらず、ユーザによって任意に指定するものであることを示している。
【００３５】
また、scope要素のicon属性は、このscope要素に対応するサービス（アクセス範囲）を表現したアイコン画像へのURLを示している。
【００３６】
次に、上記のステップＳ１１２における処理の詳細について、図５のフローチャートを用いて説明する。なお、この説明では、情報処理装置２０１がサーバ２０７から図９（ｂ）に示したアクセス範囲情報を受信した場合を例にとっている。しかし、以下の説明は、図９（ｂ）に示したアクセス範囲情報以外のアクセス範囲情報を受信した場合であっても同様に適用することができる。
【００３７】
ステップＳ２０２では、アクセス範囲情報取得部２０４が送信した要求に応じてサーバ２０７から送信されたアクセス範囲情報を、アクセス範囲情報解析部２０５が受信する。そしてアクセス範囲情報解析部２０５が有する記述解析部が、この受信したアクセス範囲情報を解析する。
【００３８】
ステップＳ２０３では、アクセス範囲情報解析部２０５は、以下の処理で用いる変数scopeListをリスト型で初期化する。即ち、変数scopeListに対して複数個の構造体を格納できるようにする。
【００３９】
ステップＳ２０４では、アクセス範囲情報解析部２０５は、受信したアクセス範囲情報中における、ルートのscopes要素以下の全てのscope要素を解析したか否かを判断する。この判断の結果、全てのscope要素を解析した場合には、処理はステップＳ２１０に進み、まだ解析していないscope要素が残っている場合には、処理はステップＳ２０５に進む。
【００４０】
ステップＳ２０５では、アクセス範囲情報解析部２０５は、変数（構造体）scopeを適当な値に初期化する。ステップＳ２０６では、アクセス範囲情報解析部２０５の属性解析部が、未解析のscope要素のuse属性の値を、変数scopeのメンバー変数useに設定する。ステップＳ２０７では、アクセス範囲情報解析部２０５の属性解析部が、未解析のscope要素のicon属性の値を、変数scopeのメンバー変数iconに設定する。ステップＳ２０８では、アクセス範囲情報解析部２０５の属性解析部が、未解析のscope要素の要素内容を変数scopeのメンバー変数uriに設定する。
【００４１】
ステップＳ２０９では、アクセス範囲情報解析部２０５の属性解析部は、ステップＳ２０６〜Ｓ２０８で確定した変数scopeを、変数scopeListに追加登録する。
【００４２】
ステップＳ２１０では、アクセス範囲情報解析部２０５の選択画面生成部は、変数scopeListを用いて、サーバ２０７が提供可能なサービスを選択可能に表示する為の選択用ＨＴＭＬページ（表示情報）を生成する。そしてアクセス範囲情報解析部２０５の選択画面生成部は、この該生成した選択用ＨＴＭＬページを、ユーザ端末装置２０９に対して送信する。
【００４３】
ステップＳ２１０における処理の詳細について、図６のフローチャートを用いて説明する。なお、図６のフローチャートの各ステップにおける処理の主体は何れも、アクセス範囲情報解析部２０５の選択画面生成部である。
【００４４】
ステップＳ３０２では、ユーザ端末装置２０９に送信するレスポンスの出力ストリームを初期化する。ステップＳ３０３では、html要素の開始タグとhead要素を出力ストリームに対して出力する。ステップＳ３０４では、body要素の開始タグと、form要素の開始タグを出力ストリームに対して出力する。ステップＳ３０５では、変数scopeListに含まれる全てのscopeオブジェクトを解析したか否かを判断する。
【００４５】
この判断の結果、全てのscopeオブジェクトを解析している場合は、処理はステップＳ３１２に進み、まだ解析していないscopeオブジェクトが残っている場合は、処理はステップＳ３０６に進む。
【００４６】
ステップＳ３０６では、div要素の開始タグを出力ストリームに対して出力する。ステップＳ３０７では、未解析のscopeオブジェクトのメンバ変数useの値が”default”と等しいか否かを判断する。この判断の結果、等しい場合には、処理はステップＳ３０８に進み、等しくない場合は、処理はステップＳ３０９に進む。
【００４７】
ステップＳ３０８では、”checkbox”を値とするtype属性と、”scope”を値とするname属性と、scopeのメンバ変数uriを値とするvalue属性と、checked属性を含むinput要素を出力ストリームに対して出力する。
【００４８】
ステップＳ３０９では、”checkbox”を値とするtype属性と、”scope”を値とするname属性と、scopeのメンバ変数uriを値とするvalue属性と、を含むinput要素を出力ストリームに対して出力する。
【００４９】
ステップＳ３１０では、未解析のscopeオブジェクトのメンバ変数iconを値とするsrc属性を含むimg要素を出力ストリームに対して出力する。ステップＳ３１１では、div要素の終了タグを出力ストリームに対して出力する。
【００５０】
ステップＳ３１２では、form要素の終了タグと、body要素の終了タグと、html要素の終了タグを出力ストリームに対して出力する。そして、ステップＳ３１３では、レスポンスの出力ストリームをクローズする。
【００５１】
このようにして生成した出力ストリームを、上記の選択用ＨＴＭＬページとしてユーザ端末装置２０９に対して送信する。上記の処理により生成される選択用ＨＴＭＬページを図１０（ｂ）に示す。また、この選択用ＨＴＭＬページを受信したユーザ端末装置２０９の表示画面に表示される、選択用ＨＴＭＬページの画面の表示例を図１０（ａ）に示す。
【００５２】
図１０（ａ）に示した画面上には、form要素以下の各div要素に各サービスを利用するか否かのチェックボックスと、そのサービスを表現するアイコン画像とが配されている。図９（ｂ）においてサービスhttps:／／docs.sample.org／feedを含むscope要素のuse属性は”default”であるため、図１０（ａ）の画面でこのサービスに対応するチェックボックスは標準設定で選択状態にある。
【００５３】
ユーザ端末装置２０９のユーザは、図１０（ａ）の画面において、利用するサービスに対応するチェックボックスを指示し、その後「ＯＫ」ボタンを指示する。これによりユーザ端末装置２０９からは、form要素のaction属性で指定したCGIに対して、ユーザの選択したチェックボックスの内容がGETリクエストのクエリパラメータとして送信される。このクエリパラメータには、ユーザが図１０（ａ）の画面で選択したサービスに関するアクセス範囲情報が含まれている。
【００５４】
図１１（ａ）に、図１０（ａ）の画面において、ユーザが文書サービスとスプレッドシートサービスのチェックボックスを選択した場合に、CGIに送信されるGETリクエストの内容を示す。
【００５５】
ステップＳ２１１では、アクセス範囲情報解析部２０５の選択範囲解析部は、この送信されたクエリパラメータを受信する。そしてステップＳ２１２では、アクセス範囲情報解析部２０５の選択範囲解析部は、この受信したクエリパラメータを解析する。
【００５６】
ステップＳ１１３では、アクセス範囲情報解析部２０５の選択範囲解析部は、この解析により判明した「ユーザが選択したサービス」をOAuthのscopeパラメータに設定する。
【００５７】
一方、ステップＳ１１４では、アクセス範囲情報解析部２０５の選択範囲解析部は、変数default_uriのURIをOAuthのscopeパラメータに設定する。
【００５８】
ステップＳ１１５では、認可要求送信部２０６は、ユーザ端末装置２０９を認可サーバ２０８にリダイレクトすべく、認可サーバ２０８に対して、リダイレクトメッセージを送信する。
【００５９】
ステップＳ１１３の後にステップＳ１１５において送信されるリダイレクトメッセージを図１１（ｂ）に示す。このリダイレクトメッセージでは、ステップＳ１１２で取得したアクセス範囲情報をURLエンコード変換してscopeパラメータに設定している。
【００６０】
ステップＳ１１４の後にステップＳ１１５において送信されるリダイレクトメッセージを図２に示す。このリダイレクトメッセージでは、scopeパラメータには１つのURLを設定し、情報処理装置２０１は、１つのWeb APIへのアクセス許可を求める。
【００６１】
以降の処理は、図７のOAuthプロトコルの認可フローに従い、情報処理装置２０１によるサーバ２０７へのアクセスを認可した場合には、図７の手順（５）のように、ユーザ端末装置２０９を情報処理装置２０１にリダイレクトする。その際、認可サーバ２０８から取得した認証コードを用いて、図７の手順（６）のように、認可サーバ２０８からアクセストークンを取得する。そして、取得したアクセストークンを用いて、サーバ２０７から、そのユーザ個人の文書とスプレッドシートを取得し、印刷する。
【００６２】
なお、上記の情報処理装置２０１の構成は、文書を用いたサービスを前提としたものであり、下記の構成の一例に過ぎない。即ち、情報処理装置２０１は、サーバ装置、ユーザ端末装置、認証サーバ装置、とデータ通信可能に接続されていることを前提とする。この前提において情報処理装置２０１は、サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信し、サービス情報が表すサービスを選択可能に表示する為の表示情報を生成し、該生成した表示情報をユーザ端末装置に送信する。そして情報処理装置２０１は、ユーザ端末装置側で選択されたサービスを示す選択サービス情報を該ユーザ端末装置から受信する。そして、該受信した選択サービス情報から生成した認証要求を、該選択されたサービスをサーバ装置が提供する前に認証を行う認証サーバ装置に対して送信する。そして、認証サーバ装置による認証が成功した場合には、サーバ装置に対してこの選択されたサービスを提供させるよう指示する。
【００６３】
［第２の実施形態］
本実施形態では、OAuthクライアントによるリソースプロバイダへのアクセス要求に対して、トークン不正エラー通知を受信した場合に、動的にアクセス範囲情報を取得して認可処理を行う方法について説明する。
【００６４】
本実施形態における情報処理装置２０１が行う処理の流れを図１２に示す。また、ユーザ、印刷サービス、認可サーバ、オフィス文書サービス、のそれぞれの間における認可処理のフローを図１３に示す。
【００６５】
まず、図１３の手順（１）のように、ユーザ１０１がWebブラウザを用いて印刷サービス１０２にアクセスし、外部のオフィス文書サービス１０４内に保存しているユーザのオフィス文書の印刷を要求する。そして、印刷サービス１０２は、あらかじめ取得済みのアクセストークンを用いて、オフィス文書サービス１０４に対して、文書取得要求を送信する（ステップＳ４０２）。
【００６６】
そして、オフィス文書サービス１０４からのレスポンスを解析し、アクセストークンが不正であるというエラー通知を受信したか否かを判断する（ステップＳ４０３）。もし、アクセストークンが不正であるというエラー通知を受信しなかった場合には、オフィス文書サービス１０４から指定したオフィス文書を取得する（ステップＳ４０４）。
【００６７】
一方、アクセストークンが不正であるというエラー通知を受信した場合には、オフィス文書サービス１０４のディスカバリーサービスからXRD文書を取得する（ステップＳ４０５）。そして、ステップＳ１０３以降の処理を行うことで、認可サーバ１０３からアクセストークンを再発行し、オフィス文書サービス１０４から指定したオフィス文書を取得する。
【００６８】
［第３の実施形態］
図３に示した情報処理装置２０１を構成する各部はハードウェアで構成してもよいが、ソフトウェア（コンピュータプログラム）で実装してもよい。この場合、このソフトウェアや第１の実施形態で既知の情報として取り扱ったデータを格納するためのメモリと、このメモリに格納されているソフトウェアやデータを用いて処理を実行するＣＰＵと、を有する装置は情報処理装置２０１に適用することができる。このような装置には、例えば、一般のＰＣ（パーソナルコンピュータ）を適用することができる。
【００６９】
図３に示した情報処理装置２０１を構成する各部のうちのいくつかは統合してもよいし、いくつかを別個の装置としてもよい。即ち、第１の実施形態を実現するためのシステムの構成は、図１に示した構成に限るものではない。
【００７０】
（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【特許請求の範囲】
【請求項１】
サーバ装置、ユーザ端末装置、認証サーバ装置、とデータ通信可能に接続されている情報処理装置であって、
前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信する受信手段と、
前記サービス情報が表すサービスを選択可能に表示する為の表示情報を生成し、該生成した表示情報を前記ユーザ端末装置に対して送信する手段と、
前記ユーザ端末装置側で選択されたサービスを示す選択サービス情報を該ユーザ端末装置から受信し、該受信した選択サービス情報から生成した認証要求を、該選択されたサービスを前記サーバ装置が提供する前に認証を行う前記認証サーバ装置に対して送信する手段と、
前記認証サーバ装置による認証が成功した場合には、前記サーバ装置に対して前記選択されたサービスを提供させるよう指示する手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記受信手段は、
前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信する為のURIが記された文書を該サーバ装置から受信する手段と、
前記文書を受信すると、該文書から前記URIを取得し、該取得したURIで特定される前記サーバ装置に対して前記サービス情報を要求し、該要求に応じて前記サーバ装置から送信されたサービス情報を受信する手段と
を備えることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記受信手段は、予め定められたアクセストークンを用いて前記サーバ装置に対してアクセスした場合に、該アクセストークンが不正である旨のエラー通知を受信した場合に、前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
サーバ装置、ユーザ端末装置、認証サーバ装置、とデータ通信可能に接続されている情報処理装置が行う情報処理方法であって、
前記情報処理装置の受信手段が、前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信する受信工程と、
前記情報処理装置の表示情報の送信手段が、前記サービス情報が表すサービスを選択可能に表示する為の表示情報を生成し、該生成した表示情報を前記ユーザ端末装置に対して送信する工程と、
前記情報処理装置の認証要求の送信手段が、前記ユーザ端末装置側で選択されたサービスを示す選択サービス情報を該ユーザ端末装置から受信し、該受信した選択サービス情報から生成した認証要求を、該選択されたサービスを前記サーバ装置が提供する前に認証を行う前記認証サーバ装置に対して送信する工程と、
前記情報処理装置の指示手段が、前記認証サーバ装置による認証が成功した場合には、前記サーバ装置に対して前記選択されたサービスを提供させるよう指示する工程と
を備えることを特徴とする情報処理方法。
【請求項５】
コンピュータを、請求項１乃至３の何れか１項に記載の情報処理装置の各手段として機能させるためのコンピュータプログラム。
【請求項１】
サーバ装置、ユーザ端末装置、認証サーバ装置、とデータ通信可能に接続されている情報処理装置であって、
前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信する受信手段と、
前記サービス情報が表すサービスを選択可能に表示する為の表示情報を生成し、該生成した表示情報を前記ユーザ端末装置に対して送信する手段と、
前記ユーザ端末装置側で選択されたサービスを示す選択サービス情報を該ユーザ端末装置から受信し、該受信した選択サービス情報から生成した認証要求を、該選択されたサービスを前記サーバ装置が提供する前に認証を行う前記認証サーバ装置に対して送信する手段と、
前記認証サーバ装置による認証が成功した場合には、前記サーバ装置に対して前記選択されたサービスを提供させるよう指示する手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記受信手段は、
前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信する為のURIが記された文書を該サーバ装置から受信する手段と、
前記文書を受信すると、該文書から前記URIを取得し、該取得したURIで特定される前記サーバ装置に対して前記サービス情報を要求し、該要求に応じて前記サーバ装置から送信されたサービス情報を受信する手段と
を備えることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記受信手段は、予め定められたアクセストークンを用いて前記サーバ装置に対してアクセスした場合に、該アクセストークンが不正である旨のエラー通知を受信した場合に、前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
サーバ装置、ユーザ端末装置、認証サーバ装置、とデータ通信可能に接続されている情報処理装置が行う情報処理方法であって、
前記情報処理装置の受信手段が、前記サーバ装置が提供可能なサービスを示すサービス情報を該サーバ装置から受信する受信工程と、
前記情報処理装置の表示情報の送信手段が、前記サービス情報が表すサービスを選択可能に表示する為の表示情報を生成し、該生成した表示情報を前記ユーザ端末装置に対して送信する工程と、
前記情報処理装置の認証要求の送信手段が、前記ユーザ端末装置側で選択されたサービスを示す選択サービス情報を該ユーザ端末装置から受信し、該受信した選択サービス情報から生成した認証要求を、該選択されたサービスを前記サーバ装置が提供する前に認証を行う前記認証サーバ装置に対して送信する工程と、
前記情報処理装置の指示手段が、前記認証サーバ装置による認証が成功した場合には、前記サーバ装置に対して前記選択されたサービスを提供させるよう指示する工程と
を備えることを特徴とする情報処理方法。
【請求項５】
コンピュータを、請求項１乃至３の何れか１項に記載の情報処理装置の各手段として機能させるためのコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１３−８１０６（Ｐ２０１３−８１０６Ａ）
【公開日】平成２５年１月１０日（２０１３．１．１０）
【国際特許分類】
【出願番号】特願２０１１−１３８８８９（Ｐ２０１１−１３８８８９）
【出願日】平成２３年６月２２日（２０１１．６．２２）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２５年１月１０日（２０１３．１．１０）
【国際特許分類】
【出願日】平成２３年６月２２日（２０１１．６．２２）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]