JP6880579B2 - 情報提供システム - Google Patents

Description

本発明の実施形態は、情報提供プログラム、情報提供方法および情報提供システムに関する。

近年、ＲＥＳＴ（REpresentational State Transfer）などのＷｅｂ ＡＰＩ（Application Programming Interface）を通してシステム間の連携やクライアント端末との連携を行うＷｅｂアプリが増加している。このＷｅｂアプリでは、ＯＡｕｔｈやＳＡＭＬ（Security Assertion Markup Language）といった仕組みでユーザ認証および認可の機構を統一している。また、ＯＡｕｔｈやＳＡＭＬを採用していないＷｅｂアプリでもＷｅｂ ＡＰＩを取り入れるニーズが高まっている。このＷｅｂアプリでは、Ｃｏｏｋｉｅを利用した認証を行っており、クライアント端末とＷｅｂサーバとの間のＡＰＩサーバが認証できるように認証情報をＡＰＩサーバに渡している。

国際公開第２０１１／０９０１４４号 特開２００４−１０３０２２号公報

「The OAuth 2.0 Authorization Framework」、［平成２８年５月２８日検索］、インターネット＜URL:https://tools.ietf.org/html/rfc6749＞ 「Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants」、［平成２８年５月２８日検索］、インターネット＜URL:https://tools.ietf.org/html/rfc7522＞

しかしながら、上述したＯＡｕｔｈやＳＡＭＬを採用していないＷｅｂアプリでは、データ参照（ＧＥＴ Ｒｅｑｕｅｓｔ）時などにおいて平文の認証情報が随所で利用され、認証情報が漏洩するリスクが高くなるという問題がある。例えば、ＡＰＩサーバ上のアクセスログに、アクセスされたページへのＰａｔｈとともに認証情報が残る場合がある。また、Ｗｅｂブラウザ上の閲覧履歴にアクセスしたページのＵＲＬとともに認証情報が残る場合がある。

図１０は、従来の情報提供システムの通信例を説明する説明図である。図１０に示すように、従来の情報提供システム２００は、クライアント端末２１０、ＡＰＩサーバ２２０およびＷｅｂサーバ２３０を有する。クライアント端末２１０は、ＡＰＩサーバ２２０を通してＷｅｂサーバ２３０との通信セッションを開始して情報を閲覧する。ＡＰＩサーバ２２０は、クライアント端末２１０より得た認証情報を用いてＷｅｂサーバ２３０へアクセスする際の認証を実施し、通信セッションを開始する。

例えば、Ｂａｓｉｃ認証を利用してクライアント端末２１０からＡＰＩサーバ２２０へ認証情報を送信してＷｅｂサーバ２３０への認証を行う場合は、ＡＰＩサーバ２２０上でも平文の認証情報を取り扱うことになる。このため、認証情報が漏洩するリスクが高くなる。

また、認証情報をＧＥＴ Ｐａｒａｍｅｔｅｒへ含めて送信する場合、すなわちＲｅｑｕｅｓｔ Ｐａｔｈ上に認証情報を含める場合は、ＡＰＩサーバ２２０上のアクセスログにはアクセスされたページへのＰａｔｈとともに認証情報が残る。また、クライアント端末２１０のＷｅｂブラウザ上の閲覧履歴にもアクセスしたページのＵＲＬ（Uniform Resource Locator）とともに認証情報が残るため、認証情報の漏洩リスクは高くなる。

また、ＧＥＴ Ｒｅｑｕｅｓｔの場合は、多くのライブラリがリクエスト引数をｍｅｓｓａｇｅ−ｂｏｄｙへ含めることを許していないので、Ｒｅｑｕｅｓｔ Ｐａｔｈ上に認証情報が載ることとなる。また、データ更新などで用いるＰＯＳＴ Ｒｅｑｕｅｓｔの場合は、リクエスト引数をｍｅｓｓａｇｅ−ｂｏｄｙへ含めるので、アクセスログには認証情報が残らないが、依然認証情報をＡＰＩサーバ２２０へ格納することから認証情報の漏洩リスクは高くなる。

１つの側面では、認証情報が漏洩するリスクを低減できる情報提供プログラム、情報提供方法および情報提供システムを提供することを目的とする。

