(57)【要約】【課題】サーバで提供されるサービスの利便性を向上させる。【解決手段】情報処理装置１０は、記憶部１１と処理部１２とを有する。記憶部１１は、サーバ２にユーザが有するアカウントの第１認証情報と、ユーザがログインしたときにサーバ２が生成したセッションＩＤ４とを記憶する。処理部１２は、ユーザが利用する利用装置１から第２認証情報が含まれた処理要求５を受信すると、第２認証情報を第１認証情報と照合する。第２認証情報と第１認証情報とが一致した場合、処理部１２は、処理要求５に応じた処理に使用するデータ７の取得要求６にセッションＩＤを含め、取得要求６をサーバ２に送信する。【選択図】図１
2018060259.tif 000002
【特許請求の範囲】
【請求項１】
サーバにユーザが有するアカウントの第１認証情報と、前記ユーザが前記アカウントでログインしたときに前記サーバが生成したセッションＩＤとを記憶する記憶部と、
前記ユーザが利用する利用装置から第２認証情報が含まれた処理要求を受信すると、前記第２認証情報を前記第１認証情報と照合し、前記第２認証情報と前記第１認証情報とが一致した場合、前記処理要求に応じた処理に使用するデータの取得要求に前記セッションＩＤを含め、前記取得要求を前記サーバに送信する処理部と、
を有する情報処理装置。
【請求項２】
前記処理部は、さらに、
前記取得要求の送信後に前記サーバから応答された前記データを用いて前記処理要求に従った処理を実行し、処理の実行結果を前記利用装置に送信する、
請求項１記載の情報処理装置。
【請求項３】
前記処理部は、さらに、
前記第１認証情報が含まれたログイン要求を前記利用装置から受信すると、前記サーバ内の所定の資源宛てに前記ログイン要求を送信し、前記サーバから前記セッションＩＤを受信すると、前記第１認証情報と前記セッションＩＤとを前記記憶部に格納する、
請求項１または２記載の情報処理装置。
【請求項４】
前記処理部は、さらに、
前記記憶部に記憶された前記セッションＩＤに示されている有効期限情報に基づいて、前記セッションＩＤの有効期限が切れているか否かを判断し、有効期限が切れている場合、前記記憶部から前記第１認証情報を取得し、前記第１認証情報を含む再ログイン要求を前記サーバに送信し、前記サーバから新規セッションＩＤを含むログイン完了応答を受信すると、前記記憶部内の前記セッションＩＤを、前記新規セッションＩＤに更新する、
請求項１乃至３のいずれかに記載の情報処理装置。
【請求項５】
ユーザのアカウントに対応する第１認証情報を記憶しており、前記ユーザが前記第１認証情報を用いてログインするとセッションＩＤを生成し、前記セッションＩＤを含む取得要求に応じてデータを提供するサーバと、
前記ユーザが利用する利用装置から第２認証情報が含まれた処理要求を受信すると、前記第１認証情報と、前記ユーザが前記アカウントでログインしたときに前記サーバが生成した前記セッションＩＤとを記憶する記憶部を参照し、前記第２認証情報を前記第１認証情報と照合し、前記第２認証情報と前記第１認証情報とが一致した場合、前記処理要求に応じた処理に使用する前記データの前記取得要求に前記セッションＩＤを含め、前記取得要求を前記サーバに送信する情報処理装置と、
を有する情報処理システム。
【請求項６】
コンピュータが、
ユーザが利用する利用装置から第２認証情報が含まれた処理要求を受信すると、サーバに前記ユーザが有するアカウントの第１認証情報と、前記ユーザが前記アカウントでログインしたときに前記サーバが生成したセッションＩＤとを記憶する記憶部を参照し、前記第２認証情報を前記第１認証情報と照合し、
前記第２認証情報と前記第１認証情報とが一致した場合、前記処理要求に応じた処理に使用するデータの取得要求に前記セッションＩＤを含め、前記取得要求を前記サーバに送信する、
ユーザ認証方法。
【請求項７】
コンピュータに、
ユーザが利用する利用装置から第２認証情報が含まれた処理要求を受信すると、サーバに前記ユーザが有するアカウントの第１認証情報と、前記ユーザが前記アカウントでログインしたときに前記サーバが生成したセッションＩＤとを記憶する記憶部を参照し、前記第２認証情報を前記第１認証情報と照合し、
前記第２認証情報と前記第１認証情報とが一致した場合、前記処理要求に応じた処理に使用するデータの取得要求に前記セッションＩＤを含め、前記取得要求を前記サーバに送信する、
処理を実行させるユーザ認証プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理システム、ユーザ認証方法、およびユーザ認証プログラムに関する。
【背景技術】
【０００２】
サーバを用いてデータや機能を提供するサービスを行う場合、サーバの管理者は、提供するサービスを呼び出すためのＡＰＩ（Application Programming Interface）を用意する。ＡＰＩは、アプリケーションソフトウェアを実行するコンピュータから、サーバに用意されたサービスを利用するための手順やデータ形式を定めたものである。ＡＰＩは、データの提供者あるいは機能の開発者によって作成され、サービスを利用するユーザに公開される。例えば、ＨＴＴＰ（HyperText Transfer Protocol）でアクセス可能なＷｅｂＡＰＩの形でＡＰＩが公開される。
【０００３】
ＷｅｂＡＰＩを用いると、ＡＰＩサーバを介在させることで、Ｗｅｂサーバで提供される既存のＷｅｂサービスの利便性を高めることができる。ＡＰＩサーバは、ユーザが使用するコンピュータからのＷｅｂＡＰＩに従った処理要求に応じて、Ｗｅｂサーバから提供されるデータを変換し、変換後のデータをユーザが使用するコンピュータに送信する。
【０００４】
ユーザが使用するコンピュータでは、例えばＷｅｂＡＰＩを利用したアプリケーションソフトウェア（以下、ＡＰＩ利用アプリと呼ぶ）を実行し、ＡＰＩ利用アプリに基づく処理の過程で、ＷｅｂＡＰＩを用いてＡＰＩサーバに処理要求を送信する。これにより、例えばＷｅｂサーバで提供されるデータを所定のデータ形式で取得し、そのデータを利用した様々な処理を、ユーザが利用するコンピュータで実行することができる。
【０００５】
Ｗｅｂサーバのサービスを利用する場合、Ｗｅｂサーバにおいてユーザ認証が行われることがある。Ｗｅｂサーバで主に利用されているユーザ認証方式として、ＦＯＲＭ認証がある。ＦＯＲＭ認証では、Ｗｅｂサーバは、ＨＴＭＬ（HyperText Markup Language）のＦＯＲＭを利用した独自のログイン画面を介してユーザの認証情報を取得し、ユーザ認証を行う。ユーザ認証に成功し、ログインが完了すると、Ｗｅｂサーバはユーザが使用するコンピュータにセッションＩＤを送信し、そのセッションＩＤにより、ログイン済みのユーザからのリクエストを識別する。
【０００６】
ユーザがＡＰＩサーバを介してＷｅｂサービスを利用する場合、ユーザは、ＡＰＩサーバ経由でＷｅｂサーバにアクセスし、Ｗｅｂサーバによるユーザ認証を受けることになる。このように別のサーバを介したユーザ認証技術としては、シングルサインオンなど、さまざまな技術がある。例えばバックエンドサーバを改変することなくシングルサインオン環境を実現するコンピュータシステムがある。認証機構を別途設けなくともウェブサイトとのセッションを他のコンピュータに委譲できるようにするセッション権限管理方法も考えられている。認証が必要なＷｅｂサーバに対して認証の取得を容易にする認証システムも考えられている。複数のコンピュータリソースを利用するためのシングルサインオンの処理を第三者に委託しつつも、企業内で利用するログインＩＤを第三者に提供せずに認証を行う認証システムもある。さらに、追加するクラウドサービスを利用するアプリケーションごとにユーザは認可操作を行うことにより、操作が煩雑になってしまうことを解消するためのデバイス装置も考えられている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００５−３２１９７０号公報
【特許文献２】特開２００８−２２６０１５号公報
【特許文献３】特開２０１０−２３８０６０号公報
【特許文献４】特開２０１２−２０３７８１号公報
【特許文献５】特開２０１４−６７３７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ＦＯＲＭ認証を行うサーバで提供されるサービスを利用するには、ユーザが使用するコンピュータは、サーバ独自のＦＯＲＭ認証用のログイン画面でログインし、サーバが発行したセッションＩＤをサーバと協働して管理することとなる。そのため、ユーザが使用するコンピュータにおいて、ＡＰＩ利用アプリのようなソフトウェアの実行途中でＦＯＲＭ認証を行うサーバのサービスを利用するには、そのソフトウェアがサーバのＦＯＲＭ認証の仕様に合わせて作られていることが前提となる。その結果、ＦＯＲＭ認証を行うサーバで提供されるサービスの利用に使用できるソフトウェアが制限され、サービスの利便性がよくない。
【０００９】
１つの側面では、本件は、サーバで提供されるサービスの利便性を向上させることを目的とする。
【課題を解決するための手段】
【００１０】
１つの案では、以下に示すような記憶部と処理部とを有する情報処理装置が提供される。
記憶部は、サーバにユーザが有するアカウントの第１認証情報と、ユーザがアカウントでログインしたときにサーバが生成したセッションＩＤとを記憶する。処理部は、ユーザが利用する利用装置から第２認証情報が含まれた処理要求を受信すると、第２認証情報を第１認証情報と照合し、第２認証情報と第１認証情報とが一致した場合、処理要求に応じた処理に使用するデータの取得要求にセッションＩＤを含め、取得要求をサーバに送信する。
【発明の効果】
【００１１】
１態様によれば、サーバで提供されるサービスの利便性を向上させることができる。
【図面の簡単な説明】
【００１２】
【図１】第１の実施の形態に係るシステムの構成例を示す図である。
【図２】第２の実施の形態のシステム構成例を示す図である。
【図３】本実施の形態に用いるコンピュータのハードウェアの一構成例を示す図である。
【図４】各装置の機能を示すブロック図である。
【図５】ＡＰＩ管理テーブルの一例を示す図である。
【図６】認証情報管理テーブルの一例を示す図である。
【図７】Cookie管理テーブルの一例を示す図である。
【図８】ＡＰＩサーバが実行する認証処理の概要を示す図である。
【図９】ログイン画面要求送信処理の手順を示すフローチャートである。
【図１０】認証情報・Cookie追加処理の手順を示すフローチャートである。
【図１１】ユーザ認証・Cookie取得処理の手順の一例を示すフローチャートである。
【図１２】期限切れのCookieの監視・更新処理の手順の一例を示すフローチャートである。
【図１３】ユーザへのサービス提供手順を示すシーケンス図である。
【図１４】ユーザ登録リクエストの一例を示す図である。
【図１５】ログイン画面リクエストの一例を示す図である。
【図１６】Ｗｅｂサーバが送信するログイン画面データの一例を示す図である。
【図１７】ＡＰＩサーバが送信するログイン画面データの一例を示す図である。
【図１８】ＡＰＩ利用装置が送信するＦＯＲＭ認証リクエストの一例を示す図である。
【図１９】ＡＰＩサーバが送信するＦＯＲＭ認証リクエストの一例を示す図である。
【図２０】ログイン後の画面データの一例を示す図である。
【図２１】登録完了メッセージの一例を示す図である。
【図２２】Basic認証によるリソースリクエストの一例を示す図である。
【図２３】画面リクエストの一例を示す図である。
【図２４】画面データの一例を示す図である。
【図２５】リソースデータの一例を示す図である。
【発明を実施するための形態】
【００１３】
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
まず第１の実施の形態について説明する。
【００１４】
図１は、第１の実施の形態に係るシステムの構成例を示す図である。利用装置１とサーバ２との間に、情報処理装置１０が設けられている。利用装置１は、サーバ２で提供されるサービスを利用するユーザが使用するコンピュータである。サーバ２は、サービスを提供するコンピュータである。情報処理装置１０は、サーバ２で提供されるデータに所定の処理を実行し、その実行結果を利用装置１に送信するコンピュータである。例えば情報処理装置１０は、ＡＰＩサーバである。
【００１５】
情報処理装置１０は、記憶部１１と処理部１２とを有する。記憶部１１は、例えば情報処理装置１０が有するメモリまたはストレージ装置である。処理部１２は、例えば情報処理装置１０が有するプロセッサである。
【００１６】
記憶部１１は、サーバ２にユーザが有するアカウントの認証情報３と、ユーザがそのアカウントでログインしたときにサーバ２が生成したセッションＩＤ４とを記憶する。
処理部１２は、認証情報３が含まれたログイン要求を利用装置１から受信すると、サーバ２内の所定の資源宛てにログイン要求を送信する。所定の資源は、例えばサーバ２においてＦＯＲＭ認証を行う機能に対応する資源（プログラムモジュールなど）である。ログイン要求に応じてサーバ２がユーザ認証を行い、正しくログインできると、サーバ２から情報処理装置１０にセッションＩＤが送信される。処理部１２は、サーバ２からセッションＩＤ４を受信すると、認証情報３とセッションＩＤ４とを記憶部１１に格納する。
【００１７】
その後、処理部１２は、利用装置１から認証情報が含まれた処理要求５を受信すると、記憶部１１を参照し、処理要求５に含まれる認証情報と、記憶部１１に記憶されている認証情報３とを照合する。この照合処理は、例えばBasic認証処理である。照合により２つの認証情報が一致した場合、処理部１２は、処理要求５に応じた処理に使用するデータ７の取得要求６にセッションＩＤを含め、取得要求６をサーバ２に送信する。取得要求６に対してサーバ２からデータ７が応答される。処理部１２は、取得要求６に対してサーバ２から応答されたデータ７を用いて処理要求５に従った処理を実行する。そして処理部１２は、処理の実行結果８を利用装置１に送信する。
【００１８】
このようなシステムによれば、ユーザが、利用装置１を用いて、情報処理装置１０を介してサーバ２にログインすると、情報処理装置１０において、認証情報３とセッションＩＤ４とが記憶される。その後、例えば利用装置１においてソフトウェアを実行している途中でサーバ２内のデータを利用した処理になり、利用装置１が認証情報を含む処理要求５を送信すると、情報処理装置１０で例えばBasic認証が行われる。認証に成功すると、情報処理装置１０からサーバ２へ、セッションＩＤ４を含む取得要求６が送信され、サーバ２からデータ７が応答される。情報処理装置１０では、データ７を利用して処理要求５に応じた処理が実行され、実行結果８が利用装置１に送信される。利用装置１では、実行結果８を用いて、ソフトウェアの処理を続行する。
【００１９】
このように、第１の実施の形態によれば、利用装置１では、ソフトウェアの実行中にサーバ２で提供されるデータを用いた処理を行う場合、情報処理装置１０に認証情報を含む処理要求５を送信すればよい。すなわちユーザは、最初に１度だけサーバ２へのログイン手続きを行っておけば、その後は、サーバ２へのログインの手続きを繰り返さずに済む。その結果、利用装置１で実行するソフトウェアに、サーバ２におけるログインの認証方式に依存したプログラムモジュールを組み込まずに済み、ソフトウェアの開発が容易となる。その結果、サーバ２で提供されるサービスの利便性が向上する。
【００２０】
しかも第１の実施の形態では、サーバ２が生成したセッションＩＤを、情報処理装置１０で管理しているため、利用装置１では、セッションＩＤを管理せずに済む。そのため、利用装置１におけるソフトウェアの開発がさらに容易となる。
【００２１】
なお、セッションＩＤ４には、有効期限を設定することができる。有効期限は、例えばセッションＩＤ内に示されている。セッションＩＤ４に有効期限が設定されている場合、処理部１２は、セッションＩＤ４に示されている有効期限情報に基づいて、セッションＩＤ４の有効期限が切れているか否かを判断する。有効期限が切れている場合、処理部１２は、記憶部１１から認証情報３を取得し、認証情報３を含むログイン要求をサーバ２に送信する。このログイン要求に応じて、サーバ２でログイン処理が行われる。正しくログインできると、サーバ２から情報処理装置１０に、新規のセッションＩＤを含むログイン完了応答が送信される。処理部１２はログイン完了応答を受信すると、記憶部１１内のセッションＩＤ４を、ログイン完了応答に含まれるセッションＩＤに更新する。
【００２２】
このように、有効期限が切れたセッションＩＤを自動更新することで、セッションＩＤ４に有効期限があっても、利用装置１からのサーバ２へのログイン処理を、最初の１回のみで済ませることができる。その結果、利用装置１においてサーバ２で提供されるサービスを利用する際の利便性が向上する。
【００２３】
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、Ｗｅｂサーバで提供されるサービスを、ＷｅｂＡＰＩを介して利用するものである。この場合、ユーザが使用するコンピュータは、ＡＰＩ利用アプリを実行することで、Ｗｅｂサーバで提供されるサービスを利用する。
【００２４】
多くの場合、Ｗｅｂサーバでは、ＦＯＲＭ認証が行われる。ＷｅｂサーバのサービスをＷｅｂブラウザ経由で利用するユーザに対しては、Ｗｅｂサーバ独自のログイン画面でユーザ認証を行わせることで、提供するサービスに合ったログイン画面をユーザに提示し、サービスの独自性を出すことができる。そのため、Ｗｅｂサーバで実行されているＷｅｂアプリには変更を加えたくない場合がある。
【００２５】
それに対して、ＦＯＲＭ認証を採用しているＷｅｂサーバのサービスを、ＡＰＩサーバを介して利用する場合、ＡＰＩの認証方式がログイン画面に強く依存してしまい、使い勝手が悪い。例えばＷｅｂサーバが独自仕様のＦＯＲＭ認証を行っていると、ユーザが使用するコンピュータで実行させるＡＰＩ利用アプリに、Ｗｅｂサーバ独自仕様のＦＯＲＭ認証に合わせた処理のプログラムモジュールを組み込むこととなる。その結果、ＡＰＩ利用アプリの開発負担が増えてしまう。またＦＯＲＭ認証では、ログインしたユーザか否かをセッションＩＤで管理するため、ＡＰＩ利用アプリにセッションＩＤを管理するプログラムモジュールを組み込むことにもなることも、ＡＰＩ利用アプリの開発負担の上昇要因である。
【００２６】
そこで、第２の実施の形態では、ＡＰＩ利用アプリが、Basic認証やDigest認証などの標準的な認証方式に適合していれば、ＦＯＲＭ認証を行うＷｅｂサーバのサービスをＡＰＩサーバ経由で容易に利用できるようにしている。
【００２７】
図２は、第２の実施の形態のシステム構成例を示す図である。ＡＰＩ利用装置２１０は、ネットワーク３１を介して、サービス提供用のシステムに接続されている。サービス提供用のシステムでは、ＦＷ（Firewall）３２を介して、ＤＭＺ内ネットワーク３３がネットワーク３１に接続されている。またＦＷ３４を介して、内部ネットワーク３５がＤＭＺ内ネットワーク３３に接続されている。ＤＭＺ内ネットワーク３３には、ＡＰＩサーバ１００とＷｅｂサーバ２２０とが接続されている。内部ネットワーク３５には、ＡＰＩサーバ用ＤＢ（DataBase）２３０、アプリサーバ２４０、およびＤＢ２５０が接続されている。
【００２８】
Ｗｅｂサーバ２２０、アプリサーバ２４０、およびＤＢ２５０は、例えばＷｅｂ３階層システムを構成している。Ｗｅｂサーバ２２０は、アプリサーバ２４０やＤＢ２５０と連携して、データや機能などのサービスをＡＰＩ利用装置２１０に提供する。Ｗｅｂサーバ２２０は、例えばＷｅｂサービス提供用のアプリケーションソフトウェア（以下、Ｗｅｂアプリと呼ぶ）を実行することで、サービス提供機能を実現する。
【００２９】
なお、Ｗｅｂサーバ２２０は、サービスの利用を許容しているユーザのアカウントを管理している。各ユーザのアカウントには、該当ユーザの認証情報が含まれている。Ｗｅｂサーバ２２０は、ユーザの認証情報を用いてＦＯＲＭ認証を行い、認証に成功したユーザのログインを認める。そしてＷｅｂサーバ２２０は、ログインしたユーザが使用する装置からのリクエストに応じてサービスを提供する。
【００３０】
ＡＰＩ利用装置２１０は、ＷｅｂＡＰＩを利用したアプリ（ＡＰＩ利用アプリ）を実行する。ＡＰＩ利用アプリを実行することで、ＡＰＩ利用装置２１０は、ＡＰＩサーバ１００を介して、Ｗｅｂサーバ２００によるサービスの提供を受けることができる。
【００３１】
ＡＰＩサーバ１００は、ＷｅｂＡＰＩによる処理を提供するコンピュータである。例えばＡＰＩサーバは、ＡＰＩ利用装置２１０からのＷｅｂＡＰＩの処理要求に応じて、Ｗｅｂサーバ２２０に処理を実行させる。そしてＡＰＩサーバ１００は、Ｗｅｂサーバ２２０から処理結果を受け取ると、ＷｅｂＡＰＩで定義された処理を施し、処理後のデータをＡＰＩ利用装置２１０に送信する。例えばＡＰＩサーバ１００は、ＨＴＴＰのＧＥＴメソッドで、Ｗｅｂサーバ２２０から、ＷｅｂアプリのＨＴＭＬ画面データを取得する。ＡＰＩサーバ１００は、取得したＨＴＭＬ画面データをパーズし、所望のデータを取得する。そしてＡＰＩサーバ１００は、取得したデータをＷｅｂＡＰＩで定義されたデータ形式に加工して、ＡＰＩ利用装置２１０に送信する。
【００３２】
なお、Ｗｅｂサーバ２２０は、ＦＯＲＭ認証により正規のユーザであることが確認できたユーザが使用する装置に対してのみ、サービスを提供する。そこでＡＰＩサーバ１００は、ＡＰＩ利用装置２１０とＷｅｂサーバ２２０との間のＦＯＲＭ認証の処理を中継し、その際、ＡＰＩ利用装置２１０から送信された認証情報を保持する。その後、ＡＰＩサーバ１００は、保持した認証情報を用いて、ＦＯＲＭ認証以外の認証方式で、ＡＰＩ利用装置２１０を使用しているユーザを認証する。
【００３３】
例えば、ＡＰＩサーバ１００は、利用するサービスの処理要求内に認証情報を含ませることで、ユーザ認証と処理要求とを同時に行うことが可能な認証方式を用いて、ユーザ認証を行う。このような認証方式として、Basic認証やDigest認証などがある。処理要求に認証情報を含ませることができれば、Ｗｅｂサーバ２２０におけるログイン用のＦＯＲＭに合わせた処理をＡＰＩ利用装置において行わずに済み、ＡＰＩ利用装置２１０における処理負担が軽く済む。またＡＰＩ利用装置２１０において、Basic認証やDigest認証によってユーザ認証を受けることができれば、Ｗｅｂサーバ２２０側のアプリ独自のＨＴＭＬのＦＯＲＭをＡＰＩ利用装置２１０内で作成するような処理が不要となる。その結果、ＡＰＩ利用装置２１０に実行させるアプリの作成が容易となる。以下の説明では、ＡＰＩサーバ１００は、Basic認証によってユーザ認証を行うものとする。
【００３４】
図３は、本実施の形態に用いるコンピュータのハードウェアの一構成例を示す図である。ＡＰＩサーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。
【００３５】
メモリ１０２は、ＡＰＩサーバ１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。
【００３６】
バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。
【００３７】
ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。
【００３８】
グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。
【００３９】
入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
【００４０】
光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。
【００４１】
機器接続インタフェース１０７は、ＡＰＩサーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。
【００４２】
ネットワークインタフェース１０８は、ＤＭＺ内ネットワーク３３に接続されている。ネットワークインタフェース１０８は、ＤＭＺ内ネットワーク３３を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。
【００４３】
以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。なお、第１の実施の形態に示した情報処理装置１０も、図３に示したＡＰＩサーバ１００と同様のハードウェアにより実現することができる。
【００４４】
ＡＰＩサーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。ＡＰＩサーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、ＡＰＩサーバ１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またＡＰＩサーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
【００４５】
図４は、各装置の機能を示すブロック図である。ＡＰＩ利用装置２１０は、ＡＰＩ利用アプリ２１１を有している。Ｗｅｂサーバ２２０は、複数のＷｅｂアプリ２２１，２２２，・・・を有している。
【００４６】
ＡＰＩサーバ１００は、ＦＯＲＭ認証仲介部１１０、ＡＰＩ処理部１２０、および期限管理部１３０を有する。ＦＯＲＭ認証仲介部１１０は、ＡＰＩ利用装置２１０を使用するユーザがＷｅｂサーバ２２０にログインする際のＦＯＲＭ認証処理を仲介する。
【００４７】
ＡＰＩ処理部１２０は、ＡＰＩ利用装置２１０から、Ｗｅｂアプリで提供されるサービス利用した処理の処理要求を受信すると、ＡＰＩ利用装置２１０を使用するユーザの認証を、ＦＯＲＭ認証とは異なる認証方式で認証する。例えばＡＰＩ処理部１２０は、Basic認証またはDigest認証を用いて、ユーザ認証を行う。正当なユーザであることが認証できた場合、ＡＰＩ処理部１２０は、Ｗｅｂサーバ２２０にアクセスし、処理要求で指定されたＷｅｂアプリによるサービスを実行させる。そしてＡＰＩ処理部１２０は、Ｗｅｂサーバ２２０から実行結果を受信し、実行結果に所定の加工を施して、ＡＰＩ利用装置２１０に送信する。
【００４８】
なお期限管理部１３０は、ＡＰＩ利用装置２１０のユーザがＷｅｂサーバ２２０にログインしたときに生成されるCookieの有効期限を管理する。
ＡＰＩサーバ用ＤＢ２３０は、ＡＰＩサーバ１００が使用する情報を管理する。例えばＡＰＩサーバ用ＤＢ２３０には、ＡＰＩ管理テーブル２３１、認証情報管理テーブル２３２、およびCookie管理テーブル２３３が格納される。ＡＰＩ管理テーブル２３１は、Ｗｅｂアプリごとに設けられたＡＰＩを管理するデータテーブルである。認証情報管理テーブル２３２は、ユーザの認証情報を管理するデータテーブルである。Cookie管理テーブル２３３は、Ｗｅｂサーバ２２０にログインしたときに発行されるCookieを管理するデータテーブルである。
【００４９】
なお、図４に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図４に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。
【００５０】
以下、図５〜図７を参照して、各データテーブルの内容について具体的に説明する。
図５は、ＡＰＩ管理テーブルの一例を示す図である。ＡＰＩ管理テーブル２３１には、ＡＰＩ、ログイン画面ＵＲＩ（Uniform Resource Identifier）、ＦＯＲＭ認証ＵＲＩ、ベースパス、およびリソースの欄が設けられている。
【００５１】
ＡＰＩの欄には、Ｗｅｂアプリを利用したサービスを提供するＡＰＩの名称が設定される。例えば、利用するＷｅｂアプリの名称が、そのＷｅｂアプリを利用したサービスを提供するＡＰＩの名称として利用される。
【００５２】
ログイン画面ＵＲＩの欄には、対応するＷｅｂアプリのログイン画面データが格納されている場所を示すＵＲＩが設定される。ＦＯＲＭ認証仲介部１１０は、ＡＰＩ利用装置２１０からユーザ登録リクエストを受信すると、ログイン画面ＵＲＩの欄に設定されているＵＲＩを参照して、Ｗｅｂサーバ２２０に対してログイン画面リクエストを送信する。例えばユーザ登録リクエストには、「[アプリ名]/[バージョン]/login-forms」という情報が含まれる。ＦＯＲＭ認証仲介部１１０は、ユーザ登録リクエストに含まれる「アプリ名」に対応するＡＰＩ管理テーブル２３１内のレコードを参照し、該当するレコードのログイン画面ＵＲＩを取得する。そしてＦＯＲＭ認証仲介部１１０は、取得したログイン画面ＵＲＩを指定したログイン画面リクエストを、Ｗｅｂサーバ２２０に送信する。
【００５３】
ＦＯＲＭ認証ＵＲＩの欄には、対応するＷｅｂアプリにおけるＦＯＲＭ認証を実行するための資源（例えばプログラム）を示すＵＲＩが設定される。ＦＯＲＭ認証仲介部１１０は、ＡＰＩ利用装置２１０からＦＯＲＭ認証リクエストを受信すると、ＦＯＲＭ認証ＵＲＩに示される資源に対して、そのＦＯＲＭ認証リクエストを転送する。例えばＡＰＩ利用装置２１０から送られるＦＯＲＭ認証リクエストには、「[アプリ名]/[バージョン]/login」という情報が含まれる。ＦＯＲＭ認証仲介部１１０は、受信したＦＯＲＭ認証リクエストに含まれる「アプリ名」に対応するＡＰＩ管理テーブル２３１内のレコードを参照し、該当するレコードのＦＯＲＭ認証ＵＲＩを取得する。そしてＦＯＲＭ認証仲介部１１０は、取得したＦＯＲＭ認証ＵＲＩを指定したＦＯＲＭ認証リクエストを、Ｗｅｂサーバ２２０に送信する。
【００５４】
ベースパスの欄には、対応するＷｅｂアプリの、Ｗｅｂサーバ２２０内での位置を示す情報が設定される。リソースの欄には、ＡＰＩで提供される資源の識別情報が設定される。リソースの欄に設定されている識別情報を、ベースパスの後に連結した情報により、資源を一意に特定することができる。例えば、「/app1/v1/customers」と指定することで、Ｗｅｂアプリ「app1」のサービスを利用するＡＰＩ「/customers」にアクセスできる。
【００５５】
図６は、認証情報管理テーブルの一例を示す図である。認証情報管理テーブル２３２には、ＡＰＩ、ユーザ、およびパスワードの欄が設けられている。Ｗｅｂアプリを利用したサービスを提供するＡＰＩの名称が設定される。ユーザの欄には、対応するＷｅｂアプリに対してログインしたユーザのユーザ名が設定される。パスワードの欄には、ユーザがログインしたときに使用したパスワードが設定される。パスワードは、Ｗｅｂアプリの仕様に従って、ハッシュ化または暗号化して認証情報管理テーブル２３２に格納される。
【００５６】
図７は、Cookie管理テーブルの一例を示す図である。Cookie管理テーブル２３３には、ＡＰＩ、ユーザ、およびCookieの欄が設けられている。ＡＰＩの欄には、Ｗｅｂアプリを利用したサービスを提供するＡＰＩの名称が設定される。ユーザの欄には、対応するＷｅｂアプリに対してＦＯＲＭ認証によりログインしたユーザのユーザ名が設定される。Cookieの欄には、ユーザがログインしたときにＷｅｂサーバ２２０で発行されたCookieが格納される。Cookieには、セッションＩＤや、セッションの有効期限を示す情報が含まれている。例えばCookie内のexpires, max-ageなどの項目によって、有効期限が指定される。
【００５７】
次に、ＡＰＩサーバによる認証処理について詳細に説明する。
図８は、ＡＰＩサーバが実行する認証処理の概要を示す図である。ＡＰＩ利用装置２１０から、特定のＷｅｂアプリへのユーザ登録リクエストを受信すると、ＡＰＩサーバ１００は、ＡＰＩ管理テーブル２３１を参照し、指定されたＷｅｂアプリのログイン画面ＵＲＩを取得する。そしてＡＰＩサーバ１００は、取得したログイン画面ＵＲＩを指定して、ログイン画面リクエストをＷｅｂサーバ２２０に送信する。
【００５８】
ログイン画面リクエストに応じて、Ｗｅｂサーバ２２０からＡＰＩサーバ１００に、ログイン画面データが送信される。ＡＰＩサーバ１００は、Ｗｅｂサーバ２２０から送られたログイン画面データをＡＰＩ利用装置２１０に送信する。すると、ＡＰＩ利用装置２１０のモニタにログイン画面が表示される。ＡＰＩ利用装置２１０を使用しているユーザは、ログイン画面の所定の領域に、ユーザ名とパスワードとを入力する。するとＡＰＩ利用装置２１０は、ユーザ名とパスワードとの組からなる認証情報を含むＦＯＲＭ認証リクエストを、ＡＰＩサーバ１００に送信する。
【００５９】
ＡＰＩサーバ１００は、ＦＯＲＭ認証リクエストを受信すると、ＡＰＩ管理テーブル２３１を参照し、認証対象のＷｅｂアプリのＦＯＲＭ認証ＵＲＩを取得する。ＡＰＩサーバ１００は、取得したＦＯＲＭ認証ＵＲＩを指定して、Ｗｅｂサーバ２２０にＦＯＲＭ認証リクエストを送信する。Ｗｅｂサーバ２２０では、ＦＯＲＭ認証リクエストに含まれる認証情報を用いたユーザ認証が行われる。例えば、予め登録されている正規ユーザの認証情報のいずれかと、ＦＯＲＭ認証リクエストに含まれる認証情報とが一致するか否かが判断される。正規ユーザの認証情報のいずれかと一致した場合、Ｗｅｂサーバ２２０は、ＡＰＩ利用装置２１０を使用しているユーザのログインを許可し、ログイン後の画面データをＡＰＩサーバ１００に送信する。ログイン後の画面データには、Cookieが含まれる。
【００６０】
ログイン後の画面データを受信したＡＰＩサーバ１００は、ＦＯＲＭ認証リクエストに含まれていた認証情報を、認証情報管理テーブル２３２に格納する。またＡＰＩサーバ１００は、ログイン後の画面データに含まれているCookieを、Cookie管理テーブル２３３に格納する。その後、ＡＰＩサーバ１００は、登録完了メッセージを、ＡＰＩ利用装置２１０に送信する。
【００６１】
ＡＰＩ利用装置２１０においてＡＰＩ利用アプリが実行され、Ｗｅｂサーバ２２０が提供するサービスを利用する処理が開始されると、ＡＰＩ利用装置２１０からＡＰＩサーバ１００へ、Basic認証によるリソースリクエストが送信される。このリソースリクエストには、ＦＯＲＭ認証で使用した認証情報が含まれる。ＡＰＩサーバ１００は、リソースリクエストを受信すると、認証情報管理テーブル２３２を参照し、Basic認証によるユーザ認証を行う。例えばＡＰＩサーバ１００は、リソースリクエストに含まれる認証情報のユーザ名とパスワードとのペアが、認証情報管理テーブル２３２に登録されているいずれかのレコードのユーザ名とパスワードとのペアと一致するか否かを判断する。一致するレコードがある場合、ＡＰＩサーバ１００は、そのレコードのユーザ名に対応する正規のユーザからのリソースリクエストであると認証し、Cookie管理テーブル２３３から、該当ユーザのCookieを取得する。そしてＡＰＩサーバ１００は、リソースリクエストをCookie付きの画面リクエストに変換し、その画面リクエストをＷｅｂサーバ２２０に送信する。
【００６２】
画面リクエストを受信したＷｅｂサーバ２２０は、画面リクエストに応じたＨＴＭＬ画面データをＡＰＩサーバ１００に送信する。ＡＰＩサーバ１００は、取得したＨＴＭＬ画面データを、所定の形式のデータに変換し、変換されたデータをＡＰＩ利用装置２１０に送信する。ＡＰＩ利用装置２１０では、ＡＰＩサーバ１００から送られたデータを用いて、ＡＰＩ利用アプリの実行を継続する。
【００６３】
なおＡＰＩサーバ１００は、Cookie管理テーブル２３３を参照し、有効期限が切れたCookieの有無を監視する。ＡＰＩサーバ１００は、有効期限が切れたCookieを検出すると、認証情報管理テーブル２３２を参照し、そのCookieに対応するユーザの認証情報を取得する。ＡＰＩサーバ１００は、取得した認証情報を含むＦＯＲＭ認証リクエストを、Ｗｅｂサーバ２２０に送信する。ログインに成功すると、有効期限が更新された新たなCookieが、Ｗｅｂサーバ２２０からＡＰＩサーバ１００に送信される。ＡＰＩサーバ１００は、新たに取得したCookieで、Cookie管理テーブル２３３内のCookieを更新する。これにより、Cookie管理テーブル２３３内のCookieが、有効期限が切れていないCookieに随時更新される。
【００６４】
次に、図８に示したような処理を実現するためのＡＰＩサーバ１００で実行する処理を、図９〜図１２を参照して詳細に説明する。
ＡＰＩ利用装置２１０がＡＰＩ利用アプリ２１１の実行を開始すると、まずＡＰＩ利用装置２１０が、ＡＰＩサーバ１００へユーザ登録リクエストを送信する。すると、ＡＰＩサーバ１００において、ログイン画面要求送信処理が開始される。
【００６５】
図９は、ログイン画面要求送信処理の手順を示すフローチャートである。以下、図９に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］ＦＯＲＭ認証仲介部１１０は、ＡＰＩ利用装置２１０から、そのＡＰＩ利用装置２１０を使用するユーザのユーザ登録リクエストを受信する。ユーザ登録リクエストには、ユーザ名と、Ｗｅｂアプリを利用したサービスを提供するＡＰＩの名称とが含まれる。
【００６６】
［ステップＳ１０２］ＦＯＲＭ認証仲介部１１０は、認証情報管理テーブル２３２に、ＡＰＩの名称とユーザ名との組を含むレコードを追加する。
［ステップＳ１０３］ＦＯＲＭ認証仲介部１１０は、指定されたＡＰＩに対応するＷｅｂアプリのログイン画面を、Ｗｅｂサーバ２２０から取得する。例えばＦＯＲＭ認証仲介部１１０は、ユーザ登録リクエストで指定されたＡＰＩに対応するＡＰＩ管理テーブル２３１内のレコードから、ログイン画面ＵＲＩを取得する。そしてＦＯＲＭ認証仲介部１１０は、取得したログイン画面ＵＲＩを指定したログイン画面リクエストをＷｅｂサーバ２２０に送信する。ＦＯＲＭ認証仲介部１１０は、ログイン画面リクエストに応じてＷｅｂサーバ２２０から送信されたログイン画面データを取得する。
【００６７】
［ステップＳ１０４］ＦＯＲＭ認証仲介部１１０は、取得したログイン画面データを、ユーザ登録リクエストに対応する応答として、ＡＰＩ利用装置２１０に送信する。
ログイン画面データを受信したＡＰＩ利用装置２１０では、ログイン画面が表示される。そしてＡＰＩ利用装置２１０を使用するユーザが、ログイン画面内の所定の領域にユーザ名とパスワードとを入力すると、ＡＰＩ利用装置２１０からＡＰＩサーバ１００へ、ＦＯＲＭ認証リクエストが送信される。ＦＯＲＭ認証リクエストを受信したＡＰＩサーバ１００では、認証情報・Cookie追加処理が実行される。
【００６８】
図１０は、認証情報・Cookie追加処理の手順を示すフローチャートである。以下、図１０に示す処理をステップ番号に沿って説明する。
［ステップＳ１１１］ＦＯＲＭ認証仲介部１１０は、ＡＰＩ利用装置２１０から、ＷｅｂアプリのＦＯＲＭ認証ＵＲＩへのＦＯＲＭ認証リクエストを受信する。ＦＯＲＭ認証リクエストには、認証情報として、ＡＰＩ利用装置２１０を使用するユーザのユーザ名とパスワードとの組が含まれている。
【００６９】
［ステップＳ１１２］ＦＯＲＭ認証仲介部１１０は、ＡＰＩ管理テーブル２３１から、ＦＯＲＭ認証リクエストに示されるＦＯＲＭ認証ＵＲＩに対応するＡＰＩ名を取得する。
［ステップＳ１１３］ＦＯＲＭ認証仲介部１１０は、ＦＯＲＭ認証リクエストに示されるユーザ名と、ＡＰＩ管理テーブル２３１から取得したＡＰＩ名との組に対応するレコードが、認証情報管理テーブル２３２内にあるか否かを判断する。該当するレコードがあれば、処理がステップＳ１１４に進められる。該当するレコードがなければ、処理がステップＳ１１９に進められる。
【００７０】
［ステップＳ１１４］ＦＯＲＭ認証仲介部１１０は、ＦＯＲＭ認証ＵＲＩ宛てにＦＯＲＭ認証リクエストを送信する。送信されたＦＯＲＭ認証リクエストは、Ｗｅｂサーバ２２０で受信され、ＦＯＲＭ認証ＵＲＩに対応するＷｅｂアプリを用いてユーザ認証が行われる。そしてＷｅｂサーバ２２０からＡＰＩサーバ１００に、認証結果が送信される。するとＦＯＲＭ認証仲介部１１０が認証結果を受信する。認証結果にはCookieが含まれている。そのCookieには、セッションＩＤや有効期限が示されている。
【００７１】
［ステップＳ１１５］ＦＯＲＭ認証仲介部１１０は、認証に成功したか否かを判断する。認証に成功した場合、処理がステップＳ１１６に進められる。認証に失敗した場合、処理がステップＳ１１９に進められる。
【００７２】
［ステップＳ１１６］ＦＯＲＭ認証仲介部１１０は、ＦＯＲＭ認証リクエストに示されるユーザ名と、ＡＰＩ管理テーブル２３１から取得したＡＰＩ名との組に対応する、認証情報管理テーブル２３２内のレコードに、ＦＯＲＭ認証リクエストに含まれる認証情報を追加する。
【００７３】
［ステップＳ１１７］ＦＯＲＭ認証仲介部１１０は、ＦＯＲＭ認証リクエストに示されるユーザ名と、ＡＰＩ管理テーブル２３１から取得したＡＰＩ名との組に対応する、Cookie管理テーブル２３３内のレコードに、認証結果に含まれるCookieを追加する。
【００７４】
［ステップＳ１１８］ＦＯＲＭ認証仲介部１１０は、登録完了メッセージをＡＰＩ利用装置２１０に送信する。その後、認証情報・Cookie追加処理が終了する。
［ステップＳ１１９］ＦＯＲＭ認証仲介部１１０は、エラーメッセージをＡＰＩ利用装置２１０に送信する。その後、認証情報・Cookie追加処理が終了する。
【００７５】
登録完了メッセージを受信したＡＰＩ利用装置２１０では、ＡＰＩ利用アプリ２１１の実行が継続される。そして、ＡＰＩ利用装置２１０において、ＡＰＩサーバ１００で提供されるＷｅｂＡＰＩを用いた処理が開始されると、ＡＰＩ利用装置２１０は、ＡＰＩサーバ１００に、Basic認証によるリソースリクエストを送信する。するとＡＰＩサーバ１００において、ユーザ認証・Cookie取得処理が実行される。
【００７６】
図１１は、ユーザ認証・Cookie取得処理の手順の一例を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。
［ステップＳ１２１］ＡＰＩ処理部１２０は、ＡＰＩ利用装置２１０から、Basic認証によるリソースリクエストを受信する。リソースリクエストには、Basic認証のための認証情報と、呼び出し対象のＡＰＩのリソースを示す情報とが含まれる。
【００７７】
［ステップＳ１２２］ＡＰＩ処理部１２０は、ＡＰＩ管理テーブル２３１を参照し、リソースリクエストが対象とするＡＰＩを特定する。例えばＡＰＩ処理部１２０は、ＡＰＩ管理テーブル２３１から、ベースパスとリソースとの欄で特定されるリソースが、リソースリクエストに示されるリソースと一致するレコードを検索する。そしてＡＰＩ処理部１２０は、検索でヒットしたレコードで示されるリソースを、リソースリクエストが対象とするＡＰＩとして特定する。
【００７８】
［ステップＳ１２３］ＡＰＩ処理部１２０は、特定したＡＰＩのＡＰＩ名と、リソースリクエストに含まれる認証情報に示されるユーザ名との組に対応するレコードが、認証情報管理テーブル２３２にあるか否かを判断する。該当するレコードがあれば、処理がステップＳ１２４に進められる。該当するレコードがなければ、処理がステップＳ１２８に進められる。
【００７９】
［ステップＳ１２４］ＡＰＩ処理部１２０は、認証情報管理テーブル２３２内の認証情報（ユーザ名とパスワード）を用いて、事前に指定された認証方式によりユーザ認証を実施する。例えばＡＰＩ処理部１２０は、特定したＡＰＩのＡＰＩ名と、リソースリクエストに含まれる認証情報に示されるユーザ名との組に対応するレコードを、認証情報管理テーブル２３２から取得する。ＡＰＩ処理部１２０は、取得したレコードのユーザ名とパスワードとの組と、リソースリクエストに含まれるユーザ名とパスワードとの組を照合する。ユーザ名とパスワードとの組が一致していれば、ＡＰＩ処理部１２０は、リソースリクエストを送信したＡＰＩ利用装置２１０のユーザが、正規のユーザであると認証する。
【００８０】
［ステップＳ１２５］ＡＰＩ処理部１２０は、認証に成功したか否かを判定する。認証に成功した場合、処理がステップＳ１２６に進められる。認証に失敗した場合、処理がステップＳ１２８に進められる。
【００８１】
［ステップＳ１２６］ＡＰＩ処理部１２０は、特定したＡＰＩのＡＰＩ名と、リソースリクエストに含まれる認証情報に示されるユーザ名との組に対応するレコードが、Cookie管理テーブル２３３にあるか否かを判断する。該当するレコードがある場合、処理がステップＳ１２７に進められる。該当するレコードがなければ、処理がステップＳ１２８に進められる。
【００８２】
［ステップＳ１２７］ＡＰＩ処理部１２０は、Cookie管理テーブル２３３から、リソースリクエストに含まれる認証情報に示されるユーザ名との組に対応するCookieを取得する。その後、ユーザ認証・Cookie取得処理が終了する。
【００８３】
［ステップＳ１２８］ＡＰＩ処理部１２０は、エラーメッセージをＡＰＩ利用装置２１０に送信する。その後、ユーザ認証・Cookie取得処理が終了する。
このようにして、ユーザ認証に成功したユーザのCookieが取得される。取得したCookieを用いて、ＷｅｂサーバからＨＴＭＬ画面データを取得することができる。
【００８４】
なおCookieには有効期限を設定できる。Cookieの有効期限が切れていると、そのCookieを付与した画面リクエストをＷｅｂサーバ２２０に送信しても、エラーが応答される。そこで、期限管理部１３０が、Cookieの有効期限をチェックし、期限切れのCookieがある場合には、そのCookieに対応するユーザ用の新たなCookieを取得する。
【００８５】
図１２は、期限切れのCookieの監視・更新処理の手順の一例を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。
［ステップＳ１３１］期限管理部１３０は、認証情報管理テーブル２３２よりレコードを１件取得する。例えば期限管理部１３０は、認証情報管理テーブル２３２に登録されているレコードを上から順に取得する。
【００８６】
［ステップＳ１３２］期限管理部１３０は、取得したレコード内のCookieの有効期限を確認する。
［ステップＳ１３３］期限管理部１３０は、取得したレコード内のCookieの有効期限が切れているか否かを判断する。例えば期限管理部１３０は、Cookieに有効期限として示されている日時が、現在の日時より前であれば、有効期限が切れていると判断する。有効期限が切れている場合、処理がステップＳ１３４に進められる。有効期限が切れていなければ、処理がステップＳ１３１に進められる。
【００８７】
［ステップＳ１３４］期限管理部１３０は、取得したレコードから認証情報（ユーザ名とパスワード）を抽出する。
［ステップＳ１３５］期限管理部１３０は、有効期限が切れたCookieに対応するＷｅｂアプリのログイン画面データを、Ｗｅｂサーバ２２０から取得する。例えば期限管理部１３０は、取得したレコードに示されるＡＰＩのログイン画面ＵＲＩを、ＡＰＩ管理テーブル２３１から取得する。次に期限管理部１３０は、取得したログイン画面ＵＲＩ宛てに、ログイン画面リクエストを送信する。するとＷｅｂサーバ２２０からログイン画面データが応答される。
【００８８】
［ステップＳ１３６］期限管理部１３０は、ステップＳ１３４で抽出した認証情報を用いて、有効期限が切れたCookieに対応するＷｅｂアプリへのログイン処理を行う。例えば期限管理部１３０は、取得したレコードに示されるＡＰＩのＦＯＲＭ認証ＵＲＩを、ＡＰＩ管理テーブル２３１から取得する。次に期限管理部１３０は、取得したＦＯＲＭ認証ＵＲＩ宛てに、ステップＳ１３４で抽出した認証情報を含むＦＯＲＭ認証リクエストを送信する。するとＷｅｂサーバ２２０において、指定されたＵＲＩに対応するＷｅｂアプリにおけるユーザ認証処理が行われる。そしてＷｅｂサーバ２２０からＡＰＩサーバ１００に、ユーザ認証の結果を示す認証結果レスポンスが送信される。
【００８９】
［ステップＳ１３７］期限管理部１３０は、認証に成功したか否かを判断する。例えば期限管理部１３０は、認証結果レスポンスとして、新たなCookieを含むログイン後の画面データを受信した場合、認証に成功したと判断する。認証に成功した場合、処理がステップＳ１３９に進められる。認証に失敗した場合、処理がステップＳ１３８に進められる。
【００９０】
［ステップＳ１３８］期限管理部１３０は、認証に失敗したＡＰＩ名とユーザ名との組対応するレコードを、認証情報管理テーブル２３２とCookie管理テーブル２３３とのそれぞれから削除する。その後、処理がステップＳ１３１に進められる。
【００９１】
［ステップＳ１３９］期限管理部１３０は、Cookie管理テーブル２３３内の認証に失敗したＡＰＩ名とユーザ名との組対応するレコードに、認証結果レスポンスに含まれるCookieを追加する。その後、処理がステップＳ１３１に進められる。
【００９２】
このようにして、Cookieの期限が切れるごとに、対応するＷｅｂアプリに対して自動ログイン処理が行われ、Cookieが随時更新される。
次に、図１３〜図２５を参照し、装置間で送受信されるデータの具体例について説明する。
【００９３】
図１３は、ユーザへのサービス提供手順を示すシーケンス図である。以下の図１４〜図２５を参照した説明にけるステップ番号は、図１３に示す処理を示している。
ユーザが使用するＡＰＩ利用装置２１０は、ＡＰＩ利用アプリ２１１の実行を開始すると、まずユーザ登録リクエストをＡＰＩサーバ１００に送信する（ステップＳ２０１）。
【００９４】
図１４は、ユーザ登録リクエストの一例を示す図である。ユーザ登録リクエスト４１には、リクエスト対象のＡＰＩのベースパス「/app1/v1」と、ログインフォームの取得処理のリソースを示す情報「/login-forms」とが含まれる。ＡＰＩサーバ１００は、このユーザ登録リクエスト４１を受信すると、ＡＰＩ管理テーブル２３１を参照し、ＡＰＩ「app1」のログインフォームの取得要求であることを認識する。そしてＡＰＩサーバ１００は、ＡＰＩ管理テーブル２３１からＡＰＩ「app1」のログイン画面ＵＲＩ「/login.action」を取得し、ログイン画面リクエストをＷｅｂサーバ２２０に送信する（ステップＳ２０２）。
【００９５】
図１５は、ログイン画面リクエストの一例を示す図である。ログイン画面リクエスト４２には、ログイン機能に対応する資源を指定するＦＯＲＭ認証ＵＲＩ「/login.action」が含まれている。ログイン画面リクエスト４２を受信したＷｅｂサーバ２２０は、ＦＯＲＭ認証ＵＲＩ「/login.action」で対応する資源を用いて、予め用意されているログイン画面データを取得し、そのログイン画面データをＡＰＩサーバ１００に送信する（ステップＳ２０３）。
【００９６】
図１６は、Ｗｅｂサーバが送信するログイン画面データの一例を示す図である。Ｗｅｂサーバ２２０が送信するログイン画面データ４３には、Cookie「JSESSIONID=7BF5…」が含まれている。また、ログイン画面データ４３には、ログイン画面で入力した認証情報を、資源「/login.action」宛てに送信することが示されている。
【００９７】
ログイン画面データ４３を受信したＡＰＩサーバ１００は、認証情報の送信先をＡＰＩサーバ１００の資源に置き換えたログイン画面データを、ＡＰＩ利用装置２１０に送信する（ステップＳ２０４）。
【００９８】
図１７は、ＡＰＩサーバが送信するログイン画面データの一例を示す図である。ＡＰＩサーバが送信するログイン画面データ４４では、認証情報の送信先がＡＰＩサーバ１００内の資源「login.action」に変更されている。
【００９９】
ログイン画面データ４４を受信したＡＰＩ利用装置２１０では、ログイン画面が表示される。そしてユーザがＡＰＩ利用装置２１０に、認証情報としてユーザ名とパスワードとを入力すると、ＡＰＩ利用装置２１０は、入力された認証情報を含むＦＯＲＭ認証リクエストを、ＡＰＩサーバ１００に送信する（ステップＳ２０５）。
【０１００】
図１８は、ＡＰＩ利用装置が送信するＦＯＲＭ認証リクエストの一例を示す図である。ＦＯＲＭ認証リクエスト４５には、ログイン画面データ４４から取得したCookieとユーザが入力した認証情報とが含まれている。またＦＯＲＭ認証リクエスト４５の送信先は、ＡＰＩサーバ１００内の資源「/app1/v1/login」である。
【０１０１】
ＦＯＲＭ認証リクエスト４５を受信したＡＰＩサーバ１００は、ＦＯＲＭ認証リクエスト４５の送信先をＷｅｂサーバ２２０内の資源に変更し、変更後のＦＯＲＭ認証リクエストをＷｅｂサーバ２２０に送信する（ステップＳ２０６）。
【０１０２】
図１９は、ＡＰＩサーバが送信するＦＯＲＭ認証リクエストの一例を示す図である。ＡＰＩサーバが送信するＦＯＲＭ認証リクエスト４６では、送信先の資源が「/login.action」に変更されている。このＦＯＲＭ認証リクエスト４６を受信したＷｅｂサーバ２２０は、ＦＯＲＭ認証リクエスト４６に含まれている認証情報に基づいてユーザ認証を行う。この例では、ユーザ認証に成功したものとする。その場合、Ｗｅｂサーバ２２０は、ログイン後の画面データをＡＰＩサーバ１００に送信する（ステップＳ２０７）。
【０１０３】
図２０は、ログイン後の画面データの一例を示す図である。ログイン後の画面データ４７には、ログインに成功したことを示すメッセージが含まれる。ログイン後の画面データ４７を受信したＡＰＩサーバ１００は、ログインに使用した認証情報を認証情報管理テーブル２３２に格納し、Ｗｅｂサーバ２２０から取得したCookieを、Cookie管理テーブル２３３に格納する（ステップＳ２０８）。その後、ＡＰＩサーバ１００は、登録完了メッセージをＡＰＩ利用装置２１０に送信する（ステップＳ２０９）。
【０１０４】
図２１は、登録完了メッセージの一例を示す図である。例えば登録完了メッセージ４８には、ＡＰＩサーバ１００内の資源へのリダイレクトが指定されている。リダイレクトにより、ＡＰＩ利用装置２１０は、別の登録完了メッセージ４９をＡＰＩサーバ１００から取得する。登録完了メッセージ４９には、ユーザ登録が完了したことを示すメッセージが含まれている。
【０１０５】
ユーザ登録が完了すると、ＡＰＩ利用装置２１０は、ＡＰＩ利用アプリ２１１における処理が実行される。ＡＰＩ利用アプリ２１１の実行途中で、いずれかのＷｅｂアプリで提供されるデータの、ＷｅｂＡＰＩを介した利用処理が発生すると、ＡＰＩ利用装置２１０は、ＡＰＩサーバ１００に、Basic認証によるリソースリクエストを送信する（ステップＳ２１０）。
【０１０６】
図２２は、Basic認証によるリソースリクエストの一例を示す図である。Basic認証によるリソースリクエスト５０には、ＦＯＲＭ認証でのログインに使用された認証情報が含まれる。Basic認証に使用する認証情報は、暗号化しておくことができる。
【０１０７】
Basic認証によるリソースリクエスト５０を受信したＡＰＩサーバ１００は、Basic認証方式によるユーザ認証を行う（ステップＳ２１１）。認証に成功すると、ＡＰＩサーバ１００は、画面リクエストをＷｅｂサーバ２２０に送信する（ステップＳ２１２）。
【０１０８】
図２３は、画面リクエストの一例を示す図である。画面リクエスト５１には、ＦＯＲＭ認証でログインした際に取得したCookieが含まれる。画面リクエスト５１を受信したＷｅｂサーバ２２０は、画面リクエスト５１で指定された画面を示す画面データをＡＰＩサーバ１００に送信する（ステップＳ２１３）。
【０１０９】
図２４は、画面データの一例を示す図である。画面データ５２には、画面リクエスト５１で指定された内容に応じた情報（顧客一覧など）が含まれている。画面データ５２を受信したＡＰＩサーバ１００は、画面データから、ＡＰＩ利用装置２１０からのリクエストに応じたリソースデータを抽出する（ステップＳ２１４）。そしてＡＰＩサーバ１００は、抽出したリソースデータを、ＡＰＩ利用装置２１０に送信する（ステップＳ２１５）。
【０１１０】
図２５は、リソースデータの一例を示す図である。リソースデータ５３には、例えば画面データ５２から抽出されたデータが含まれている。またリソースデータ５３は、画面データ５２とは異なるデータ形式に変換されている。リソースデータ５３を取得したＡＰＩ利用装置２１０では、ＡＰＩ利用アプリ２１１に基づいて、リソースデータ５３を利用した処理が実行される。
【０１１１】
このように、第２の実施の形態では、ＦＯＲＭ認証を採用するＷｅｂサーバ２２０によるサービスを、Basic認証でユーザ認証を受けながら、ＡＰＩ利用装置２１０から利用することができる。その結果、ＡＰＩ利用装置２１０におけるＡＰＩ利用アプリ２１１に対して、Ｗｅｂアプリ２２１，２２２ごとの独自仕様のログイン画面それぞれに対応する処理のプログラムモジュールを組み込まずに済み、ＡＰＩ利用アプリ２１１の開発負担が軽減される。その結果、Ｗｅｂサーバ２２０のサービスを利用する際の利便性が向上する。
【０１１２】
〔その他の実施の形態〕
第２の実施の形態では、ＡＰＩサーバ１００で実施する認証方式としてBasic認証を採用しているが、Digest認証などの他の認証方式で認証を行ってもよい。ＡＰＩサーバ１００で使用できる、Basic認証・Digest認証以外の認証方式は、例えば、ログイン以外のサービス提供を要求するリクエストに認証情報を付与することで、ユーザ認証を行うことが可能な認証方式である。すなわち、ＦＯＲＭ認証を行う装置に対しては、ユーザ認証を実行する資源を指定したリクエストを送信しなければならず、ユーザ認証以外の処理のリクエストに認証情報を付加してユーザ認証を受けることができない。任意のリクエストに認証情報を付加することでユーザ認証を受け、そのリクエストに応じたサービスの提供を受けることができる認証方式であれば、サービス利用の利便性が向上する。
【０１１３】
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
【符号の説明】
【０１１４】
１  利用装置
２  サーバ
３  認証情報
４  セッションＩＤ
５  処理要求
６  取得要求
７  データ
８  実行結果
１０  情報処理装置
１１  記憶部
１２  処理部
【図１】
2018060259.tif 000003
【図２】
2018060259.tif 000004
【図３】
2018060259.tif 000005
【図４】
2018060259.tif 000006
【図５】
2018060259.tif 000007
【図６】
2018060259.tif 000008
【図７】
2018060259.tif 000009
【図８】
2018060259.tif 000010
【図９】
2018060259.tif 000011
【図１０】
2018060259.tif 000012
【図１１】
2018060259.tif 000013
【図１２】
2018060259.tif 000014
【図１３】
2018060259.tif 000015
【図１４】
2018060259.tif 000016
【図１５】
2018060259.tif 000017
【図１６】
2018060259.tif 000018
【図１７】
2018060259.tif 000019
【図１８】
2018060259.tif 000020
【図１９】
2018060259.tif 000021
【図２０】
2018060259.tif 000022
【図２１】
2018060259.tif 000023
【図２２】
2018060259.tif 000024
【図２３】
2018060259.tif 000025
【図２４】
2018060259.tif 000026
【図２５】
2018060259.tif 000027