(57)【要約】【課題】異なるオリジンに属するＷｅｂサービスやＷｅｂアプリケーションへのアクセスを制御できる。【解決手段】情報処理装置は、第１の実行部、第２の実行部、および、通信部を備える。第１の実行部は、第１のＷｅｂアプリケーションを実行する。第２の実行部は、第１の実行部からＷｅｂサービスへのリクエストとリクエストを識別する識別子を取得するとともに、リクエストをＷｅｂサービスへ中継する第２のＷｅｂアプリケーションを実行する。通信部は、Ｗｅｂサービスを提供するサーバと通信する。第２の実行部は、通信部を介してリクエストに対するレスポンスを取得すると、レスポンスと識別子を含むメッセージを、第１の実行部に出力する。第１の実行部は、レスポンスをリクエストに対するＷｅｂサービスでの処理結果として処理する。【選択図】図１
2017062659.tif 000002
【特許請求の範囲】
【請求項１】
第１のＷｅｂアプリケーションを実行する第１の実行部と、
前記第１の実行部からＷｅｂサービスへのリクエストと前記リクエストを識別する識別子を取得するとともに、前記リクエストを前記Ｗｅｂサービスへ中継する第２のＷｅｂアプリケーションを実行する第２の実行部と、
前記Ｗｅｂサービスを提供するサーバと通信する通信部
を備え、
前記第２の実行部は、前記通信部を介して前記リクエストに対するレスポンスを取得すると、前記レスポンスと前記識別子を含むメッセージを、前記第１の実行部に出力し、
前記第１の実行部は、前記レスポンスを前記リクエストに対する前記Ｗｅｂサービスでの処理結果として処理する
ことを特徴とする情報処理装置。
【請求項２】
前記第２の実行部は、
前記第１の実行部から通知された識別子を、前記第１のＷｅｂアプリケーションが実行されているブラウジングコンテキストと対応付けて記憶し、
前記メッセージを、前記識別子に対応付けられたブラウジングコンテキストに出力することにより、前記メッセージを前記第１の実行部に引き渡す
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記第２の実行部は、前記第１のＷｅｂアプリケーションからのアクセスを許可するＷｅｂサービスを特定する制御情報を保持し、
前記通信部は、前記第１の実行部から取得したリクエストを処理するＷｅｂサービスが前記制御情報に含まれている場合、前記リクエストを前記サーバに送信する
ことを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
第３のＷｅｂアプリケーションを実行する第３の実行部を備え、
前記第２の実行部は、
前記第１の実行部から前記第３のＷｅｂアプリケーションに対して戻り値を要求する他のリクエストと前記他のリクエストを識別する第１の識別子を取得し、
前記他のリクエストの処理の要求と第２の識別子を対応付けて、前記第３の実行部に出力し、
前記第２の識別子に対応付けて前記第３の実行部から通知された値を前記他のリクエストの処理によって得られた前記戻り値として特定し、
前記戻り値と前記第１の識別子を含むメッセージを、前記第１の実行部に出力する
ことを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。
【請求項５】
第１のＷｅｂアプリケーションを実行し、
前記第１のＷｅｂアプリケーションからＷｅｂサービスへのリクエストと前記リクエストを識別する識別子を取得するとともに、前記リクエストを前記Ｗｅｂサービスへ中継する第２のＷｅｂアプリケーションを実行し、
前記Ｗｅｂサービスを提供するサーバと通信することにより、前記リクエストに対するレスポンスを取得し、
前記レスポンスと前記識別子を含むメッセージを、前記第２のＷｅｂアプリケーションから前記第１のＷｅｂアプリケーションに出力し、
前記第１のＷｅｂアプリケーションで、前記レスポンスを前記リクエストに対する前記Ｗｅｂサービスでの処理結果として処理する
処理を情報処理装置が行うことを特徴とする情報処理方法。
【請求項６】
第１のＷｅｂアプリケーションを実行し、
前記第１のＷｅｂアプリケーションからＷｅｂサービスへのリクエストと前記リクエストを識別する識別子を取得するとともに、前記リクエストを前記Ｗｅｂサービスへ中継する第２のＷｅｂアプリケーションを実行し、
前記Ｗｅｂサービスを提供するサーバと通信することにより、前記リクエストに対するレスポンスを取得し、
前記レスポンスと前記識別子を含むメッセージを、前記第２のＷｅｂアプリケーションから前記第１のＷｅｂアプリケーションに出力し、
前記第１のＷｅｂアプリケーションで、前記レスポンスを前記リクエストに対する前記Ｗｅｂサービスでの処理結果として処理する
処理を情報処理装置に実行させることを特徴とする処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に関する。
【背景技術】
【０００２】
Ｗｅｂアプリケーション（Ｗｅｂアプリ）は、インターネットなどのネットワークを介して使用するアプリケーションソフトウェアであり、Ｗｅｂブラウザ上で動作する。Ｗｅｂアプリは、例えばＪａｖａＳｃｒｉｐｔ（登録商標）などのプログラミング言語とＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＨＴＭＬ）で記述されており、Ｗｅｂサーバ側のプログラムと協調して動作する。
【０００３】
Ｗｅｂアプリは、ブラウジングコンテキストで実行される。ブラウジングコンテキストは、ＨＴＭＬ５の仕様によれば、文書が表示されるウィンドウやタブなどの環境を示す。また、ＨＴＭＬ５のインラインフレームなども、ブラウジングコンテキストと呼ばれる。ブラウジングコンテキストは、インストールされたＷｅｂブラウザ上で動作する。
【０００４】
Ｗｅｂアプリは、オリジンと呼ばれるグループに属している。同一生成源ポリシー（Ｓａｍｅ  Ｏｒｉｇｉｎ  Ｐｏｌｉｃｙ：ＳＯＰ）が使用される場合、Ｗｅｂアプリは、同じオリジンに属している別のＷｅｂアプリに対する操作が許可されている。そのため、Ｗｅｂアプリは、同じオリジンに属している別のＷｅｂアプリに対して、例えば、Ｄｏｃｕｍｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ（以下、ＤＯＭ）操作や、Ｗｅｂアプリ間のメッセージの送受信などを行うことが許可されている。
【０００５】
一方、同一生成源ポリシーが使用される場合、Ｗｅｂアプリは、異なるオリジンに属している別のＷｅｂアプリに対する操作を行うことが許可されていない。すなわち、Ｗｅｂアプリは、異なるオリジンに属している別のＷｅｂアプリに対して、例えば、ＤＯＭ操作は許可されていない。このため、Ｗｅｂアプリの処理に起因して、異なるオリジンのＷｅｂアプリへデータが漏洩することなどを避けることができる。
【０００６】
関連する技術として、セッション情報をタスクセッション情報とスレッドセッション情報に分離し、タスクセッションＩＤとスレッドセッションＩＤを用いて、サービスサイト単位のセッションを確立させる方法が提案されている（例えば、特許文献１など）。ユーザのデバイスから使用可能な複数のアプリケーション・サービスの群の中の特定の群にアクセスできるようにするネットワークを、動的に形成するプログラムも提案されている（例えば、特許文献２など）。オンラインサービスサーバ、ブラウザを備えるクライアント端末、生体認証支援サーバを有する生体認証システムも提案されている。このシステムでは、クライアント端末は、ブラウザに生体情報入力装置を操作する機能を追加するプラグインを生体認証支援サーバから取得する。オンラインサービスサーバが生体認証依頼スクリプトをクライアント端末に送信すると、クライアント端末のブラウザ上で生体認証依頼スクリプトの実行とユーザ認証が行われる（例えば、特許文献３など）。ウェブサーバ装置が、正当な一時トークンの送信元のクライアント装置に通常セッションＩＤを送信し、一時トークンに対応付けられていたウェブサービスセッションＩＤと通常セッションＩＤを対応付ける方法も提案されている（例えば、特許文献４など）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−１７８４６６号公報
【特許文献２】特表２００５−５２０２５０号公報
【特許文献３】特開２００９−２２３６３８号公報
【特許文献４】特開２００８−０７７６１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
同一生成源ポリシーが用いられる場合、あるＷｅｂアプリケーションから他のＷｅｂアプリケーションやＷｅｂサービスの呼び出しの可否は、オリジン単位で制御される。オリジンは、Ｗｅｂアプリケーションの配布者により決定されるが、配布者であっても、複数のＷｅｂアプリケーション間の関連性やＷｅｂアプリケーションとＷｅｂサービスの関連性を考慮したオリジンの設計は困難である。
【０００９】
本発明は、一つの側面では、異なるオリジンに属するＷｅｂサービスやＷｅｂアプリケーションへのアクセスを制御することを目的とする。
【課題を解決するための手段】
【００１０】
１つの態様にかかる情報処理装置は、第１の実行部、第２の実行部、および、通信部を備える。第１の実行部は、第１のＷｅｂアプリケーションを実行する。第２の実行部は、前記第１の実行部からＷｅｂサービスへのリクエストと前記リクエストを識別する識別子を取得するとともに、前記リクエストを前記Ｗｅｂサービスへ中継する第２のＷｅｂアプリケーションを実行する。通信部は、前記Ｗｅｂサービスを提供するサーバと通信する。前記第２の実行部は、前記通信部を介して前記リクエストに対するレスポンスを取得すると、前記レスポンスと前記識別子を含むメッセージを、前記第１の実行部に出力する。前記第１の実行部は、前記レスポンスを前記リクエストに対する前記Ｗｅｂサービスでの処理結果として処理する。
【発明の効果】
【００１１】
異なるオリジンに属するＷｅｂサービスやＷｅｂアプリケーションへのアクセスを制御できる。
【図面の簡単な説明】
【００１２】
【図１】実施形態にかかる通信方法の例を説明する図である。
【図２】情報処理装置とサーバの構成の例を説明する図である。
【図３】情報処理装置およびサーバのハードウェア構成の例を説明する図である。
【図４】各アプリケーションで行われる処理の例を説明する図である。
【図５】制御情報の例を説明する図である。
【図６】各アプリケーションで行われる処理の例を説明する図である。
【図７】アプリ管理情報の例を説明する図である。
【図８】各アプリケーションで行われる処理の例を説明するシーケンス図である。
【図９】実施形態にかかる方法で行われる通信の例を説明する図である。
【図１０】第２の実施形態で使用される制御情報の例を説明する図である。
【図１１】第３の実施形態で使用される制御情報の例を説明する図である。
【図１２】Ｗｅｂアプリ間での処理の例を説明する図である。
【発明を実施するための形態】
【００１３】
図１は、実施形態にかかる通信方法の例を説明する図である。情報処理装置２００には、ブラウザ１００がインストールされている。ブラウザ１００は、複数のブラウジングコンテキスト（ＢＣ）を提供することができる。ブラウジングコンテキストは、例えば、ウィンドウ、タブ、インラインフレームなどであり、各ＢＣでは、Ｗｅｂアプリが実行される。複数のＢＣは階層化（nested）されてもよい。図１の例では、ブラウザ１００において、トップレベルＢＣ１１０、子ＢＣ１２０、子ＢＣ１３０がツリー状に提供されている。子ＢＣ１２０および子ＢＣ１３０は、トップレベルＢＣ１１０にネスティングしているブラウジングコンテキストであり、トップレベルＢＣ１１０は、子ＢＣ１２０と子ＢＣ１３０の親ＢＣである。例えば、トップレベルＢＣ１１０はトップレベルのウィンドウであってもよく、子ＢＣ１２０と子ＢＣ１３０は、トップレベルＢＣ１１０内のインラインフレームであってもよい。
【００１４】
図１の例では、トップレベルＢＣ１１０において管理アプリ１５０が実行され、子ＢＣ１２０においてＷｅｂアプリ１２１、子ＢＣ１３０においてＷｅｂアプリ１３１が実行されているとする。また、管理アプリ１５０は管理用オリジン、Ｗｅｂアプリ１２１はオリジンＢ、Ｗｅｂアプリ１３１はオリジンＣに属するものとする。さらに、図１中のサーバ４００は、Ｗｅｂサービス４０１を提供する。Ｗｅｂサービス４０１は、オリジンＳに属するとする。管理用オリジンに対応付けられたアクセスの要求は、いずれのオリジンに属するＷｅｂアプリやＷｅｂサービスでも許可されるものとする。
【００１５】
管理アプリ１５０は、あるＷｅｂアプリからの他のＷｅｂアプリやＷｅｂサービスへのアクセスを制御する。以下、オリジンＣに属するＷｅｂアプリ１３１が、オリジンＳに属するＷｅｂサービス４０１にアクセスする場合を例として、通信方法の例を説明する。
【００１６】
まず、Ｗｅｂアプリ１３１の一部として動作する実行部１３４は、Ｗｅｂサービス４０１へのリクエストと、そのリクエストを識別する識別子を生成する。図１の例では、実行部１３４は、ＩＤａという識別子を生成したとする。Ｗｅｂアプリ１３１は、識別子ＩＤａを、Ｗｅｂサービス４０１へのリクエストに対応付けた識別子として記憶する。さらに、Ｗｅｂアプリ１３１は、識別子ＩＤａとＷｅｂサービス４０１へのリクエストを含むメッセージを、管理アプリ１５０が動作しているトップレベルＢＣ１１０に出力する（矢印Ａ１）。
【００１７】
管理アプリ１５０の一部として動作する実行部１５３は、メッセージに含まれている識別子ＩＤａを、メッセージの送信元のＢＣ１３０と対応付ける。制御部１５２は、Ｗｅｂアプリ１３１からＷｅｂサービス４０１へのアクセスを許可するかを判定する。Ｗｅｂアプリ１３１からＷｅｂサービス４０１へのアクセスが許可できる場合、実行部１５３は、矢印Ａ１で入力されたメッセージ中のリクエストを、Ｗｅｂサービス４０１で処理されるリクエストとする。実行部１５３は、Ｗｅｂサービス４０１で処理されるリクエストを含むメッセージを、サーバ４００に送信する（矢印Ａ２）。このとき、サーバ４００宛てのメッセージには、メッセージの送信元のアプリケーションが属するオリジンとして、管理用オリジンが指定されている。
【００１８】
Ｗｅｂサービス４０１は、管理用オリジンに属するアプリケーションから送信されたメッセージを処理する。Ｗｅｂサービス４０１は、メッセージ中のリクエストに対する処理を行った結果（レスポンス）を、管理アプリ１５０で処理されるデータとして含めたメッセージを生成する。サーバ４００は、レスポンスを含むメッセージを情報処理装置２００に送信する。情報処理装置２００でのメッセージの受信処理により、実行部１５３はレスポンスを取得する。（矢印Ａ３）。なお、矢印Ａ３で送信されるメッセージには、メッセージ中の情報が、矢印Ａ２での処理の結果であることが特定可能な任意の情報が含まれているものとする。
【００１９】
実行部１５３は、レスポンスに対応するリクエストの取得時に記憶した情報から、レスポンスがＢＣ１３０で動作しているＷｅｂアプリに出力するデータであると判定する。実行部１５３は、レスポンスと、ＢＣ１３０に対応付けて記憶している識別子ＩＤａを含むメッセージを、子ＢＣ１３０に出力する（矢印Ａ４）。
【００２０】
Ｗｅｂアプリ１３１の実行部１３４は、取得したメッセージ中に、識別子ＩＤａが記録されていることから、取得したメッセージには、Ｗｅｂサービス４０１へのリクエストに対するレスポンスが含まれていると判定する。そこで、実行部１３４は、メッセージ中のレスポンスを、Ｗｅｂサービス４０１から得られたレスポンスとして処理する。
【００２１】
このように、実施形態にかかる方法では、管理アプリ１５０によって、リクエストやレスポンスが中継され、リクエストは管理用オリジンのリクエストとしてアクセス先のＷｅｂサービスに送信される。このため、Ｗｅｂアプリは異なるオリジンのＷｅｂサービスやＷｅｂアプリにアクセスできる。
【００２２】
なお、管理アプリ１５０を介してアクセスが要求されていない場合には、同一生成源ポリシーが適用される。例えば、図１の点線の矢印で示すように、Ｗｅｂアプリ１２１が直接Ｗｅｂサービス４０１にアクセスしようとしても、Ｗｅｂアプリ１２１とＷｅｂサービス４０１ではオリジンが異なるので、Ｗｅｂアプリ１２１からのアクセスは許可されない。同様に、Ｗｅｂアプリ１３１からＷｅｂサービス４０１への直接のアクセスも許可されない。このため、異なるオリジン間でのアクセスを許可する場合の条件を管理アプリ１５０に登録することにより、Ｗｅｂアプリケーションの操作の可否をアプリケーションごとに制御することができる。
【００２３】
同様に、サンドボックス化（sandbox）されたＷｅｂアプリからのリクエストのように、アクセス元のオリジンがｎｕｌｌになっているリクエストなども、管理アプリ１５０でアクセスが許可されれば、他のＷｅｂサービスやＷｅｂアプリで処理されうる。
【００２４】
なお、図１の例では、管理アプリ１５０がトップレベルＢＣ１１０で動作する場合を例として説明したが、図１は一例に過ぎず、管理アプリ１５０は任意のブラウジングコンテキストで実行されうる。この場合、異なるオリジンのＷｅｂアプリケーションやＷｅｂサービスにアクセスするＷｅｂアプリの実行部は、管理アプリ１５０が動作するブラウジングコンテキストを認識していればよい。
【００２５】
＜装置構成＞
図２は、情報処理装置２００とサーバの構成の例を説明する図である。情報処理装置２００は、サーバ２１０、サーバ２２０Ｂ、サーバ２２０Ｃ、サーバ４００の各々と、ネットワークを介して接続されている。図２の例でも、管理アプリ１５０がトップレベルＢＣ１１０で動作する場合を例とする。
【００２６】
サーバ２１０は、記憶部２１１と通信部２１２を備える。記憶部２１１は、管理アプリ１５０を記憶している。通信部２１２は、情報処理装置２００からの要求に応じて、管理アプリ１５０を情報処理装置２００に送信する。
【００２７】
サーバ２２０Ｂは、オリジンＢに属するＷｅｂアプリ１２１を配布する。サーバ２２０Ｃは、オリジンＣに属するＷｅｂアプリ１３１を配布する。以下、サーバ２２０Ｂ、サーバ２２０ＣのようにＷｅｂアプリを配布するサーバをまとめてサーバ２２０と記載する。サーバ２２０は、記憶部２２１と通信部２２２を備える。サーバ２２０Ｃの記憶部２２１は、オリジンＣに属するＷｅｂアプリ１３１を記憶している。サーバ２２０Ｂの記憶部２２１は、オリジンＢに属するＷｅｂアプリ１２１を記憶している。通信部２２２は、情報処理装置２００からの要求に応じて、要求されたＷｅｂアプリを情報処理装置２００に送信する。
【００２８】
サーバ４００は、実行部４０３と通信部４０２を備える。実行部４０３は、管理用オリジンに対応付けられているリクエストに対して、Ｗｅｂサービス４０１を提供するための処理を実行する。通信部４０２は、実行部４０３での処理で得られたレスポンスを情報処理装置２００に送信する。
【００２９】
情報処理装置２００は、通信部２０５を用いて、サーバ２１０、サーバ２２０、サーバ４００との間の通信を行う。通信部２０５は、送信部２０６と受信部２０７を有する。送信部２０６は、リクエストなどの情報を含むパケットを、リクエストの宛先に送信する。受信部２０７は、リクエストに対するレスポンスなどの情報を含むパケットを受信する。
【００３０】
情報処理装置２００は、インストールされているブラウザ１００を動作させる。サーバ２１０から管理アプリ１５０がダウンロードされると、管理アプリ１５０は、ブラウザ１００によって実現されているトップレベルＢＣ１１０上で実行される。管理アプリ１５０が実行されると、管理アプリ１５０に含まれているコードによる処理は管理アプリ実行部１５１として実現される。管理アプリ実行部１５１は、制御部１５２、実行部１５３、メッセージ出力部１５５、メッセージ取得部１５６、保持部１６０を含む。また、管理アプリ１５０の実行中に管理アプリ実行部１５１がアクセスすることが可能なメモリ１２や記憶装置１６が、保持部１６０として使われる。保持部１６０には、制御情報１６１、アプリ管理情報１６２、出力先情報１６３が含まれる。
【００３１】
メッセージ取得部１５６は、管理アプリ１５０以外のＷｅｂアプリからメッセージを取得する。メッセージ出力部１５５は、管理アプリ１５０以外のＷｅｂアプリにメッセージを出力する。制御部１５２は、ＷｅｂアプリからＷｅｂサービスや他のＷｅｂアプリへのアクセスを許可するかを判定する。このとき、制御部１５２は、制御情報１６１を用いることができる。制御情報１６１は、Ｗｅｂアプリごとに、そのＷｅｂアプリにアクセスを許可するＷｅｂサービスやＷｅｂアプリの情報を対応付けている。アクセスが許可される場合、実行部１５３は、アクセスの要求元のＷｅｂアプリが動作しているブラウジングコンテキストとアクセスに対応付けて通知された識別子を、出力先情報１６３として格納する。実行部１５３は、許可されたアクセスについて、アクセス先へのリクエストの送信とアクセス先から得られたレスポンスをアクセスの要求元のＷｅｂアプリに出力するための制御を、適宜、アプリ管理情報１６２を使用して行う。アプリ管理情報１６２は、ブラウザ１００上で実行されている管理アプリ１５０以外のＷｅｂアプリについて、そのＷｅｂアプリが実行されているブラウジングコンテキストを特定するために使用される。
【００３２】
実行部１５３は、ブラウザ１００からＷｅｂアプリの実行要求を受け取ると、実行要求を受けたＷｅｂアプリを、サーバ２２０からダウンロードする。オリジンＣに属するＷｅｂアプリ１３１をダウンロードする場合、実行部１５３は、サーバ２２０Ｃからダウンロードを行う。なお、Ｗｅｂアプリの実行要求は、例えば、情報処理装置２００のユーザが、ブラウザ１００上のＷｅｂアプリへのリンクボタンを押下するなどのイベントをトリガとして発生する。実行部１５３は、ダウンロードしたＷｅｂアプリを子ＢＣや孫ＢＣで実行させる場合、Ｗｅｂアプリの情報と、そのＷｅｂアプリが実行されるＢＣの情報を対応づけて、アプリ管理情報１６２に追加する。
【００３３】
Ｗｅｂアプリ１３１が実行されると、Ｗｅｂアプリ１３１に含まれているコードによる処理はＷｅｂアプリ実行部１３２として実現される。Ｗｅｂアプリ実行部１３２は、メッセージ出力部１３３、実行部１３４、メッセージ取得部１３５を含む。また、Ｗｅｂアプリ１３１の実行中にＷｅｂアプリ実行部１３２がアクセスすることが可能なメモリ１２や記憶装置１６が、識別情報保持部１３６として使われる。メッセージ出力部１３３は、実行部１３４の処理によって生成されたメッセージを出力する。メッセージ取得部１３５は、メッセージ出力部１５５から出力されたメッセージなどを取得する。実行部１３４は、Ｗｅｂアプリ１３１での処理を実行する。
【００３４】
図３は、情報処理装置２００およびサーバのハードウェア構成の例を説明する図である。情報処理装置２００、サーバ２１０、サーバ２２０、サーバ４００のいずれも、プロセッサ１１、メモリ１２、バス１５、記憶装置１６、ネットワーク接続装置１９を備える。情報処理装置２００、サーバ２１０、サーバ２２０、サーバ４００のいずれも、入力装置１３、出力装置１４、媒体駆動装置１７の１つ以上をさらに有していても良い。
【００３５】
プロセッサ１１は、Central Processing Unit（ＣＰＵ）を含む任意の処理回路である。情報処理装置２００において、プロセッサ１１は、制御部１５２、実行部１５３、メッセージ出力部１５５、メッセージ取得部１５６として動作する。さらに、プロセッサ１１は、メッセージ出力部１３３、実行部１３４、メッセージ取得部１３５として動作する。プロセッサ１１は、処理によって得られたデータの記録や記憶しているデータの取得の際に、適宜、メモリ１２や記憶装置１６を使用する。このため、メモリ１２および記憶装置１６は、保持部１６０を実現する。同様に、メモリ１２や記憶装置１６は、識別情報保持部１３６も実現する。プロセッサ１１は、メモリ１２や記憶装置１６に記憶されたプログラムを実行することができる。プロセッサ１１が実行するプログラムは、例えば、管理アプリ１５０、Ｗｅｂアプリ１２１、Ｗｅｂアプリ１３１などである。なお、サーバ４００においては、プロセッサ１１は実行部４０３として動作する。
【００３６】
メモリ１２には、ＲＡＭ（Random Access Memory）が含まれ、さらに、ＲＯＭ（Read Only Memory）等の不揮発性のメモリも含まれる。記憶装置１６は、例えば、ＨＤＤでもよく、Ｓｏｌｉｄ‐Ｓｔａｔｅ  Ｄｒｉｖｅ（ＳＳＤ）でもよい。サーバ２１０において、メモリ１２および記憶装置１６は記憶部２１１として動作する。同様に、サーバ２２０において、メモリ１２および記憶装置１６は記憶部２２１として動作する。
【００３７】
情報処理装置２００において、ネットワーク接続装置１９は、通信部２０５として動作する。サーバ２１０において、ネットワーク接続装置１９は、通信部２１２として動作する。同様に、ネットワーク接続装置１９は、サーバ２２０において通信部２２２として動作し、サーバ４００において通信部４０２として動作する。バス１５は、プロセッサ１１、メモリ１２、入力装置１３、出力装置１４、記憶装置１６、媒体駆動装置１７、ネットワーク接続装置１９を、相互にデータの送受信が可能になるように接続する。
【００３８】
入力装置１３は、キーボードやマウスなど、情報の入力に使用される任意の装置であり、出力装置１４は、ディスプレイなど、データの出力に使用される任意の装置である。媒体駆動装置１７は、メモリ１２や記憶装置１６のデータを可搬型記憶媒体１８に出力することができ、また、可搬型記憶媒体１８からプログラムやデータ等を読み出すことができる。ここで、可搬型記憶媒体１８は、Compact Disc Recordable（ＣＤ−Ｒ）やDigital Versatile Disk Recordable（ＤＶＤ−Ｒ）を含む、持ち運びが可能な任意の記憶媒体とすることができる。
【００３９】
＜第１の実施形態＞
図４は、各アプリケーションで行われる処理の例を説明する図である。以下、Ｗｅｂアプリ１３１がＷｅｂサービス４０１に対してサービスを要求する場合を例として、Ｗｅｂアプリ実行部１３２、管理アプリ実行部１５１、Ｗｅｂサービス４０１を実行する実行部４０３で行われる処理の例を説明する。
【００４０】
まず、Ｗｅｂアプリ１３１の一部として動作する実行部１３４は、Ｗｅｂサービス４０１に処理を要求することを決定すると、コールバック関数Ｆ１を含む通信用オブジェクトＯＢ１を生成する。コールバック関数Ｆ１は、Ｗｅｂサービス４０１へのリクエストに対して得られるレスポンスを処理する関数である。さらに、実行部１３４は、Ｗｅｂサービス４０１へのリクエストを識別する識別子を生成する。図４では、実行部１３４は、ＩＤａという識別子を生成したとする。実行部１３４は、通信用オブジェクトＯＢ１と識別子ＩＤａを対応付けて、識別情報保持部１３６に保持する。その後、実行部１３４は、識別子ＩＤａとＷｅｂサービス４０１へのリクエストを含むメッセージＭ１を生成し、メッセージＭ１をメッセージ出力部１３３に出力する。メッセージ出力部１３３は、実行部１３４から取得したメッセージＭ１を、管理アプリ１５０が動作しているブラウジングコンテキストに出力する（矢印Ａ１１）。
【００４１】
管理アプリ１５０の一部として動作する制御部１５２は、メッセージＭ１に含まれているリクエストを、矢印Ａ１２に示すように、Ｗｅｂサービス４０１を実行しているサーバに送信するかを、制御情報１６１を用いて判定する。
【００４２】
図５は、制御情報１６１の例を説明する図である。制御情報１６１は、Ｗｅｂアプリからの操作が許可されているＷｅｂサービスの特定に使用される情報であり、ＷｅｂアプリＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）とＷｅｂサービスＵＲＬを含む。ＷｅｂアプリＵＲＬは、Ｗｅｂサービスに対する操作を求めるＷｅｂアプリを示す情報であり、「https://originC.com/webApp1.html」のように、ＵＲＬ方式により示される。制御情報１６１の「https://originC.com」の部分が、オリジンを示す情報であり、この場合は、オリジンＣである。オリジンは、スキームとホストとポートの組み合わせにより識別される。「https://originC.com/webApp1.html」の内、オリジンを示す情報の後に付随している「webApp1.html」の部分は、オリジンに属するＷｅｂアプリを示す情報である。以下の説明では、「https://originC.com/webApp1.html」は、オリジンＣに属するＷｅｂアプリ１３１を示しているとする。
【００４３】
一方、ＷｅｂサービスＵＲＬは、エントリ中のＷｅｂアプリからのアクセスが許可されているＷｅｂサービスを示す情報であり、ＵＲＬ方式で表される。例えば、図５の１番目のエントリより、オリジンＳに属するＷｅｂサービスのうちの「https://originS.com/webServ2.html」へのアクセスが許可されることが特定される。
【００４４】
例えば、Ｗｅｂアプリ１３１が「https://originC.com/webApp1.html」で表され、Ｗｅｂサービス４０１が「https://originS.com/webServ2.html」で表されるとする。この場合、メッセージＭ１のアクセス元のＷｅｂアプリ１３１とアクセス先のＷｅｂサービス４０１は、図５に示す制御情報１６１の１番目のエントリの条件に合致するので、制御部１５２は、メッセージＭ１によるリクエストを許可することを決定する。
【００４５】
図６は、各アプリケーションで行われる処理の例を説明する図である。矢印Ａ１１の処理は図４と同様である。
【００４６】
Ｗｅｂアプリ１３１からＷｅｂサービス４０１へのアクセスを許可する場合、管理アプリ実行部１５１中の実行部１５３は、通信用オブジェクトＯＢ２を生成する。図６の例では、通信用オブジェクトＯＢ２は、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔによる処理に使用されるオブジェクトである。通信用オブジェクトＯＢ２には、管理アプリ１５０とＷｅｂサービス４０１との間でのアクセスの結果として得られたレスポンスを、Ｗｅｂアプリ実行部１３２に出力するためのコールバック関数Ｆ２が含まれる。図６の例では、コールバック関数Ｆ２には、メッセージＭ１においてリクエストに対応付けられた識別子ＩＤａと、Ｗｅｂサービス４０１の呼び出し元のブラウジングコンテキスト１３０の情報が含められている。なお、識別子ＩＤａとブラウジングコンテキスト１３０の情報は、コールバック関数Ｆ２の実行の際に参照可能な領域に格納されていれば、コールバック関数中に含められていなくてもよい。この場合、実行部１５３は、メッセージＭ１に含まれている識別子ＩＤａを、メッセージの送信元のＢＣ１３０と対応付けて、出力先情報１６３に記録する。
【００４７】
Ｗｅｂアプリ１３１からＷｅｂサービス４０１へのアクセスが許可される場合、実行部１５３は、矢印Ａ１１で入力されたメッセージ中のリクエストを、Ｗｅｂサービス４０１に通知することを決定する。このとき、Ｗｅｂサービス４０１宛てのリクエストのオリジンとして、制御部１５２は、管理用オリジンを指定する。制御部１５２は、矢印Ａ１１で入力されたメッセージ中のリクエストを、メッセージ出力部１５５を介して、送信部２０６に出力する。送信部２０６は、リクエストを含むパケットを、サーバ４００に送信する（矢印Ａ１２）。
【００４８】
Ｗｅｂサービス４０１では、管理用オリジンに属するアプリケーション（管理アプリ１５０）から送信されたメッセージを処理する。Ｗｅｂサービス４０１は、メッセージ中のリクエストに対する処理を行った結果を、管理アプリ１５０で処理されるデータとして含めたレスポンスを生成する。サーバ４００は、レスポンスを含むメッセージを情報処理装置２００に送信する。情報処理装置２００でのメッセージの受信処理により、管理アプリ実行部１５１中のメッセージ取得部１５６はレスポンスを取得する（矢印Ａ２１）。
【００４９】
メッセージ取得部１５６は、Ｗｅｂサービス４０１からのレスポンスを、実行部１５３に出力する。実行部１５３は、Ｗｅｂサービス４０１からのレスポンスを処理するために、コールバック関数Ｆ２を呼び出す。コールバック関数Ｆ２には、識別子ＩＤａとメッセージＭ１の送信元のＷｅｂアプリ１３１が動作している子ＢＣ１３０の情報が含まれている。そこで、実行部１５３は、Ｗｅｂサービス４０１から得られたレスポンスの引き渡し先のＷｅｂアプリ１３１を、アプリ管理情報１６２（図７）を用いて特定する。Ｗｅｂアプリ１３１を特定する際に行われる処理については後述する。実行部１５３は、特定したＷｅｂアプリ１３１に出力するメッセージとして、Ｗｅｂサービス４０１から得られたレスポンスと、識別子ＩＤａを含むメッセージＭ２を生成する。実行部１５３は、メッセージＭ２を、メッセージ出力部１５５を介して、子ＢＣ１３０に向けて出力する（矢印Ａ２２）。
【００５０】
子ＢＣ１３０では、Ｗｅｂアプリ実行部１３２中のメッセージ取得部１３５がメッセージＭ２を取得して、実行部１３４に出力する。実行部１３４は、メッセージＭ２に識別子ＩＤａが含まれていることを特定する。さらに、実行部１３４は、識別情報保持部１３６において、識別子ＩＤａに対応付けられているオブジェクトを用いて、メッセージＭ２で通知された情報を処理することを決定する。識別情報保持部１３６では、識別子ＩＤａにオブジェクトＯＢ１が対応付けられているので、実行部１３４は、メッセージＭ２で通知された情報をオブジェクトＯＢ１によって処理する。オブジェクトＯＢ１には、識別子ＩＤａに対応付けて管理アプリ１５０に出力されたリクエストに対するレスポンスを処理するコールバック関数Ｆ１が含まれている。このため、実行部１３４は、管理アプリ１５０を介して取得したＷｅｂサービス４０１での処理結果を、コールバック関数Ｆ１で処理できる。
【００５１】
図７は、アプリ管理情報１６２の例を説明する図である。アプリ管理情報１６２は、ＢＣ情報とＷｅｂアプリ情報を対応付けている。Ｗｅｂアプリ情報は、Ｗｅｂアプリと、そのＷｅｂアプリが属するオリジンとを示す情報であり、図７の例では、制御情報１６１（図５）と同様にＵＲＬで表記されている。ＢＣ情報は、エントリ中のＷｅｂアプリが実行されているブラウジングコンテキストを識別する情報である。なお、Ｗｅｂアプリ管理情報のＷｅｂアプリ情報は、ＵＲＬに限られず、Ｗｅｂアプリを識別できる任意の形式の情報でよい。また、ＢＣ情報も、ＢＣを特定できる任意の形式の情報でよい。
【００５２】
アプリ管理情報１６２は、管理アプリ１５０が、他のＷｅｂアプリを管理するために用いる情報であり、ブラウジングコンテキストから、そのブラウジングコンテキストで実行されているＷｅｂアプリを特定する際に使用される。例えば、図６の例では、実行部１５３は、Ｗｅｂアプリ１３１を特定する際に、Ｗｅｂサービス４０１から取得したレスポンスを処理するオブジェクトＯＢ２に含まれているＢＣ情報が子ＢＣ１３０であることを特定している。すると、実行部１５３は、子ＢＣ１３０をキーとして、子ＢＣ１３０に対応づけられているＷｅｂアプリを、アプリ管理情報１６２から特定する。図７の例では、２番目のエントリに、ＢＣ情報として「ＢＣ１３０」、Ｗｅｂアプリ情報として「https://originC.com/webApp1.html」が登録されている。このため、実行部１５３は、「https://originC.com/webApp1.html」で識別されるＷｅｂアプリ１３１に、Ｗｅｂサービス４０１から取得したレスポンスを引き渡すことを決定する。
【００５３】
図８は、各アプリケーションで行われる処理の例を説明するシーケンス図である。図８では、Ｗｅｂアプリ実行部１３２から管理アプリ１５０が動作しているブラウジングコンテキストに出力されるメッセージの送信が２つのコマンドを用いて行われる場合を例としている。さらに、図８の例では、オブジェクトでなく、コールバック関数が識別子と対応付けられる場合を説明している。なお、図８においても、Ｗｅｂアプリ１３１はオリジンＣに属しており、Ｗｅｂサービス４０１はオリジンＳに属しているものとする。
【００５４】
Ｗｅｂアプリ１３１の一部として動作する実行部１３４は、Ｗｅｂサービス４０１での処理を要求する際に、Ｗｅｂサービス４０１での処理によって得られたレスポンスを処理するために使用するコールバック関数Ｆ１を生成する（ステップＳ１）。さらに、実行部１３４は、Ｗｅｂサービス４０１へのリクエストを識別するための識別子を生成するとともに、コールバック関数Ｆ１を識別子と対応付けて記憶する。
【００５５】
Ｗｅｂアプリ１３１の一部として動作するメッセージ出力部１３３は、Ｗｅｂサービス４０１に対するアクセスを要求することを管理アプリ実行部１５１に通知するための処理を行う。図８の例では、メッセージ出力部１３３は、ｐｏｓｔＭｅｓｓａｇｅ（ｏｐｅｎ）をメッセージ取得部１５６に出力する（ステップＳ２）。
【００５６】
制御部１５２は、ｐｏｓｔＭｅｓｓａｇｅ（ｏｐｅｎ）によってアクセスが要求されているＷｅｂサービス４０１に対してＷｅｂアプリ１３１がアクセス可能であるかを、制御情報１６１を用いて判定する（ステップＳ３）。Ｗｅｂアプリ１３１にＷｅｂサービス４０１へのアクセスを許可しない場合、制御部１５２は、メッセージ出力部１５５を介して、Ｗｅｂアプリ実行部１３２にエラーメッセージを出力する。
【００５７】
図８の例では、Ｗｅｂアプリ１３１にＷｅｂサービス４０１へのアクセスを許可する場合を示している。Ｗｅｂアプリ１３１にＷｅｂサービス４０１へのアクセスを許可する場合、実行部１５３は、Ｗｅｂサービス４０１へのアクセスを行うためのオブジェクトを生成する。図８の例では、実行部１５３は、ＨＴＭＬ５のＸＭＬＨｔｔｐＲｅｑｕｅｓｔを用いて、ｘｈｒオブジェクトを生成する（ステップＳ４）。次に、実行部１５３は、生成したｘｈｒオブジェクトに、コールバック関数を登録する。ｘｈｒオブジェクト中のコールバック関数は、管理アプリ実行部１５１がＷｅｂサービス４０１から取得したレスポンスをＷｅｂアプリ実行部１３２に引き渡すために使用される（ステップＳ５）。ｘｈｒオブジェクトは、例えば、下に示すコードで実現されてもよい。
var obj = {
var win, id, xhr;
};
obj.win = targetWindow;
obj.id = targetId;
obj.xhr = new XMLHttpRequest;
obj.xhr.onload = function (event) {
if (xhr.readyState === 4 && xhr.status === 200) {
obj.win.postMessage(obj.id + “,” + xhr.responseText, “*”);
}
};
【００５８】
メッセージ出力部１５５は、Ｗｅｂアプリ実行部１３２から取得するＷｅｂサービス４０１宛てのリクエストを、Ｗｅｂサービス４０１が実行されているサーバ４００に送信するための処理を行う。図８の例では、メッセージ出力部１５５は、ｘｈｒ．ｏｐｅｎにより、Ｗｅｂサービス４０１へのアクセスのための処理を実行する（ステップＳ６）。
【００５９】
メッセージ出力部１３３は、ｐｏｓｔＭｅｓｓａｇｅ（ｓｅｎｄ）をメッセージ取得部１５６に出力することにより、Ｗｅｂサービス４０１へのリクエストと識別子の組み合わせをメッセージ取得部１５６に出力する（ステップＳ７）。なお、ステップＳ７においてリクエストとともに出力される識別子は、ステップＳ１においてコールバック関数Ｆ１に対応付けられている識別子である。
【００６０】
メッセージ取得部１５６は、ｐｏｓｔＭｅｓｓａｇｅ（ｓｅｎｄ）を取得すると、実行部１５３に出力する。実行部１５３は、ｘｈｒ．ｓｅｎｄを用いて、ｐｏｓｔＭｅｓｓａｇｅ（ｓｅｎｄ）で取得したリクエストを、Ｗｅｂサービス４０１を実行しているサーバに送信するためのメッセージを生成する。メッセージ出力部１５５は、送信部２０６を介して、ｘｈｒ．ｓｅｎｄを用いたメッセージを、Ｗｅｂサービス４０１が実行されているサーバ４００に送信する（ステップＳ８）。
【００６１】
サーバ４００での受信処理により、Ｗｅｂサービス４０１が管理アプリ１５０から出力されたメッセージを取得したとする。Ｗｅｂサービス４０１は、取得したメッセージに含まれているリクエストを処理することにより、レスポンスを生成する（ステップＳ９）。Ｗｅｂサービス４０１を実行する実行部４０３は、通信部４０２を介して、情報処理装置２００に向けてレスポンスを送信する（ステップＳ１０）。
【００６２】
メッセージ取得部１５６は、受信部２０７を介して、Ｗｅｂサービス４０１からのレスポンスを含むパケットを取得する。実行部１５３は、メッセージ取得部１５６を介して、レスポンスを取得すると、ステップＳ４、Ｓ５で生成したｘｈｒオブジェクトによる処理を行う。このため、実行部１５３は、レスポンスと、そのレスポンスに対応するリクエストに関連付けられている識別子を含むメッセージを生成する。なお、生成されたメッセージを、Ｗｅｂアプリ実行部１３２が実行されているブラウジングコンテキスト１３０に出力することも、ｘｈｒオブジェクトから特定される。メッセージ出力部１５５は、実行部１５３で生成されたメッセージをメッセージ取得部１３５に出力する（ステップＳ１１）。メッセージ取得部１３５は、取得したメッセージを実行部１３４に出力する。実行部１３４は、取得したメッセージ中の識別子から、レスポンスを処理するコールバック関数を特定する。実行部１３４は、メッセージ中のレスポンスを、特定したコールバック関数に引き渡す。
【００６３】
図９は、第１の実施形態にかかる方法で行われる通信の例を説明する図である。第１の実施形態にかかる方法により、あるＷｅｂアプリ１３１のＷｅｂアプリ実行部１３２が、異なるオリジンのＷｅｂサービス４０１へアクセスし、Ｗｅｂサービス４０１で得られたレスポンスを取得することができる。すなわち、オリジンＣに属するＷｅｂアプリケーションのＷｅｂアプリ実行部１３２が、管理アプリ１５０を介して、オリジンＣとは異なるオリジンＳに属するＷｅｂサービス４０１にアクセスすることができる。このとき、管理アプリ１５０では、Ｗｅｂアプリ実行部１３２から管理アプリ実行部１５１に出力されたアクセス依頼を、管理用オリジンを用いて、Ｗｅｂサービス４０１に中継する。Ｗｅｂサービス４０１は、管理用オリジンから要求されたアクセスを受け入れて処理を行う。さらに、Ｗｅｂサービス４０１からのレスポンスも、管理アプリ１５０を介してＷｅｂアプリ実行部１３２に出力される。
【００６４】
ここで、管理アプリ１５０によって、制御情報１６１を用いたアクセス制御が行われるため、予め許容するアクセスとして制御情報１６１に登録されていないＷｅｂアプリからのＷｅｂサービスへのアクセスを、管理アプリ１５０が防止することができる。また、Ｗｅｂアプリ実行部１３２が管理アプリ１５０を介さずにＷｅｂサービス４０１にアクセスした場合も、オリジンが異なるために、アクセスを禁止することができる。
【００６５】
このように、第１の実施形態によると、ブラウザ１００で動作しているＷｅｂアプリに応じて、異なるオリジンのＷｅｂサービスに対するアクセスを許可するかを判定することができる。また、アクセスが許可されたＷｅｂアプリは、管理アプリ１５０を介して、アクセス先のＷｅｂサービスからレスポンスを取得することができる。このため、Ｗｅｂアプリケーションごとに、Ｗｅｂサービスへのアクセスを制御することが可能になる。
【００６６】
＜第２の実施形態＞
図１０は、第２の実施形態で使用される制御情報１６１の例を説明する図である。第２の実施形態では、制御情報１６１には、ＷｅｂアプリＵＲＬ、ＷｅｂサービスＵＲＬ、ユーザリストが含まれる。第２の実施形態では、各Ｗｅｂアプリの実行時に、ユーザは、ブラウザ１００の表示画面からユーザ情報を入力するように求められるものとする。また、第２の実施形態では、制御部１５２での判定処理は図１０に示す制御情報１６１を用いて行われる。
【００６７】
第２の実施形態では、アクセスの可否は、ＷｅｂアプリＵＲＬ、ＷｅｂサービスＵＲＬ、ユーザリストの組み合わせで決定される。ユーザリストには、ＷｅｂアプリＵＲＬ、ＷｅｂサービスＵＲＬの組み合わせの各々について、アクセスを許可するユーザが記録される。例えば、ＷｅｂアプリＵＲＬ＝「https://originC.com/webApp1.html」のＷｅｂアプリからユーザＰがＷｅｂサービスＵＲＬ＝「https://originS.com/webServ2.html」のＷｅｂサービスにアクセスしようとしたとする。この場合、管理アプリ実行部１５１は、図１０に示す制御情報１６１の１番目のエントリの情報を用いて、アクセスを許可する。アクセスが許可される場合の処理は、第１の実施形態と同様である。
【００６８】
一方、ＷｅｂアプリＵＲＬ＝「https://originC.com/webApp1.html」のＷｅｂアプリからユーザＱがＷｅｂサービスＵＲＬ＝「https://originS.com/webServ2.html」のＷｅｂサービス４０１にアクセスしようとしたとする。この場合、このアクセスについてのＷｅｂアプリＵＲＬ、ＷｅｂサービスＵＲＬ、ユーザリストの組み合わせは制御情報１６１に無いため、管理アプリ実行部１５１はアクセスを許可しない。制御部１５２は、アクセスを許可しないことを決定すると、メッセージ出力部１５５を介して、エラーメッセージを、アクセスの要求元のＷｅｂアプリが実行されているブラウジングコンテキストに出力する。
【００６９】
なお、アクセスが許可されるユーザの数は、ＷｅｂアプリＵＲＬとＷｅｂサービスＵＲＬの組み合わせごとに任意に設定され得る。例えば、２番目のエントリに基づいて、「https://originC.com/webApp1.html」のＷｅｂアプリから「https://originS.com/webServ3.html?name=abc」のＷｅｂサービスには、ユーザＰとユーザＱがアクセスできる。また、図１０に示すように、全ユーザに対してアクセスが許可されるＷｅｂアプリＵＲＬ、ＷｅｂサービスＵＲＬの組み合わせも設定されてもよい。
【００７０】
このように、第２の実施形態では、第１の実施形態と同様に、Ｗｅｂアプリケーションごとに、Ｗｅｂサービスへのアクセスを制御することが可能になるだけでなく、ユーザ別の制御も可能になる。
【００７１】
＜第３の実施形態＞
図１１は、第３の実施形態で使用される制御情報１６１の例を説明する図である。図１１は、ＷｅｂアプリやＷｅｂサービスをグループ化してアクセス制御が行われる場合の制御情報１６１の例である。制御情報１６１は、Ｗｅｂアプリリスト、Ｗｅｂサービスリスト、ユーザリストを含む。第３の実施形態でも、各Ｗｅｂアプリの実行時に、ユーザは、ブラウザ１００の表示画面からユーザ情報を入力するように求められるものとする。また、第３の実施形態では、制御部１５２での判定処理は図１１に示す制御情報１６１を用いて行われる。
【００７２】
グループ情報は、少なくとも１つのＷｅｂアプリとＷｅｂサービスの組み合わせを含むグループを識別するための情報である。Ｗｅｂアプリリストは、グループに属しているＷｅｂアプリを特定可能なリストである。Ｗｅｂサービスリストは、グループに属しているＷｅｂサービスを特定可能なリストである。図１１では、紙面の関係から、ＷｅｂサービスについてはＵＲＬ表記をしていないが、Ｗｅｂサービスの表記方法はＷｅｂサービスを特定可能な任意の表記方法でよい。同様に、Ｗｅｂアプリリスト中の各Ｗｅｂアプリの情報も、ＵＲＬ表記以外の任意の方法で行われ得る。ユーザリストは、そのグループに属しているＷｅｂアプリから、そのグループに属しているＷｅｂサービスへのアクセスが許可されているユーザを示すリストである。
【００７３】
図１１の制御情報の例では、「グループＧ１」に属するＷｅｂアプリは、「https://originC.com/webApp1.html」、「https://originC.com/webApp2.html」、「https://originS.com/webServ3.html?name=abc」で表される各Ｗｅｂアプリである。「グループＧ１」に属するＷｅｂサービスは、Ｗｅｂサービス４０１、Ｗｅｂサービス５０１で表される各Ｗｅｂサービスである。グループＧ１のＷｅｂアプリリスト中のＷｅｂアプリから、グループＧ１のＷｅｂサービスリスト中のＷｅｂサービスへのアクセスが許可されているユーザは、ユーザリストに示されるユーザＰ及びユーザＱである。つまり、ユーザＰ又はユーザＱがグループＧ１のＷｅｂアプリリストに含まれている任意のＷｅｂアプリから、グループＧ１のＷｅｂサービスリストに含まれている任意のＷｅｂサービスへアクセスする場合、アクセスが許可される。
【００７４】
「グループＧ２」には、ＷｅｂアプリＵＲＬ＝「https://originC.com/webApp5.html」のＷｅｂアプリと、「https://originA.com/webApp4.html」で表されるＷｅｂアプリが分類されている。「グループＧ２」に属するＷｅｂサービスは、Ｗｅｂサービス４４１である。グループＧ２でのアクセスが許可されているユーザはユーザＰとユーザＲである。したがって、ユーザＰとユーザＲに対しては、グループＧ２のＷｅｂアプリリストに含まれている任意のＷｅｂアプリから、グループＧ２のＷｅｂサービスリストに含まれている任意のＷｅｂサービスへアクセスする場合、アクセスが許可される。
【００７５】
このように、第３の実施形態では、第１の実施形態と同様に、Ｗｅｂアプリケーションごとに、Ｗｅｂサービスへのアクセスを制御する際に、グループごとに設定を行うことが可能になる。このため、設定内容の登録や管理等の効率化が期待できる。
【００７６】
＜変形例＞
なお、実施形態は上記に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。
【００７７】
図１２は、Ｗｅｂアプリ間での処理の例を説明する図である。以下、図１２を用いて、あるＷｅｂアプリがオリジンの異なるＷｅｂアプリにアクセスして、アクセス先のＷｅｂアプリからレスポンスを取得する方法について説明する。図１２では、トップレベルＢＣ１１０において管理アプリ１５０、子ＢＣ１２０においてＷｅｂアプリ１２１、子ＢＣ１３０においてＷｅｂアプリ１３１が実行されている。以下、オリジンＣに属するＷｅｂアプリ１３１が、管理アプリ１５０を介して、オリジンＢに属するＷｅｂアプリ１２１にアクセスし、レスポンスを取得する場合を例として、通信方法の例を説明する。
【００７８】
まず、Ｗｅｂアプリ１３１の一部として動作する実行部１３４は、Ｗｅｂアプリ１２１へのリクエストと、そのリクエストを識別する識別子ＩＤｂを生成する。また、実行部１３４は、識別子ＩＤｂに対応付けられたレスポンスを処理するためのコールバック関数Ｆ１１を生成して、識別子ＩＤｂに対応付けて記憶する。その後、実行部１３４は、管理アプリ実行部１５１中のメッセージ取得部１５６に対して、リクエストと識別子ＩＤｂを含むメッセージを出力する（矢印Ａ３１）。
【００７９】
管理アプリ実行部１５１で動作する制御部１５２は、Ｗｅｂアプリ１３１からＷｅｂアプリ１２１へのアクセスを許可することを決定したとする。この場合、実行部１５３は、Ｗｅｂアプリ１２１からのレスポンスの処理を行うためのコールバック関数Ｆ２を生成するとともに、コールバック関数Ｆ２の処理の際に使用する情報として、識別子ＩＤｂと子ＢＣ１３０を対応付ける。次に、実行部１５３は、Ｗｅｂアプリ１２１に対して、管理用オリジンを用いてリクエストを出力する際に通知する識別子ＩＤｘを生成し、コールバック関数Ｆ２に関連付けて記憶する。この処理により、実行部１５３は、識別子ＩＤｘに対応付けて通知されたレスポンスを、コールバック関数Ｆ２で処理することを記憶する。実行部１５３は、Ｗｅｂアプリ１３１から取得したリクエストを、識別子ＩＤｘに対応付けて、Ｗｅｂアプリ１２１に出力する（矢印Ａ３２）。
【００８０】
Ｗｅｂアプリ１２１を実行する実行部は、管理用オリジンに属するアプリケーションから送信されたメッセージを処理し、得られた結果を、管理アプリ１５０で処理されるデータとして含めたメッセージを生成する。このとき、管理アプリ１５０に出力されるメッセージには、管理アプリ１５０からＷｅｂアプリ１２１に通知されたリクエストに対するレスポンスと識別子ＩＤｘが含まれている。Ｗｅｂアプリ１２１の実行部は、レスポンスを含むメッセージをメッセージ取得部１５６に出力する。（矢印Ａ３３）。
【００８１】
実行部１５３は、取得したレスポンスに識別子ＩＤｘが対応付けられていることから、レスポンスを処理するためにコールバック関数Ｆ２を呼び出す。コールバック関数Ｆ２は、レスポンスと、ＢＣ１３０に対応付けて記憶している識別子ＩＤｂを含むメッセージを、子ＢＣ１３０に出力する（矢印Ａ３４）。
【００８２】
実行部１３４は、取得したメッセージ中に、識別子ＩＤｂが記録されていることから、取得したメッセージには、Ｗｅｂアプリ１２１へのリクエストに対するレスポンスが含まれていると判定する。実行部１３４は、メッセージ中のレスポンスを、コールバック関数Ｆ１１を用いて処理する。
【００８３】
一方、図１２において、Ｗｅｂアプリ１３１が管理アプリ１５０を介さずにＷｅｂアプリ１２１にアクセスを要求した場合、Ｗｅｂアプリ１３１とＷｅｂアプリ１２１ではオリジンが異なるので、破線の矢印で示すようにアクセスは許可されない。このように、管理アプリ１５０は、Ｗｅｂサービスだけでなく、Ｗｅｂアプリ間でのアクセスの中継も行うことができる。
【００８４】
第１の実施形態では、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔを用いたオブジェクトによって、Ｗｅｂサービス４０１からレスポンスを取得する場合を例としたが、他の手法によってＷｅｂサービス４０１からレスポンスが取得されても良い。例えば、図１２を参照しながら説明したように、実行部１５３がＷｅｂサービス４０１に出力するリクエストを一意に特定するための識別子を生成して、コールバック関数に対応付けて記憶しておいても良い。この場合、Ｗｅｂサービス４０１からのレスポンスに含まれている識別子に対応するコールバック関数を実行することにより、実行部１５３は、アクセスの要求元のＷｅｂアプリ１３１に対して、レスポンスを出力する。なお、実行部１５３は、Ｗｅｂアプリ１３１にレスポンスを出力する際には、第１の実施形態と同様に、Ｗｅｂアプリ１３１からリクエストに対応付けて通知された識別子をレスポンスに対応付ける。
【００８５】
以上の説明に使用したコード、メッセージに含まれる情報要素、テーブル中の情報要素は、いずれも例示であり、実装に応じて変更され得る。
【００８６】
さらに、第３の実施形態において、制御情報１６１にユーザリストが含まれていなくてもよい。この場合、グループの条件となっているＷｅｂアプリとＷｅｂサービスの組み合わせであれば、ユーザに関係なく、アクセスが許可される。
【００８７】
なお、Ｗｅｂアプリごとのアクセス制限が行われない場合であっても、以上の説明と同様の方法により、管理アプリ１５０は、Ｗｅｂアプリから他のＷｅｂサービスやＷｅｂアプリへのアクセスを中継することができる。Ｗｅｂアプリごとのアクセス制限が行われない場合、管理アプリ実行部１５１は、制御部１５２を備えなくても良い。
【００８８】
上述の第１〜第３の実施形態を含む実施形態に関し、さらに以下の付記を開示する。
（付記１）
第１のＷｅｂアプリケーションを実行する第１の実行部と、
前記第１の実行部からＷｅｂサービスへのリクエストと前記リクエストを識別する識別子を取得するとともに、前記リクエストを前記Ｗｅｂサービスへ中継する第２のＷｅｂアプリケーションを実行する第２の実行部と、
前記Ｗｅｂサービスを提供するサーバと通信する通信部
を備え、
前記第２の実行部は、前記通信部を介して前記リクエストに対するレスポンスを取得すると、前記レスポンスと前記識別子を含むメッセージを、前記第１の実行部に出力し、
前記第１の実行部は、前記レスポンスを前記リクエストに対する前記Ｗｅｂサービスでの処理結果として処理する
ことを特徴とする情報処理装置。
（付記２）
前記第２の実行部は、
前記第１の実行部から通知された識別子を、前記第１のＷｅｂアプリケーションが実行されているブラウジングコンテキストと対応付けて記憶し、
前記メッセージを、前記識別子に対応付けられたブラウジングコンテキストに出力することにより、前記メッセージを前記第１の実行部に引き渡す
ことを特徴とする付記１に記載の情報処理装置。
（付記３）
前記第２の実行部は、前記第１のＷｅｂアプリケーションからのアクセスを許可するＷｅｂサービスを特定する制御情報を保持し、
前記通信部は、前記第１の実行部から取得したリクエストを処理するＷｅｂサービスが前記制御情報に含まれている場合、前記リクエストを前記サーバに送信する
ことを特徴とする付記１または２に記載の情報処理装置。
（付記４）
第３のＷｅｂアプリケーションを実行する第３の実行部を備え、
前記第２の実行部は、
前記第１の実行部から前記第３のＷｅｂアプリケーションに対して戻り値を要求する他のリクエストと前記他のリクエストを識別する第１の識別子を取得し、
前記他のリクエストの処理の要求と第２の識別子を対応付けて、前記第３の実行部に出力し、
前記第２の識別子に対応付けて前記第３の実行部から通知された値を前記他のリクエストの処理によって得られた前記戻り値として特定し、
前記戻り値と前記第１の識別子を含むメッセージを、前記第１の実行部に出力する
ことを特徴とする付記１〜３のいずれか１項に記載の情報処理装置。
（付記５）
第１のＷｅｂアプリケーションを実行し、
前記第１のＷｅｂアプリケーションからＷｅｂサービスへのリクエストと前記リクエストを識別する識別子を取得するとともに、前記リクエストを前記Ｗｅｂサービスへ中継する第２のＷｅｂアプリケーションを実行し、
前記Ｗｅｂサービスを提供するサーバと通信することにより、前記リクエストに対するレスポンスを取得し、
前記レスポンスと前記識別子を含むメッセージを、前記第２のＷｅｂアプリケーションから前記第１のＷｅｂアプリケーションに出力し、
前記第１のＷｅｂアプリケーションで、前記レスポンスを前記リクエストに対する前記Ｗｅｂサービスでの処理結果として処理する
処理を情報処理装置が行うことを特徴とする情報処理方法。
（付記６）
前記情報処理装置は、
前記第１のＷｅｂアプリケーションから前記第２のＷｅｂアプリケーションに通知された識別子を、前記第１のＷｅｂアプリケーションが実行されているブラウジングコンテキストと対応付けて記憶し、
前記メッセージを、前記識別子に対応付けられたブラウジングコンテキストに出力することにより、前記メッセージを前記第１のＷｅｂアプリケーションに引き渡す
ことを特徴とする付記５に記載の情報処理方法。
（付記７）
前記情報処理装置は、
前記第１のＷｅｂアプリケーションからのアクセスを許可するＷｅｂサービスを特定する制御情報を参照し、
前記リクエストを処理するＷｅｂサービスが前記制御情報に含まれている場合、前記リクエストを前記サーバに送信する
ことを特徴とする付記５または６に記載の情報処理方法。
（付記８）
前記情報処理装置は、
第３のＷｅｂアプリケーションを実行し、
前記第１のＷｅｂアプリケーションから前記第３のＷｅｂアプリケーションに対して戻り値を要求する他のリクエストと、前記他のリクエストを識別する第１の識別子を、前記第１のＷｅｂアプリケーションから前記第２のＷｅｂアプリケーションに出力し、
前記他のリクエストの処理の要求と第２の識別子を対応付けて、前記第２のＷｅｂアプリケーションから、前記第３のＷｅｂアプリケーションに出力し、
前記第２の識別子に対応付けて前記第３のＷｅｂアプリケーションから前記第２のＷｅｂアプリケーションに通知された値を、前記他のリクエストの処理によって得られた前記戻り値として特定し、
前記戻り値と前記第１の識別子を含むメッセージを、前記第１のＷｅｂアプリケーションに出力する
ことを特徴とする付記５〜７のいずれか１項に記載の情報処理方法。
（付記９）
第１のＷｅｂアプリケーションを実行し、
前記第１のＷｅｂアプリケーションからＷｅｂサービスへのリクエストと前記リクエストを識別する識別子を取得するとともに、前記リクエストを前記Ｗｅｂサービスへ中継する第２のＷｅｂアプリケーションを実行し、
前記Ｗｅｂサービスを提供するサーバと通信することにより、前記リクエストに対するレスポンスを取得し、
前記レスポンスと前記識別子を含むメッセージを、前記第２のＷｅｂアプリケーションから前記第１のＷｅｂアプリケーションに出力し、
前記第１のＷｅｂアプリケーションで、前記レスポンスを前記リクエストに対する前記Ｗｅｂサービスでの処理結果として処理する
処理を情報処理装置に実行させることを特徴とする処理プログラム。
（付記１０）
前記情報処理装置に、
前記第１のＷｅｂアプリケーションから前記第２のＷｅｂアプリケーションに通知された識別子を、前記第１のＷｅｂアプリケーションが実行されているブラウジングコンテキストと対応付けて記憶し、
前記メッセージを、前記識別子に対応付けられたブラウジングコンテキストに出力することにより、前記メッセージを前記第１のＷｅｂアプリケーションに引き渡す
処理を実行させることを特徴とする付記１０に記載の処理プログラム。
（付記１１）
前記情報処理装置に、
前記第１のＷｅｂアプリケーションからのアクセスを許可するＷｅｂサービスを特定する制御情報を参照し、
前記リクエストを処理するＷｅｂサービスが前記制御情報に含まれている場合、前記リクエストを前記サーバに送信する
処理を実行させることを特徴とする付記９または１０に記載の処理プログラム。
（付記１２）
前記情報処理装置に、
第３のＷｅｂアプリケーションを実行し、
前記第１のＷｅｂアプリケーションから前記第３のＷｅｂアプリケーションに対して戻り値を要求する他のリクエストと、前記他のリクエストを識別する第１の識別子を、前記第２のＷｅｂアプリケーションに出力し、
前記他のリクエストの処理の要求と第２の識別子を対応付けて、前記第２のＷｅｂアプリケーションから、前記第３のＷｅｂアプリケーションに出力し、
前記第２の識別子に対応付けて前記第３のＷｅｂアプリケーションから前記第２のＷｅｂアプリケーションに通知された値を、前記他のリクエストの処理によって得られた前記戻り値として特定し、
前記戻り値と前記第１の識別子を含むメッセージを、前記第１のＷｅｂアプリケーションに出力する
ことを特徴とする付記９〜１１のいずれか１項に記載の処理プログラム。
【符号の説明】
【００８９】
１１  プロセッサ
１２  メモリ
１３  入力装置
１４  出力装置
１５  バス
１６  記憶装置
１７  媒体駆動装置
１８  可搬型記憶媒体
１９  ネットワーク接続装置
１００  ブラウザ
１１０  トップレベルＢＣ
１２０、１３０  子ＢＣ
１２１、１３１  Ｗｅｂアプリ
１３２  Ｗｅｂアプリ実行部
１３３、１５５  メッセージ出力部
１３４、１５３、４０３  実行部
１３５、１５６  メッセージ取得部
１３６  識別情報保持部
１５０  管理アプリ
１５１  管理アプリ実行部
１５２  制御部
１６０  保持部
１６１  制御情報
１６２  アプリ管理情報
１６３  出力先情報
２００  情報処理装置
２０５、２１２、２２２、４０２  通信部
２０６  送信部
２０７  受信部
２１０、２２０、４００  サーバ
２１１、２２１  記憶部
４０１  Ｗｅｂサービス
【図１】
2017062659.tif 000003
【図２】
2017062659.tif 000004
【図３】
2017062659.tif 000005
【図４】
2017062659.tif 000006
【図５】
2017062659.tif 000007
【図６】
2017062659.tif 000008
【図７】
2017062659.tif 000009
【図８】
2017062659.tif 000010
【図９】
2017062659.tif 000011
【図１０】
2017062659.tif 000012
【図１１】
2017062659.tif 000013
【図１２】
2017062659.tif 000014