第１の案では、情報提供プログラムは、通信セッションを開始する第１のサーバ装置へ認証情報を送信して第１のサーバ装置からセッション情報を取得する処理をコンピュータに実行させる。また、情報提供プログラムは、取得したセッション情報を第２のサーバ装置へ転送して第１のサーバ装置との通信セッションを第２のサーバ装置を介して継続する処理をコンピュータに実行させる。

本発明の１実施態様によれば、認証情報が漏洩するリスクを低減できる。

図１は、実施形態にかかる情報提供システムを例示するブロック図である。 図２は、実施形態にかかる情報提供システムの動作例を示すフローチャートである。 図３は、認証画面アクセスを説明する説明図である。 図４は、Ｃｏｏｋｉｅを転送するアクセスを説明する説明図である。 図５は、Ｗｅｂサーバからのレスポンスを説明する説明図である。 図６は、Ｗｅｂサーバからのレスポンスを説明する説明図である。 図７は、リクエストから表示までの流れを説明する説明図である。 図８は、実施形態にかかる情報提供システムの通信例を説明する説明図である。 図９は、クライアント端末、ＡＰＩサーバ、Ｗｅｂサーバのハードウエア構成を例示するブロック図である。 図１０は、従来の情報提供システムの通信例を説明する説明図である。

以下、図面を参照して、実施形態にかかる情報提供プログラム、情報提供方法および情報提供システムを説明する。実施形態において同一の機能を有する構成には同一の符号を付し、重複する説明は省略する。なお、以下の実施形態で説明する情報提供プログラム、情報提供方法および情報提供システムは、一例を示すに過ぎず、実施形態を限定するものではない。また、以下の各実施形態は、矛盾しない範囲内で適宜組みあわせてもよい。

図１は、実施形態にかかる情報提供システムを例示するブロック図である。図１に示すように、情報提供システム１は、クライアント端末１０、ＡＰＩサーバ２０、Ｗｅｂサーバ３０を有する。

クライアント端末１０は、例えばＰＣ（Personal Computer）やタブレット端末などである。クライアント端末１０は、ＷｅｂブラウザなどのＷｅｂアプリを実行してＷｅｂサーバ３０にＨＴＴＰ（HyperText Transfer Protocol）でアクセスし、Ｗｅｂサーバ３０から提供された情報をユーザへ表示する。例えば、クライアント端末１０は、Ｗｅｂサーバ３０との間で通信セッションを確立した後に、Ｗｅｂサーバ３０への情報提供をリクエスト（要求）し、リクエストによるレスポンス（返信）を得てＷｅｂサーバ３０から提供された情報をユーザへ表示する。

クライアント端末１０は、認証画面アクセス部１１、認証情報管理部１２、Ｃｏｏｋｉｅ管理部１３、Ｗｅｂリソースアクセス部１４、リソース管理部１５、アプリケーション１６および表示部１７を有する。

認証画面アクセス部１１は、Ｗｅｂサーバ３０との間でリクエストＤ１およびレスポンスＤ２を送受信し、Ｗｅｂサーバ３０と通信セッションを確立するための認証プロセスを実行する。

具体的には、認証画面アクセス部１１は、Ｗｅｂサーバ３０の認証画面（ログイン画面）へアクセスし、認証画面において入力されたユーザＩＤやパスワードなどの認証情報をパラメータとするＰＯＳＴリクエストのリクエストＤ１を送信する。

Ｗｅｂサーバ３０は、リクエストＤ１に含まれる認証情報をもとに、予め登録された認証情報を管理するＤＢ（図示しない）を参照し、認証成功か認証失敗かを判定する。次いで、Ｗｅｂサーバ３０は、判定結果に応じたレスポンス画面を含むレスポンスＤ２を返信する。なお、Ｗｅｂサーバ３０は、認証成功の場合にはクライアント端末１０との間の通信セッションにかかるＣｏｏｋｉｅ（セッション情報）をレスポンスＤ２に含めて返信する。これにより、認証画面アクセス部１１は、認証成功の場合にはＣｏｏｋｉｅ（セッション情報）をＷｅｂサーバ３０より取得する。

なお、認証画面アクセス部１１は、Ｗｅｂサーバ３０との間でリクエストＤ１およびレスポンスＤ２を送受信する通信路、すなわち認証情報をＷｅｂサーバ３０へ送信してセッション情報を取得する通信路について、暗号化された通信路を用いるものとする。具体的には、認証画面アクセス部１１は、ＳＳＬ（Secure Sockets Layer）／ＴＬＳ（Transport Layer Security）を実装しており、ＳＳＬ／ＴＬＳにより暗号化された通信路を用いてリクエストＤ１およびレスポンスＤ２を送受信する。これにより、Ｗｅｂサーバ３０との間での通信において、認証情報が漏洩することを防止することができる。

認証情報管理部１２は、例えば認証画面アクセス部１１において入力されたユーザＩＤ、パスワードなどの、ユーザの認証情報を管理する。Ｃｏｏｋｉｅ管理部１３は、認証画面アクセス部１１がＷｅｂサーバ３０より取得したＣｏｏｋｉｅ（セッション情報）を管理する。

Ｗｅｂリソースアクセス部１４は、ＡＰＩサーバ２０のＡＰＩ２１との間でリクエストＤ３およびレスポンスＤ４を送受信し、ＡＰＩサーバ２０を介してＷｅｂサーバ３０が提供するＷｅｂリソースへのアクセスを行う。

具体的には、Ｗｅｂリソースアクセス部１４は、Ｗｅｂサーバ３０より取得したＣｏｏｋｉｅ（セッション情報）をＣｏｏｋｉｅ管理部１３より読み出してＡＰＩサーバ２０へ転送し、Ｗｅｂサーバ３０との間の通信セッションをＡＰＩサーバ２０を介して継続することで、Ｗｅｂサーバ３０が提供するＷｅｂリソースへアクセスする。

Ｗｅｂリソースアクセス部１４は、例えば、ＣｏｏｋｉｅをパラメータとするＧＥＴリクエストのリクエストＤ３をＡＰＩサーバ２０のＡＰＩ２１へ送信する。このＣｏｏｋｉｅの転送により、ＡＰＩサーバ２０では、認証されたユーザの権限でＷｅｂサーバ３０へのアクセスが許可され、Ｗｅｂサーバ３０が提供するＷｅｂリソースをＡＰＩサーバ２０を介してクライアント端末１０へ提供することができる。なお、Ｗｅｂサーバ３０が提供するＷｅｂリソースは、顧客情報や購買情報を管理する業務ＤＢ（データベース）などがあり、様々な現場よりアクセスして利用される。

リソース管理部１５は、Ｗｅｂリソースアクセス部１４がＡＰＩサーバ２０を介して取得したＷｅｂリソースを管理する。アプリケーション１６は、種々の論理処理を行うＷｅｂアプリにおけるアプリロジック部であり、例えば取得したＷｅｂリソースを描画用のデータに加工するなどの処理を行う。表示部１７は、モニタなどへの表示処理を行う処理部であり、描画用に加工されたＷｅｂリソースの表示などのＷｅｂアプリの処理結果を表示する。

ＡＰＩサーバ２０は、ＡＰＩ２１、コントローラ２２、ハンドラ２３、ＡＰＩセッション検証部２４、アクセス集約部２５、リクエスト変換部２６およびＨＴＭＬ２Ｏｂｊｅｃｔ部２７を有する。

ＡＰＩ２１は、Ｗｅｂサーバ３０におけるＷｅｂリソースへのアクセスを受け付けるインタフェースである。具体的には、ＡＰＩ２１は、Ｗｅｂリソースアクセス部１４よりリクエストＤ３を受信し、受信したリクエストＤ３をコントローラ２２へ出力する。また、ＡＰＩ２１は、リクエストＤ３に対応してコントローラ２２より出力されたＷｅｂサーバ３０からの返信結果をレスポンスＤ４としてクライアント端末１０へ送信する。

コントローラ２２は、ＡＰＩ２１からリクエストＤ３を受け付け、リクエストＤ３に含まれるヘッダー部やボディ部などの内容をメモリに一時記憶する。具体的には、コントローラ２２は、リクエストＤ３より、ＧＥＴなどのリクエストの種類（リクエストメソッド）、ＵＲＬなどのリクエストしたいＷｅｂリソースのパス（リクエストパス）、Ｃｏｏｋｉｅ２４ａ（セッション情報）などを抽出してメモリに一時記憶する。ハンドラ２３は、コントローラ２２によりメモリに一時記憶されたリクエストＤ３のそれぞれに対応するリクエストハンドラ２３ａ〜２３ｃを取り扱う。

ＡＰＩセッション検証部２４は、リクエストＤ３に含まれるＣｏｏｋｉｅ２４ａをＷｅｂサーバ３０へのリクエストＤ５に含めて送信し、リクエストＤ５に対するレスポンスＤ６の内容をもとに、ＡＰＩサーバ２０とＷｅｂサーバ３０との通信セッションを検証する。具体的には、ＡＰＩセッション検証部２４は、レスポンスＤ６に含まれる認証レスポンス画面を解析して認証成功か認証失敗かを判定する。認証失敗の場合は、ＡＰＩセッション検証部２４は、ＡＰＩ２１より認証失敗のレスポンスＤ４をクライアント端末１０へ送信させる。認証成功の場合は、認証成功のレスポンスＤ４をクライアント端末１０へ送信することなく、Ｗｅｂサーバ３０との通信セッションが継続される。

アクセス集約部２５は、リクエストハンドラ２３ａ〜２３ｃのリクエストごとに、リクエスト変換部２６およびＨＴＭＬ２Ｏｂｊｅｃｔ部２７によるＷｅｂサーバ３０へのアクセスを集約する。具体的には、アクセス集約部２５は、リクエストハンドラ２３ａ〜２３ｃのリクエストごとに、リクエスト変換部２６がリクエストＤ５をＷｅｂサーバ３０に送信してＨＴＭＬ２Ｏｂｊｅｃｔ部２７が受信したレスポンスＤ６の内容を集約してハンドラ２３へ出力する。これにより、ＡＰＩ２１は、リクエストハンドラ２３ａ〜２３ｃのリクエストについて、Ｗｅｂサーバ３０からのレスポンスＤ６を集約した結果をレスポンスＤ４としてクライアント端末１０へ送信する。

リクエスト変換部２６は、クライアント端末１０より受信したリクエストＤ３に対応するリクエストＤ５をＷｅｂサーバ３０へ送信する。具体的には、リクエスト変換部２６は、リクエストＤ３に含まれるＣｏｏｋｉｅ２４ａをパラメータとしてＧＥＴリクエストのリクエストＤ５を送信する。

ＨＴＭＬ２Ｏｂｊｅｃｔ部２７は、リクエストＤ５に対するＷｅｂサーバ３０からのレスポンスＤ６を受信し、アクセス集約部２５へ渡す。なお、ＨＴＭＬ２Ｏｂｊｅｃｔ部２７は、受信したレスポンスＤ６のボディ部に含まれる内容を、クライアント端末１０において読み取り可能な共通形式（ＪＳＯＮなど）に加工してアクセス集約部２５へ渡す。

Ｗｅｂサーバ３０は、Ｗｅｂサーバ３０における通信インタフェースであり、所定のネットワークアドレスが割り当てられた通信部３１を有する。Ｗｅｂサーバ３０は、通信部３１との間で通信セッションを確立したクライアント端末１０などの外部機器に対して様々な情報を提供する。例えば、Ｗｅｂサーバ３０は、ＨＴＴＰでのリクエストに応じたレスポンスを返してＨＴＭＬ（ HyperText Markup Language）などで記述された情報を提供する。

図２は、実施形態にかかる情報提供システム１の動作例を示すフローチャートである。図２に示すように、処理が開始されると、クライアント端末１０の認証画面アクセス部１１は、リクエストＤ１をＷｅｂサーバ３０へ送信してレスポンスＤ２を受信することでログイン画面（認証画面）を取得し、Ｗｅｂサーバ３０との通信セッションを開始する（Ｓ１）。

図３は、認証画面アクセスを説明する説明図である。図３に示すように、Ｓ１１において認証画面アクセス部１１は、ログイン画面のＧＥＴリクエストのリクエストＤ１をＷｅｂサーバ３０に送信し、Ｗｅｂサーバ３０よりログイン画面についてのレスポンスＤ２を受信する。認証画面アクセス部１１は、レスポンスＤ２に含まれるＣｏｏｋｉｅを抽出してＣｏｏｋｉｅ管理部１３に出力する。また、認証画面アクセス部１１は、ＣＳＲＦ（Cross Site Request Forgeries）による成りすまし防止トークンなどがＷｅｂサーバ３０から送られているときは防止トークンもＣｏｏｋｉｅとともに抽出してＣｏｏｋｉｅ管理部１３に出力する。

次いで、認証画面アクセス部１１は、ユーザが入力したユーザＩＤやパスワードなど、認証情報管理部１２が管理している認証情報を含むＰＯＳＴリクエストのリクエストＤ１をＷｅｂサーバ３０へ送信する（Ｓ２）。次いで、認証画面アクセス部１１は、認証情報に基づく判定結果に応じたレスポンス画面を含むレスポンスＤ２をＷｅｂサーバ３０より受信する（Ｓ３）。

具体的には、図３に示すように、Ｓ２において認証画面アクセス部１１は、「ｕｉｄ」、「ｐａｓｓｗｄ」などが設定されたリクエストＤ１をＷｅｂサーバ３０へ送信する。また、Ｓ３において認証画面アクセス部１１は、「ｕｉｄ」、「ｐａｓｓｗｄ」の判定結果に応じたレスポンス画面を含むレスポンスＤ２をＷｅｂサーバ３０より受信する。

次いで、認証画面アクセス部１１は、レスポンスＤ２に含まれる、認証レスポンス画面を解析し、認証成功か否かを判定する（Ｓ４）。例えば、認証画面アクセス部１１は、認証失敗を示すエラーコードが含まれる場合は認証失敗と判定し、認証失敗を示すエラーコードが含まれない場合には認証成功と判定する。

Ｓ４において認証失敗の場合、認証画面アクセス部１１はＳ１へ処理を戻す。また、認証失敗の場合、Ｗｅｂサーバ３０においては、クライアント端末１０に送信したＣｏｏｋｉｅに対する通信セッションが認証失敗（ログイン未承認）とされる。

Ｓ４において認証成功の場合は、レスポンスＤ２に含まれるレスポンス画面が表示部１７によりユーザに対して表示される。例えば認証成功の場合、図３に示すように、表示部１７の表示画面Ｇ１には、認証成功のユーザに対するレスポンス画面である、ユーザのポータル画面が表示される。ユーザは、表示画面Ｇ１上での操作により、Ｗｅｂサーバ３０が提供する各種Ｗｅｂリソースをリクエストする。また、Ｗｅｂサーバ３０においては、クライアント端末１０に送信したＣｏｏｋｉｅに対する通信セッションが認証成功（ログイン済み）として継続されることとなる。

Ｓ４において認証成功の場合、認証画面アクセス部１１は、レスポンスＤ２に含まれるＣｏｏｋｉｅを抽出し（Ｓ５）、Ｃｏｏｋｉｅ管理部１３に出力する。これにより、Ｗｅｂサーバ３０において認証が成功した通信セッション（ログイン済み）のＣｏｏｋｉｅがＣｏｏｋｉｅ管理部１３で管理されることとなる。

次いで、Ｗｅｂリソースアクセス部１４は、表示画面Ｇ１（図３参照）上での操作などにより、Ｗｅｂサーバ３０が提供する各種Ｗｅｂリソースについてのリクエストをユーザより受け付ける。次いで、Ｗｅｂリソースアクセス部１４は、ユーザよりリクエストのあったＷｅｂリソースについてのＧｅｔリクエストとログイン済みのＣｏｏｋｉｅ（セッション情報）をＡＰＩサーバ２０へ送信する（Ｓ６）。

図４は、Ｃｏｏｋｉｅを転送するアクセスを説明する説明図である。図４に示すように、Ｓ６においてＷｅｂリソースアクセス部１４は、ログイン済みのＣｏｏｋｉｅ（セッション情報）をパラメータとするＧＥＴリクエストのリクエストＤ３をＡＰＩサーバ２０のＡＰＩ２１へ送信する。このＧＥＴリクエストには、ユーザよりリクエストのあったＷｅｂリソースについてのリソースパスがＷｅｂサーバ３０のＣｏｏｏｋｉｅとともに含まれている。

次いで、ＡＰＩサーバ２０のコントローラ２２は、クライアント端末１０からＧｅｔリクエストとＣｏｏｋｉｅ（セッション情報）を受信し（Ｓ７）、Ｇｅｔリクエストをログへ記録する（Ｓ８）。次いで、ＡＰＩサーバ２０では、リクエストＤ３に応じたＷｅｂサーバ３０へのアクセスにかかる、Ｓ９〜Ｓ１５のループ処理を行う。

図４におけるリクエストＤ３の例では、リクエストパスが「ａｐｉ／ｃｏｍｐａｎｙ／ｘｙｚ＿ｏｒｚ／ｍｅｍｂｅｒ／ａｌｉｃｅ」である。よって、Ｓ９〜Ｓ１５のループ処理では、「ｘｙｚ＿ｏｒｚ」の「ｃｏｍｐａｎｙ」に属する「ｍｅｍｂｅｒ」の「ａｌｉｃｅ」の情報についてアクセスが行われる。

ループ処理が開始されると、リクエスト変換部２６は、リクエストＤ３に応じたＧｅｔリクエストとＣｏｏｋｉｅ（セッション情報）をＷｅｂサーバ３０へ送信する（Ｓ１０）。具体的には、図４に示すように、Ｓ１０においてリクエスト変換部２６は、リクエストＤ３に含まれるＣｏｏｋｉｅ（セッション情報）とリクエストパスとを有するリクエストＤ５をＷｅｂサーバ３０へ送信する。すなわち、リクエスト変換部２６は、クライアント端末１０のリクエストＤ３に含まれるＣｏｏｋｉｅ（セッション情報）をＷｅｂサーバ３０へ転送することで、認証されたユーザの権限でＷｅｂサーバ３０へアクセスする。なお、リクエストＤ５は、例えば「ａｐｉ／ｃｏｍｐａｎｙ／ｘｙｚ＿ｏｒｚ／ｍｅｍｂｅｒ／ａｌｉｃｅ」のリクエストパスへのアクセスを示す所定のＲＥＳＴフォーマットであってもよい。

次いで、ＨＴＭＬ２Ｏｂｊｅｃｔ部２７はリクエストＤ５に対応するボディデータＤ７を受信する。次いで、ＡＰＩセッション検証部２４は、レスポンスＤ６に含まれる認証レスポンス画面を解析し、認証成功か否かを判定する（Ｓ１１）。例えば、ＡＰＩセッション検証部２４は、認証失敗を示すエラーコードが含まれる場合は認証失敗と判定し、認証失敗を示すエラーコードが含まれない場合には認証成功と判定する。

Ｓ１１において認証失敗の場合、ＡＰＩセッション検証部２４は、認証失敗を示すエラーコードなどを付与したレスポンスＤ４をＡＰＩ２１よりクライアント端末１０へ送信させ、認証が失敗したことを通知する（Ｓ１２）。

図５は、Ｗｅｂサーバ３０からのレスポンスを説明する説明図であり、より具体的には認証が失敗した場合のレスポンスを示す図である。

図５に示すように、Ｃｏｏｋｉｅ（セッション情報）による認証が失敗した場合には、「４０１」などのエラーコードを示すレスポンスＤ６がＷｅｂサーバ３０よりＡＰＩサーバ２０に通知される。この場合、ＡＰＩセッション検証部２４は、「４０１」のエラーコードを付与したレスポンスＤ４をＡＰＩ２１よりクライアント端末１０に送信させ、認証失敗を通知する。

認証失敗の通知を受けたクライアント端末１０では、Ｃｏｏｋｉｅ（セッション情報）による認証が失敗し、通信セッションが途切れていることから、ログイン認証をやり直すためにＳ１へ処理を戻す。

Ｓ１１において認証成功の場合、ＨＴＭＬ２Ｏｂｊｅｃｔ部２７は、リクエストしたデータ（ＨＴＭＬ文書）、すなわちリクエストＤ５に対するレスポンスＤ６を受信する（Ｓ１３）。次いで、ＨＴＭＬ２Ｏｂｊｅｃｔ部２７は、受信したデータをクライアント端末１０が読める形式（ＪＳＯＮなど）に加工する（Ｓ１４）。

図６は、Ｗｅｂサーバ３０からのレスポンスを説明する説明図であり、より具体的には認証が成功した場合のレスポンスを示す図である。図６に示すように、Ｃｏｏｋｉｅ（セッション情報）による認証が成功した場合には、リクエストしたデータ（ＨＴＭＬ文書）を含むレスポンスＤ６がＷｅｂサーバ３０よりＡＰＩサーバ２０に通知される。ＨＴＭＬ２Ｏｂｊｅｃｔ部２７は、レスポンスＤ６においてＨＴＭＬ文書が格納されたボディデータＤ７をもとに、ＪＳＯＮなどの所定の形式に加工した加工済データＤ８を作成する。クライアント端末１０では、加工済データＤ８を得ることで、リクエストしたデータの表示画面Ｇ２を描画することができる。

アクセス集約部２５では、リクエストＤ３においてリクエストされたデータの全てがＷｅｂサーバ３０より得られるまでループ処理（Ｓ９〜Ｓ１５）を継続し、得られたデータを集約してハンドラ２３へ出力する。

次いで、ＡＰＩ２１は、Ｗｅｂサーバ３０より受信したデータ（加工済データＤ８）をレスポンスＤ４としてクライアント端末１０へ送信する（Ｓ１６）。クライアント端末１０のリソース管理部１５は、レスポンスＤ４に含まれる加工済データＤ８を描画用のデータ（所定の描画サイズや着色）に加工（例えばＭａｐ形式への加工）するなどの処理を行う。次いで、表示部１７は、リソース管理部１５により加工されたデータをユーザへ表示する（Ｓ１７）。

図７は、リクエストから表示までの流れを説明する説明図である。図７に示すように、ＡＰＩサーバ２０は、Ｗｅｂサーバ３０へのリクエストＤ５に対するレスポンスＤ６に含まれるボディデータＤ７をもとに、加工済データＤ８を得る。そして、ＡＰＩサーバ２０は、得られた加工済データＤ８をボディ部にセットしたレスポンスＤ４をクライアント端末１０へ送信する。このレスポンスＤ４を受けてクライアント端末１０では、Ｗｅｂサーバ３０より得られたＷｅｂリソースを表示部１７の表示画面Ｇ２上に表示し、ユーザへの表示を行う。

図８は、実施形態にかかる情報提供システム１の通信例を説明する説明図である。図８に示すように、クライアント端末１０は、通信セッションを開始するＷｅｂサーバ３０へ認証情報を送信（Ｄ１）してＷｅｂサーバ３０からセッション情報（Ｃｏｏｋｉｅ）を取得（Ｄ２）する。また、クライアント端末１０は、取得したセッション情報をＡＰＩサーバ２０へ転送（Ｄ３）してＷｅｂサーバ３０との通信セッションをＡＰＩサーバ２０を介して継続（Ｄ５、Ｄ６、Ｄ４）する。これにより、クライアント端末１０は、認証情報をＡＰＩサーバ２０に渡すことなくＷｅｂサーバ３０よりＡＰＩサーバ２０を介してＷｅｂリソースの提供を受けることができるので、認証情報が漏洩するリスクを低減できる。

また、Ｗｅｂサーバ３０において、ログイン認証後のＡＰＩサーバ２０を介した通信セッションの確認は、従来のＣｏｏｋｉｅを用いた確認を行えばよい。このため、Ｗｅｂサーバ３０では、既存のシステムの改修なしにサービスを提供できる。例えば、Ｗｅｂサーバ３０において、ＡＰＩサーバ２０からのログイン認証を受け付けるなどの改修を行わなくてもよい。

なお、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

また、クライアント端末１０、ＡＰＩサーバ２０、Ｗｅｂサーバ３０で行われる各種処理機能は、ＣＰＵ（またはＭＰＵ、ＭＣＵ（Micro Controller Unit）等のマイクロ・コンピュータ）上で、その全部または任意の一部を実行するようにしてもよい。また、各種処理機能は、ＣＰＵ（またはＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行されるプログラム上、またはワイヤードロジックによるハードウエア上で、その全部または任意の一部を実行するようにしてもよいことは言うまでもない。また、ＡＰＩサーバ２０、Ｗｅｂサーバ３０で行われる各種処理機能は、クラウドコンピューティングにより、複数のコンピュータが協働して実行してもよい。

ところで、上記の実施形態で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することで実現できる。そこで、以下では、上記の実施形態と同様の機能を有するプログラムを実行するコンピュータ（ハードウエア）の一例を説明する。図９は、実施形態にかかるクライアント端末１０、ＡＰＩサーバ２０、Ｗｅｂサーバ３０のハードウエア構成を例示するブロック図である。なお、以下の説明ではクライアント端末１０のハードウエア構成例を代表して説明する。

図９に示すように、クライアント端末１０は、各種演算処理を実行するＣＰＵ１０１と、データ入力を受け付ける入力装置１０２と、モニタ１０３と、スピーカ１０４とを有する。また、クライアント端末１０は、記憶媒体からプログラム等を読み取る媒体読取装置１０５と、各種装置と接続するためのインタフェース装置１０６と、有線または無線により外部機器と通信接続するための通信装置１０７とを有する。また、クライアント端末１０は、各種情報を一時記憶するＲＡＭ１０８と、ハードディスク装置１０９とを有する。また、クライアント端末１０内の各部（１０１〜１０９）は、バス１１０に接続される。

ハードディスク装置１０９には、上記の実施形態で説明した認証画面アクセス部１１、認証情報管理部１２、Ｃｏｏｋｉｅ管理部１３、Ｗｅｂリソースアクセス部１４、リソース管理部１５、アプリケーション１６および表示部１７における各種の処理を実行するためのプログラム１１１が記憶される。また、ハードディスク装置１０９には、プログラム１１１が参照する各種データ１１２が記憶される。入力装置１０２は、例えば、情報提供システム１の操作者から操作情報の入力を受け付ける。モニタ１０３は、例えば、操作者が操作する各種画面を表示する。インタフェース装置１０６は、例えば印刷装置等が接続される。通信装置１０７は、ＬＡＮ（Local Area Network）等の通信ネットワークと接続され、通信ネットワークを介した外部機器との間で各種情報をやりとりする。

ＣＰＵ１０１は、ハードディスク装置１０９に記憶されたプログラム１１１を読み出して、ＲＡＭ１０８に展開して実行することで、各種の処理を行う。なお、プログラム１１１は、ハードディスク装置１０９に記憶されていなくてもよい。例えば、クライアント端末１０が読み取り可能な記憶媒体に記憶されたプログラム１１１を読み出して実行するようにしてもよい。クライアント端末１０が読み取り可能な記憶媒体は、例えば、ＣＤ−ＲＯＭやＤＶＤディスク、ＵＳＢ（Universal Serial Bus）メモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリ、ハードディスクドライブ等が対応する。また、公衆回線、インターネット、ＬＡＮ等に接続された装置にこのプログラム１１１を記憶させておき、クライアント端末１０がこれらからプログラム１１１を読み出して実行するようにしてもよい。

１…情報提供システム
１０…クライアント端末
１１…認証画面アクセス部
１２…認証情報管理部
１３…Ｃｏｏｋｉｅ管理部
１４…Ｗｅｂリソースアクセス部
１５…リソース管理部
１６…アプリケーション
１７…表示部
２０…ＡＰＩサーバ
２１…ＡＰＩ
２２…コントローラ
２３…ハンドラ
２３ａ〜２３ｃ…リクエストハンドラ
２４…ＡＰＩセッション検証部
２４ａ…Ｃｏｏｋｉｅ
２５…アクセス集約部
２６…リクエスト変換部
２７…ＨＴＭＬ２Ｏｂｊｅｃｔ部
３０…Ｗｅｂサーバ
３１…通信部
１０１…ＣＰＵ
１０２…入力装置
１０３…モニタ
１０４…スピーカ
１０５…媒体読取装置
１０６…インタフェース装置
１０７…通信装置
１０８…ＲＡＭ
１０９…ハードディスク装置
１１０…バス
１１１…プログラム
１１２…各種データ
Ｄ１、Ｄ３、Ｄ５…リクエスト
Ｄ２、Ｄ４、Ｄ６…レスポンス
Ｄ７…ボディデータ
Ｄ８…加工済データ
Ｇ１、Ｇ２…表示画面

Claims (1)

1. 第１のサーバ装置と、第２のサーバ装置と、クライアント端末とを有する情報提供システムにおいて、
   前記クライアント端末は、
   前記第１のサーバ装置へ認証情報を送信して前記第１のサーバ装置からセッション情報を取得する第１のアクセス部と、
   取得した前記セッション情報を前記第２のサーバ装置へ転送して当該第２のサーバ装置を介して前記第１のサーバ装置への情報提供を要求する第２のアクセス部とを有し、
   前記第２のサーバ装置は、
   前記転送されたセッション情報を用いて前記第１のサーバ装置へ前記クライアント端末からの情報提供を要求するリクエスト部と、
   前記リクエスト部の要求に対する前記第１のサーバ装置からの返信に基づき、前記セッション情報に関する通信セッションを検証する検証部と、
   前記通信セッションの検証の結果、認証成功である場合に、前記第１のサーバ装置からの返信を前記クライアント端末へ送信する送信部と
   を有することを特徴とする情報提供システム。

Images