JP6792133B2 - サーバと、その処理方法及びプログラム - Google Patents

Description

本発明は、認証サーバと連携してアプリケーションを実行させるように制御する仕組みに関する。

近年、クラウド上で利用されるＷｅｂサイトでは、複数のＷｅｂＡＰＩを利用したサイトが増えてきている。

例えば、不動産情報検索Ｗｅｂサイトにおいては、Ｗｅｂサイト運営会社がすべての不動産情報を持っているわけではなく、不動産業者や地図情報提供会社が提供するＷｅｂＡＰＩ（Ｗｅｂ上で提供されるＡｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を利用し、不動産業者が持つ不動産情報や地図情報を取得して検索Ｗｅｂサイトに表示していることが多い。

このように、他社が提供するＷｅｂＡＰＩを複数利用し、Ｗｅｂアプリケーションを構築する開発手法をマッシュアップという。マッシュアップのようなアプリケーションの開発手法は、短期間でＷｅｂサイトを構築することができるため利便性が高いが、利用するＷｅｂＡＰＩが信頼性のあるものかを証明する術はない。

また、個人情報漏洩、オープンソースの脆弱性などセキュリティ事故の報道が絶えないことから、クラウド情報セキュリティ確保のニーズが衰えることはないと考えられる。

よって、今後、提供されるＷｅｂＡＰＩ、および、ＷｅｂＡＰＩを利用したＷｅｂサイトが増加するにつれ、ＳａａＳを提供するＷｅｂＡＰＩ利用者（Ｗｅｂサイト運営者）は、利用する他社製ＡＰＩについて一つ一つ信頼性を確認するには大変手間がかかってしまう。また、同様に、ＷｅｂＡＰＩ提供者は、ＷｅｂＡＰＩによって機能を提供するだけではなく、品質を担保することが重要になってくる。

特許文献１では、サービス事業者がネットワーク上でＡＰＩや情報を公開する場合に、サービス提供ポリシーに応じて、公開を許諾する相手を容易に制御可能とする、また、ユーザの匿名性を保ったまま、異なる複数のサービスプロバイダ間で、ユーザ情報を連携させたサービスの提供を可能とする技術が記載されている。

特開２０１０−２２５０７４号公報

しかし、特許文献１のシステムでは、クラウド上のサービス（ＳａａＳ＝Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）を提供するＷｅｂＡＰＩ利用者にとっては、利用する他社製ＷｅｂＡＰＩについての信頼性確認作業は効率化されないという課題がある。また、ＷｅｂＡＰＩ提供者にとっては、提供するＷｅｂＡＰＩの品質を証明する方法がないという課題がある。

また、今後、ＩＳＯ／ＩＥＣ２７００１において、クラウドセキュリティの領域ＩＳＯ／ＩＥＣ ２７０１７が国際標準になった場合、ＩＳＯ２７０１７に準拠したＷｅｂＡＰＩをサービスとして提供する企業は、ＩＳＯ２７０１７の業務プロセスにおいて、認証機関から審査を受け、ＷｅｂＡＰＩをの認証を受けることが考えられる。このような認証制度においては、認証を受けた企業が認証の更新を行わない／更新の際に認証が認められない場合がある。このような場合、ＩＳＯ２７０１７の認証がないＷｅｂＡＰＩサービスが提供されている状態となり、ＷｅｂＡＰＩを利用して顧客へＷｅｂサービス（アプリケーション）を提供している企業として信頼性や品質を担保できないことになる。

また、ＷｅｂＡＰＩ提供者ごとにＷｅｂＡＰＩ認証の更新タイミングが異なること、ＷｅｂＡＰＩ利用者は様々なＷｅｂＡＰＩを利用してＷｅｂサービスを構築していることから、ＷｅｂＡＰＩ利用者がすべてのＷｅｂＡＰＩの認証について継続されていることを確認するのは非常に困難である。
そこで、本発明の目的は、外部に公開されたサービスのＡＰＩに係る認証情報の有効性に基づき、当該ＡＰＩを利用するアプリケーションの実行を適切に制御する仕組みを提供することである。

１以上の外部に公開されたサービスのＡＰＩの認証に係る認証装置と通信可能であり、ＡＰＩを利用するアプリケーションを実行するサーバであって、前記アプリケーションが利用するＡＰＩの認証に係る認証装置を決定する決定手段と、前記ＡＰＩの前記認証装置に係る秘密鍵を用いて暗号化された認証情報を取得する認証情報取得手段と、前記決定した認証装置との通信により取得した前記認証装置に係る公開鍵を用いて前記暗号化された認証情報を復号した認証情報に基づいて、当該認証情報の有効性を判定する判定手段と、前記判定手段による有効性の判定結果に基づき、前記アプリケーションの実行を制御する実行制御手段とを備えることを特徴とするサーバ。

本発明によれば、外部に公開されたサービスのＡＰＩに係る認証情報の有効性に基づき、当該ＡＰＩを利用するアプリケーションの実行を適切に制御する仕組みを提供することができる。

本発明の実施形態における認証システム１００の構成の一例を示す図 情報処理装置１０１、ＳａａＳサーバ１０２、ＷｅｂＡＰＩサーバ１０３、認証サーバ１０４、およびＩＳＭＳ認証サーバ１０５のハードウエア構成の一例を示す図 ＳａａＳサーバ１０２および認証サーバ１０４の機能構成の一例を示すブロック図 クラウドセキュリティ認証の処理概要の一例を示す図 クラウドセキュリティ認証処理１の一例を示す図 クラウドセキュリティ認証処理２の一例を示す図 クラウドセキュリティ認証処理３の一例を示す図 クラウドセキュリティ認証処理４の一例を示す図 ＷｅｂＡＰＩ認証情報登録処理の一例を示すフローチャート ＷｅｂＡＰＩ提供者電子証明書生成処理の一例を示すフローチャート ＷｅｂＡＰＩ提供者電子証明書登録処理の一例を示すフローチャート クラウドセキュリティ認証局電子証明書取得処理の一例を示すフローチャート ＳａａＳマネジメントコンソールに係る処理の一例を示すフローチャート ＷｅｂＡＰＩリスト取得処理の一例を示すフローチャート ＷｅｂＡＰＩ認証確認処理の一例を示すフローチャート ＳａａＳマネジメントコンソール表示処理の一例を示すフローチャート Ｗｅｂサービス実行処理の一例を示すフローチャート 認証サーバ１０４におけるＷｅｂＡＰＩ認証情報登録画面の一例を示す図 認証サーバ１０４において管理するテーブルの一例を示す図 ＷｅｂＡＰＩ認証情報の一例を示す図 ＳａａＳサーバ１０２において管理するＷｅｂＡＰＩリストの一例を示す図 ＳａａＳサーバ１０２が出力するＳａａＳマネジメントコンソール画面の一例を示す図 第２の実施形態に係るＳａａＳサーバ１０２が出力するＳａａＳマネジメントコンソール画面の一例を示す図 第２の実施形態に係るＳａａＳサーバ１０２において管理するＷｅｂＡＰＩリストの一例を示す図 第２の実施形態に係るＳａａＳマネジメントコンソール表示処理の一例を示すフローチャート 第２の実施形態に係る情報処理装置１０１に出力されるＷｅｂページの一例を示す図 第２の実施形態に係るＷｅｂサービス実行処理の一例を示すフローチャート

〔第１の実施形態〕
以下、図面を参照して本発明の実施形態を詳細に説明する。
図１は、本発明の実施形態における認証システム１００の構成の一例を示す図である。

本発明においては、クラウドセキュリティ認証局００４のような組織が設置されると仮定する。クラウドセキュリティ認証局００４は、ＡＰＩ提供業の認証を人的に確認し、クラウドセキュリティ認証局の公開鍵１４１の発効と、その認証サービスの提供を行う。
情報処理装置１０１は、Ｗｅｂサービス利用者００１が利用する端末であり、インターネットに繋がった端末である。

ＳａａＳサーバ１０２は、ＷｅｂＡＰＩ利用者００２（つまり、Ｗｅｂサービス（ＳａａＳ）提供者）が、Ｗｅｂサービス利用者００１に対して、Ｗｅｂサービスを提供するサーバである。本実施形態において、Ｗｅｂサービスとは、Ｗｅｂ上で提供されるアプリケーションのことを意味し、ＳａａＳサーバ１０２は、いわゆるアプリケーションサーバである。

ＷｅｂＡＰＩサーバ１０３は、ＷｅｂＡＰＩ提供者００３が、ＷｅｂＡＰＩ利用者００２に対して、ＷｅｂＡＰＩを提供するサーバであり、公開鍵暗号方式を使って、クラウドセキュリティ認証局００４の証明を受ける。
認証サーバ１０４は、クラウドセキュリティ認証局００４が、ＷｅｂＡＰＩの認証をおこなうためのサーバである。

ＩＳＭＳ認証機関００５は、認証そのものに関する文書を提供する。なお、ＩＳＭＳ認証機関００５が、クラウドセキュリティ認証局００４の役割を担う構成であってもよい。ＩＳＭＳ認証サーバ１０５は、ＩＳＭＳ認証に関する申請情報や文書を記憶する。

情報処理装置１０１、ＳａａＳサーバ１０２、ＷｅｂＡＰＩサーバ１０３、認証サーバ１０４、およびＩＳＭＳ認証サーバ１０５は、ネットワーク１０６上に通信可能に接続されている。なお、ネットワーク１０６は、インターネットとして説明する。

以下、図２を用いて、図１に示した情報処理装置１０１、ＳａａＳサーバ１０２、ＷｅｂＡＰＩサーバ１０３、認証サーバ１０４、およびＩＳＭＳ認証サーバ１０５に適用可能なハードウエア構成の一例について説明する。

図２において、２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な各種プログラム等が記憶されている。

２０２はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０３あるいは外部メモリ２１１からＲＡＭ２０２にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。

また、２０５は入力コントローラで、入力装置２０９等からの入力を制御する。２０６はビデオコントローラで、液晶ディスプレイ等のディスプレイ装置２１０への表示を制御する。なお、ディスプレイ装置は、液晶ディスプレイに限られず、ＣＲＴディスプレイなどであっても良い。これらは必要に応じてクライアントが使用するものである。

２０７はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶するハードディスク（ＨＤ）や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

２０８は通信Ｉ／Ｆコントローラで、ネットワーク１０６を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ装置２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ装置２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

ハードウエア上で動作する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。
なお、全ての装置がこれらの構成を備えているわけではなく、必要なものを夫々備えていればよい。
図３は、ＳａａＳサーバ１０２および認証サーバ１０４の機能構成の一例を示すブロック図である。
ＳａａＳサーバ１０２上のＡＰＩ識別情報記憶部３０１は、ＳａａＳサーバ１０２で利用されるＡＰＩ識別情報を記憶する機能部である。

ＳａａＳサーバ１０２上のＡＰＩ認証情報取得部３０２は、ＡＰＩ識別情報記憶部３０１により記憶されたＡＰＩ識別情報を用いて、認証サーバからＡＰＩの認証情報を取得する機能部である。

ＳａａＳサーバ１０２上のＡＰＩ認証判定部３０３は、ＡＰＩ認証情報取得部３０２により取得した認証情報に基づいて、ＡＰＩ識別情報記憶部３０１により記憶されたＡＰＩが認証サーバにおいて認証されているか否かを判定する機能部である。

ＳａａＳサーバ１０２上の実行制御部３０４は、ＡＰＩ認証判定部３０３によりＡＰＩが認証されていると判定された場合、アプリケーションを実行させるように制御し、ＡＰＩ認証判定部３０３によりＡＰＩが認証されていないと判定された場合、アプリケーションの実行を抑止させるように制御する機能部である。
ＳａａＳサーバ１０２上のアプリケーション実行可否判定部３０５は、アプリケーションの実行の可否を判定する機能部である。

ＳａａＳサーバ１０２上の実行制御部３０４は、アプリケーション実行可否判定部３０５により、アプリケーションを実行すると判定された場合、アプリケーションを実行し、アプリケーションを実行しないと判定された場合、アプリケーションの実行を抑止させるべくアプリケーションを実行させるように制御する機能部である。
ＳａａＳサーバ１０２上のＡＰＩ利用可否判定部３０６は、ＡＰＩの利用可否を判定する機能部である。

ＳａａＳサーバ１０２上の実行制御部３０４は、ＡＰＩ利用可否判定部３０６により、ＡＰＩを利用すると判定された場合、ＡＰＩを利用してアプリケーションを実行させるように制御し、ＡＰＩを利用しないと判定された場合、ＡＰＩを利用せずにアプリケーションを実行させるように制御する機能部である。

ＳａａＳサーバ１０２上の非認証ＡＰＩ通知部３０７は、ＡＰＩ認証情報取得部３０２により取得した認証情報を用いて、認証されているＡＰＩと認証されていないＡＰＩとを識別可能に通知する機能部である。
ＳａａＳサーバ１０２上のＡＰＩ有効期限判定部３０８は、有効期限が切れているか否かを判定する機能部である。

ＳａａＳサーバ１０２上の実行制御部３０４は、ＡＰＩ有効期限判定部３０８により有効期限が切れているＡＰＩが存在すると判定した場合であっても、ＡＰＩを利用してアプリケーションを実行させるように制御する機能部である。
ＳａａＳサーバ１０２上のＡＰＩ認証情報取得部３０２は、認証サーバが持つ公開鍵を取得する機能部である。

ＳａａＳサーバ１０２上のＡＰＩ認証判定部３０３は、公開鍵を用いて、ＡＰＩ識別情報記憶部３０１により記憶されたＡＰＩが認証サーバにおいて認証されているか否かを判定する機能部である。
ＳａａＳサーバ１０２上の連絡先情報記憶部３０９は、ＡＰＩを提供する提供者の連絡先情報を記憶する機能部である。

ＳａａＳサーバ１０２上の認証結果通知部３１０は、ＡＰＩ認証判定部３０３により判定されたＡＰＩの認証結果を、連絡先情報記憶部３０９により記憶されたＡＰＩを提供する提供者の連絡先情報を用いて通知する機能部である。

ＳａａＳサーバ１０２上の画面情報生成部３１１は、ＡＰＩ認証判定部３０３により認証されていると判定されたＡＰＩと、ＡＰＩ認証判定部３０３により認証されていないと判定されたＡＰＩとを識別して表示する画面情報を生成する機能部である。

認証サーバ１０４上の認証情報取得部３１２は、ＳａａＳサーバ１０２から受信したＡＰＩ識別情報を用いて、ＳａａＳサーバ１０２から要求されたＡＰＩの認証情報を取得する機能部である。
認証サーバ１０４上の認証情報送信部３１３は、認証情報取得部３１２により取得したＡＰＩの認証情報をＳａａＳサーバ１０２に送信する機能部である。

図４は、クラウドセキュリティ認証の処理概要の一例を示す図である。
Ｗｅｂサービス利用者００１は、ＷｅｂＡＰＩ利用者（ＳａａＳ提供者）００２より、Ｗｅｂサービス（ＳａａＳ）の提供を受ける。

ＷｅｂＡＰＩ利用者００２は、ＷｅｂＡＰＩ提供者００３からＷｅｂＡＰＩの提供を受けると同時に、クラウドセキュリティ認証局００４に認証確認を要求し、認証可否情報を受信する。
クラウドセキュリティ認証局００４は、ＩＳＭＳ認証機関００５に対して、ＷｅｂＡＰＩ提供者００３の認証確認を要求し、それを示す認証文書を受け取る。

なお、ＷｅｂＡＰＩ提供者００３は、ＷｅｂＡＰＩ提供者００３が提供する業務スコープについて、事前にＩＳＭＳ認証機関００５に対して、ＩＳＭＳの審査申請を行い、審査および認証を受けておくことを前提とする。
図５、図６、図７、図８は、クラウドセキュリティ認証処理の一例を示す図である。

以下において、図５、図６、図７、図８の各ステップを参照しながら、必要に応じて、図９〜図１７のフローチャート、図１８〜２２の画面およびデータについて説明する。なお、以下における、情報処理装置１０１、ＳａａＳサーバ１０２、ＷｅｂＡＰＩサーバ１０３、認証サーバ１０４、およびＩＳＭＳ認証サーバ１０５が行う処理は、それぞれの装置、サーバのＣＰＵ２０１が行うものとする。
図５は、クラウドセキュリティ認証処理１の一例を示す図である。

ステップ５０１において、ＷｅｂＡＰＩサーバ１０３は、ＷｅｂＡＰＩ提供者００３の操作に基づき、ＩＳＭＳ認証サーバ１０５に対して、ＷｅｂＡＰＩ提供者００３が提供する業務スコープに係るＩＳＭＳ審査情報を送信して申請する。

ステップ５０２において、ＩＳＭＳ認証サーバ１０５は、ＷｅｂＡＰＩサーバ１０３から申請されたＩＳＭＳ審査情報をチェックし、審査および認証処理を行う。

ステップ５０３において、ＩＳＭＳ認証サーバ１０５は、ＩＳＭＳ認証機関００５の操作に基づき、ＷｅｂＡＰＩサーバ１０３に対して、認証結果情報を送信する。
ステップ５０４において、ＷｅｂＡＰＩサーバ１０３は、ＩＳＭＳ認証サーバ１０５から送信されたＩＳＭＳ認証結果を受信する。

ステップ５０５において、ＷｅｂＡＰＩサーバ１０３は、ＩＳＭＳ認証を受けることができた場合、公開鍵暗号方式を使用するツール（例えば、ｓｓｈ−ｋｅｙｇｅｎ）によって、ＷｅｂＡＰＩサーバ１０３にて提供するＷｅｂＡＰＩの公開鍵１３１とＷｅｂＡＰＩの秘密鍵１３２を作成する。

ステップ５０６において、ＷｅｂＡＰＩサーバ１０３は、認証サーバ１０４に対して、ＷｅｂＡＰＩの認証申請情報と、ステップ５０５にて作成したＷｅｂＡＰＩの公開鍵１３１とを送信する。
ステップ５０７において、認証サーバ１０４は、ＷｅｂＡＰＩサーバ１０３から送信されたＷｅｂＡＰＩの認証申請情報と公開鍵１３１を受信する。

ステップ５０８において、認証サーバ１０４は、ＩＳＭＳ認証サーバ１０５に対して、ＷｅｂＡＰＩの認証申請情報を送信し、対象のＷｅｂＡＰＩがＷｅｂＡＰＩ提供者００３に係るＩＳＭＳ認証の業務スコープ範囲内であるか否かの判定を要求する。

ステップ５０９において、ＩＳＭＳ認証サーバ１０５は、認証サーバ１０４からの要求を受け、対象のＷｅｂＡＰＩがＩＳＭＳ認証の業務スコープ範囲内であるか否かを判定し、認証サーバ１０４に対して、判定結果を送信する。この判定結果の送信方法は、ＩＳＭＳ認証文書のＰＤＦファイルを電子メールで送信する方法、ＩＳＭＳ認証文書を表示するＷｅｂページへのＵＲＬを電子メールで送信する方法などが挙げられる。
以上で、図５の説明を終了する。
図６は、クラウドセキュリティ認証処理２の一例を示す図である。

ステップ６０１において、認証サーバ１０４は、ＩＳＭＳ認証サーバ１０５から送信された判定結果を受信し、ＷｅｂＡＰＩサーバ１０３から認証を申請されたＷｅｂＡＰＩがＩＳＭＳ認証の登録範囲内であることを確認する。

ステップ６０２において、認証サーバ１０４は、ＷｅｂＡＰＩサーバ１０３から認証を申請されたＷｅｂＡＰＩがＩＳＭＳ認証の登録範囲内である場合、ＷｅｂＡＰＩサーバ１０３から申請されたＷｅｂＡＰＩ認証情報を、図１９のＷｅｂＡＰＩ提供者テーブル１９１０、ＩＳＭＳ認証テーブル１９２０に登録する。具体的な登録方法としては、認証サーバ１０４は、ディスプレイ装置２１０にＷｅｂＡＰＩ認証情報登録画面１８００（図１８）を表示し、クラウドセキュリティ認証局００４の操作によって、ＷｅｂＡＰＩ認証情報登録画面１８００に入力された情報をＷｅｂＡＰＩ提供者テーブル１９１０、ＩＳＭＳ認証テーブル１９２０に登録する。

図１８は認証サーバ１０４におけるＷｅｂＡＰＩ認証情報登録画面の一例を示す図、図１９は認証サーバ１０４において管理するテーブルの一例を示す図である。ＷｅｂＡＰＩ提供者テーブル１９１０では認証を申請してきたＷｅｂＡＰＩ提供者の情報を、ＩＳＭＳ認証テーブル１９２０では、認証申請の対象となるＷｅｂＡＰＩの情報を管理する。例えば、ある会社がＷｅｂＡＰＩを提供する場合、ＷｅｂＡＰＩの登録数は必ずしも会社で１つに限定されるものではなく、事業毎にＷｅｂＡＰＩを登録することがある。よって、ＩＳＭＳ認証テーブル１９２０は、会社毎に１レコードとするのではなく、ＩＳＯ２７００１の登録範囲であるＷｅｂＡＰＩ毎に１レコードとして管理する。つまり、ＩＳＭＳ認証テーブル１９２０は、ＷｅｂＡＰＩ名を主キーとする。

なお、この実施形態においては、ＩＳＭＳ認証テーブル１９２０はＷｅｂＡＰＩ名を主キーとしＷｅｂＡＰＩ毎に１レコードとして管理するとしたが、これに限定するものではなく、例えば、ＩＳＯ２７００１の登録範囲である複数のＷｅｂＡＰＩをＷｅｂＡＰＩ群としてまとめ、そのＷｅｂＡＰＩ群名を主キーとしＷｅｂＡＰＩ群毎に１レコードとして管理してもよい。
図９は、ＷｅｂＡＰＩ認証情報登録処理の一例を示すフローチャートである。以下、図９について説明する。

ステップＳ９０１において、認証サーバ１０４は、クラウドセキュリティ認証局００４によってＷｅｂＡＰＩ認証情報登録画面１８００（図１８）に入力された、ＷｅｂＡＰＩ提供者に関する情報を取得し、ＷｅｂＡＰＩ提供者テーブル１９１０に記憶する。具体的には、「ＷｅｂＡＰＩ提供会社ＩＤ」「ＷｅｂＡＰＩ提供会社名」「ＷｅｂＡＰＩ提供会社代表部門名」「代表部門担当者名」「代表部門担当者連絡先」を取得し、ＷｅｂＡＰＩ提供者テーブル１９１０に記憶する。

また、認証サーバ１０４は、クラウドセキュリティ認証局００４によってＷｅｂＡＰＩ認証情報登録画面１８００（図１８）に入力された、ＷｅｂＡＰＩ認証情報を取得し、ＩＳＭＳ認証テーブル１９２０に記憶する。具体的には、「ＷｅｂＡＰＩ名」「認証機関名」「認証基準」「所在地」「組織名」「部門名」「初回登録日」「有効期限」「登録範囲」「認証登録番号」「ＷｅｂＡＰＩの公開鍵１３１」を取得し、ＩＳＭＳ認証テーブル１９２０に記憶する。

ステップＳ９０２において、認証サーバ１０４は、ステップＳ９０２にて取得した、ＷｅｂＡＰＩ認証情報をハッシュ化し、得られたハッシュ値をＲＡＭ２０２に記憶する。本実施形態においては、ハッシュ化する情報を「認証機関名」「認証基準」「所在地」「組織名」「部門名」「初回登録日」「有効期限」「登録範囲」「認証登録番号」「ＷｅｂＡＰＩ名」「ＷｅｂＡＰＩの公開鍵１３１」としたが、これらに限定するものではなく、ＷｅｂＡＰＩ毎にユニークなハッシュ値が生成されるのであれば、その他の情報を含めても、これらから一部の情報を除外してもよい。
以上で、図９の説明を終了する。

次に、ステップ６０３において、認証サーバ１０４は、ＷｅｂＡＰＩ提供者電子証明書を生成する。図２０は、ＷｅｂＡＰＩ認証情報の一例を示す図である。２００１〜２０１０は、ＷｅｂＡＰＩ提供者００３がＩＳＯ２７００１の認証を取得すれば、その認証に関する文書から確認できる情報である。２０１１は、図５のステップ５０７にて、クラウドセキュリティ認証局００４がＷｅｂＡＰＩ提供者００３から受信した、ＷｅｂＡＰＩの公開鍵１３１である。２０１２は、図９のＳ９０２において算出したハッシュ値である。
具体的には、図１０のＷｅｂＡＰＩ提供者電子証明書生成処理の一例を示すフローチャートを用いて説明する。

ステップＳ１００１において、認証サーバ１０４は、ステップＳ９０１およびステップＳ９０２にて取得したＷｅｂＡＰＩ認証情報をＲＡＭ２０２から取得し、クラウドセキュリティ認証局の秘密鍵１４２を用いて暗号化する。

ステップＳ１００２において、認証サーバ１０４は、ステップＳ１００１にて暗号化したＷｅｂＡＰＩ認証情報を用いて、ＷｅｂＡＰＩ提供者電子証明書を生成する。具体的には、ＷｅｂＡＰＩ提供者電子証明書には、暗号化していないＷｅｂＡＰＩ認証情報、暗号化したＷｅｂＡＰＩ認証情報、ＷｅｂＡＰＩの公開鍵１３１が含まれる。

ステップＳ１００３において、認証サーバ１０４は、ＷｅｂＡＰＩ名を検索キーとしてＩＳＭＳ認証テーブル１９２０を検索し、ステップＳ１００２にて生成されたＷｅｂＡＰＩ提供者電子証明書を登録する。
以上で、図１０の説明を終了する。

ステップ６０４において、認証サーバ１０４は、ステップ６０３にて生成されたＷｅｂＡＰＩ提供者電子証明書をＷｅｂＡＰＩサーバ１０３に送信する。なお、ＷｅｂＡＰＩ提供者電子証明書は、ＷｅｂＡＰＩ提供者００３にとって重要な情報であるため、ＷｅｂＡＰＩ提供者電子証明書にパスワードをかけて電子メールで送信するなど、セキュアな方法で送信する。

ステップ６０５において、ＷｅｂＡＰＩサーバ１０３は、認証サーバ１０４から受信したＷｅｂＡＰＩ提供者電子証明書を外部メモリ２１１に記憶する。具体的には、図１１のＷｅｂＡＰＩ提供者電子証明書登録処理の一例を示すフローチャートを用いて説明する。

ステップＳ１１０１において、ＷｅｂＡＰＩサーバ１０３は、認証サーバ１０４から受信したＷｅｂＡＰＩ提供者電子証明書を外部メモリ２１１に記憶する。このステップの具体的な方法としては、ＷｅｂＡＰＩサーバ１０３において用意されている、電子証明書登録用のコマンドや電子証明書登録画面（不図示）等を用いて、外部メモリ２１１に登録する。
以上で、図１１、図６の説明を終了する。

図７は、クラウドセキュリティ認証処理３の一例を示す図である。図２１は、ＳａａＳサーバ１０２において管理するＷｅｂＡＰＩリストの一例を示す図である。実際にＷｅｂＡＰＩを呼び出すために必要な、ＵＲＬや、その形式、呼び出しに必要なＩＤ、パスワードなどがＳａａＳのサービスの中で利用される。以下、図７について説明する。

ステップ７０１において、ＳａａＳサーバ１０２は、ＷｅｂＡＰＩ提供者００３からＷｅｂＡＰＩの提供を受ける前に、ＷｅｂＡＰＩ利用者００２の操作に基づき、提供するＷｅｂサービスにおいて利用するＷｅｂＡＰＩが認証を受けている認証サーバ１０４に対して、クラウドセキュリティ認証局電子証明書の要求を行う。要求の具体的な方法としては、認証サーバ１０４に対し、ＨＴＴＰプロトコルのＲｅｑｕｅｓｔ電文や、電子メールなどを送信して、クラウドセキュリティ認証局電子証明書を要求する。

なお、この実施形態においては、クラウドセキュリティ認証局００４および認証サーバ１０４はそれぞれ１つとしたが、今後、クラウドセキュリティ認証局００４が世界中に複数局設置されることも考えられ、ＷｅｂＡＰＩ毎に認証を担当したクラウドセキュリティ認証局が異なることが考えられる。その場合、ＷｅｂＡＰＩ利用者００２は、利用するＷｅｂＡＰＩの認証がどのクラウドセキュリティ認証局で行われたのかについて、ＷｅｂＡＰＩ提供者００３から情報を入手し、ステップ７０１にて、利用するＷｅｂＡＰＩの認証が行われたクラウドセキュリティ認証局の認証サーバ１０４に対して、クラウドセキュリティ認証局電子証明書の要求を行う。

なお、その際、ＳａａＳサーバ１０２は、提供するＷｅｂサービスで利用するＷｅｂＡＰＩのリストを、ＳａａＳサーバ１０２の外部メモリ２１１上の利用ＷｅｂＡＰＩテーブル２１００（図２１）として記憶する。すなわち、利用ＷｅｂＡＰＩテーブル２１００は、アプリケーションサーバで利用されるＡＰＩ識別情報を記憶する手段の一例を示すステップである。具体的には、利用ＷｅｂＡＰＩテーブル２１００に、「ＷｅｂＡＰＩ名」「提供会社名」「ＵＲＬ」「形式」「ＩＤ」「ＰＡＳＳＷＯＲＤ」を登録しておく。また、この時点では、「認証結果」「利用可否」カラムはＮＵＬＬである。この２つのカラムについては、後ほど説明する。

なお、利用ＷｅｂＡＰＩテーブル２１００は、ＳａａＳサーバ１０２で動作するアプリケーションのソースファイルや設定ファイルを検索して、ＳａａＳサーバ１０２が自動で作成するとしてもよいし、ＷｅｂＡＰＩ利用者００２の操作に基づいて、ＳａａＳサーバ１０２が作成するとしてもよい。

なお、本実施形態においては、Ｗｅｂサービスで利用するＷｅｂＡＰＩのリストを利用ＷｅｂＡＰＩテーブル２１００に登録しておくとしたが、この方法に限定するものではなく、Ｗｅｂサービスで利用するＷｅｂＡＰＩのリストをアプリケーションサーバにおけるｗｅｂ．ｘｍｌファイルのような設定ファイルに「ＷｅｂＡＰＩ名」「提供会社名」「ＵＲＬ」「形式」「ＩＤ」「ＰＡＳＳＷＯＲＤ」「認証結果」「利用可否」の値を記憶するとしてもよい。
ステップ７０２において、認証サーバ１０４は、ＳａａＳサーバ１０２からの送信された、クラウドセキュリティ認証局電子証明書の要求を受信する。

ステップ７０３において、認証サーバ１０４は、外部メモリ２１１に記憶されたクラウドセキュリティ認証局電子証明書を取得し、ＳａａＳサーバ１０２に送信する。この送付方法については、クラウドセキュリティ認証局電子証明書にパスワードをかけて電子メールで送信する、ＳＳＬなどのセキュアな通信によってクラウドセキュリティ認証局電子証明書を送信する、パスワードが必要なＷｅｂサイトのＵＲＬを電子メールで通知し、ＷｅｂＡＰＩ利用者００２にダウンロードさせるなどの方法等がある。

ステップ７０４において、ＳａａＳサーバ１０２は、クラウドセキュリティ認証局００４から送付されたクラウドセキュリティ認証局電子証明書を受信し、ＳａａＳサーバ１０２の利用ＷｅｂＡＰＩテーブル２１００に記憶する。具体的には、図１２のクラウドセキュリティ認証局電子証明書取得処理のフローチャートを用いて説明する。

ステップＳ１２０１において、ＳａａＳサーバ１０２は、ＷｅｂＡＰＩ名を検索キーとして利用ＷｅｂＡＰＩテーブル２１００を検索し、クラウドセキュリティ認証局電子証明書を登録する。この登録の具体的な方法としては、ＳａａＳサーバ１０２において用意されている、電子証明書登録コマンドや電子証明書登録画面（不図示）等を用いて登録する。
以上で、図１２、図７の説明を終了する。
図８は、クラウドセキュリティ認証処理４の一例を示す図である。以下、図８について説明する。

ステップ８０１において、ＳａａＳサーバ１０２は、提供するＷｅｂサービスを起動する。なお、Ｗｅｂサービスの起動方法は、ＳａａＳサーバ１０２のＯＳが起動した際に自動でＷｅｂサービスを起動する方法、ＷｅｂＡＰＩ利用者００２の操作に基づいて起動する方法、ＷｅｂＡＰＩ利用者００２によって事前に設定されたタイマーやバッチによって起動する、としてもよい。

ステップ８０２において、ＳａａＳサーバ１０２は、Ｗｅｂサービスの起動するにあたって、ＳａａＳマネジメントコンソールを起動し、Ｗｅｂサービスで利用するＷｅｂＡＰＩがＩＳＭＳ認証の登録範囲内であるか否かをディスプレイ装置２１０に表示する。本実施形態においては、Ｗｅｂサービスの起動に応じて、ＳａａＳマネジメントコンソールを起動するとしたが、Ｗｅｂサービスの起動とは無関係に、ＷｅｂＡＰＩ利用者００２がコマンドや実行ファイルによりＳａａＳマネジメントコンソールを起動するとしてもよい。また、バッチなどによりＳａａＳマネジメントコンソールを定期的に起動し、ＷｅｂＡＰＩの認証結果をＷｅｂＡＰＩ利用者００２にメール通知する方法をとってもよい。

ＳａａＳマネジメントコンソールは、ＷｅｂＡＰＩ提供者００３のＷｅｂＡＰＩ電子証明書を要求して、その結果を取得する。つまり、ＳａａＳサーバ１０２から、ＷｅｂＡＰＩサーバ１０３へＲｅｑｕｅｓｔ電文を送信し、ＷｅｂＡＰＩ電子証明書を含むＲｅｓｐｏｎｓｅ電文を受信する。

つまり、ＳａａＳサーバ１０２は、ＳａａＳマネジメントコンソールにＷｅｂＡＰＩ提供者００３のＷｅｂＡＰＩ電子証明書認証の確認結果を表示する。このＳａａＳマネジメントコンソールに関するフローを図１３、図１４、図１５、図１６に示す。つまり、図１３から図１６の処理を行うことによって、ＳａａＳマネジメントコンソール画面２２００が表示される。

また、図２２は、ＳａａＳサーバ１０２が出力するＳａａＳマネジメントコンソール画面２２００の一例を示す図である。２２０１〜２２０３にはＷｅｂサービスで利用するＷｅｂＡＰＩの名称を、２２１１〜２２１３には認証結果、２２２２〜２２２３には認証エラーになったＷｅｂＡＰＩの利用可否を決定するチェックボックスを表示する。
図１３はＳａａＳマネジメントコンソールに係る処理の一例を示すフローチャートを示す図である。以下、図１３について説明する。

ステップＳ１３０１において、ＳａａＳサーバ１０２は、提供するＷｅｂサービスで利用するＷｅｂＡＰＩのリストを取得する。具体的には、図１４のＷｅｂＡＰＩリスト取得処理の一例を示すフローチャートを用いて説明する。
ステップＳ１４０１において、ＳａａＳサーバ１０２は、変数ｎに１を代入する。

ステップＳ１４０２において、ＳａａＳサーバ１０２は、提供するＷｅｂサービスで利用するＷｅｂＡＰＩのリストを利用ＷｅｂＡＰＩテーブル２１００からｎ件目のＷｅｂＡＰＩレコードを取得する。具体的には、「ＵＲＬ」「形式」「ＩＤ」「ＰＡＳＳＷＯＲＤ」の値を取得する。

ステップＳ１４０３において、ＳａａＳサーバ１０２は、ｎ件目のＷｅｂＡＰＩレコードの有無を判定し、無の場合（ｎ件目のＷｅｂＡＰＩレコードが取得できなかった場合）、ステップＳ１３０１のＷｅｂＡＰＩリスト取得処理を終了する。有の場合（ｎ件目のＷｅｂＡＰＩレコードが取得できた場合）、ステップＳ１４０４に進む。

ステップＳ１４０４において、ＳａａＳサーバ１０２は、配列ＷｅｂＡＰＩ（ｎ）に取得したｉ件目のＷｅｂＡＰＩレコードを代入し、ＲＡＭ２０２に記憶する。
ステップＳ１４０５において、ＳａａＳサーバ１０２は、変数ｎの値を１インクリメントし、ステップＳ１４０２に戻る。
以上で、図１４の説明を終了する。

ステップＳ１３０２において、ＳａａＳサーバ１０２は、利用するＷｅｂＡＰＩに係る認証を確認する。具体的には、図１５の認証確認処理の一例を示すフローチャートを用いて説明する。

ステップＳ１５０１において、ＳａａＳサーバ１０２は、変数ｉに１を代入し、ＷｅｂＡＰＩ利用個数分だけステップＳ１５０２〜ステップＳ１５１３をループする。
ステップＳ１５０２において、ＳａａＳサーバ１０２は、変数エラーフラグに０を設定する。

ステップＳ１５０３において、ＳａａＳサーバ１０２は、ＷｅｂＡＰＩサーバ１０３に対して、ＷｅｂＡＰＩ提供者電子証明書を要求し、ＷｅｂＡＰＩサーバ１０３はＷｅｂＡＰＩ提供者電子証明書を送信する（図８の８０３）。具体的には、ＳａａＳサーバ１０２は、ステップＳ１４０４にてＲＡＭ２０２に記憶した「形式」「ＩＤ」「ＰＡＳＳＷＯＲＤ」を用いてＷｅｂＡＰＩ提供者電子証明書を取得するための認証情報を作成し、ＷｅｂＡＰＩサーバ１０３の「ＵＲＬ」に対して、作成した認証情報を送信する（図８の８０２から８０３へのＲｅｑｕｅｓｔ）。その認証情報を受信したＷｅｂＡＰＩサーバ１０３は、認証情報が正しい場合、ＳａａＳサーバ１０２に対して、ＷｅｂＡＰＩ提供者電子証明書を送信する（図８の８０３から８０２へのＲｅｓｐｏｎｓｅ）。

ステップＳ１５０４において、ＳａａＳサーバ１０２は、ＷｅｂＡＰＩサーバ１０３から送信されたＷｅｂＡＰＩ提供者ＷｅｂＡＰＩ電子証明書を受信し、ＷｅｂＡＰＩ提供者ＷｅｂＡＰＩ電子証明書を取得できたか否かを判定する。すなわち、ステップＳ１５０３、ステップＳ１５０４は、記憶されたＡＰＩ識別情報を用いて、認証サーバからＡＰＩの認証情報を取得する処理の一例を示すステップである。取得できなかった場合は、ステップＳ１５０５に進み、取得できた場合は、ステップＳ１５０６に進む。
ステップＳ１５０５において、ＳａａＳサーバ１０２は、変数エラーフラグに１を設定し、ステップＳ１５１３に進む。

ステップＳ１５０６において、ＳａａＳサーバ１０２は、ステップ７０４にて取得したクラウドセキュリティ認証局電子証明書からクラウドセキュリティ認証局の公開鍵１４１を取得する。すなわち、ステップＳ１５０６は、認証サーバが持つ公開鍵を取得する処理の一例を示すステップである。

ステップＳ１５０７において、ＳａａＳサーバ１０２は、ステップＳ１５０６にて取得したクラウドセキュリティ認証局の公開鍵１４１を用いて、ステップＳ１５０４にて取得したＷｅｂＡＰＩ提供者電子証明書を復号化する。

ステップＳ１５０８において、ＳａａＳサーバ１０２は、復号化されたＷｅｂＡＰＩ提供者電子証明書に含まれる「認証機関名２００１」「認証基準２００２」「所在地２００３」「組織名２００４」「部門名２００５」「初回登録日２００６」「有効期限２００７」「登録範囲２００８」「認証登録番号２００９」「公開鍵２０１０」をハッシュ化し、算出されたハッシュ値をＲＡＭ２０２に記憶する。

ステップＳ１５０９において、ＳａａＳサーバ１０２は、ステップＳ１５０７にて復号化されたＷｅｂＡＰＩ提供者電子証明書に含まれている「ハッシュ値２０１２」が、ステップＳ１５０８にてＲＡＭ２０２に記憶されたハッシュ値と同じ値か否かを判定する。異なる値の場合は、ステップＳ１５１０に進み、同じ値の場合は、ステップＳ１５１１に進む。すなわち、ステップＳ１５０９は、取得した認証情報（例えば、ハッシュ値）に基づいて、そのＡＰＩが認証サーバにおいて認証されているか否かを判定する処理の一例を示すステップである。また、ステップＳ１５０７〜Ｓ１５０９は、公開鍵を用いて、ＡＰＩが認証サーバにおいて認証されているか否かを判定する処理の一例を示すステップである。なお、本実施形態ではハッシュ値を用いて説明したが、改竄されていないことが特定できれば、ハッシュ値に限ることはない。
ステップＳ１５１０において、ＳａａＳサーバ１０２は、変数エラーフラグに２を設定する。

ステップＳ１５１１において、ＳａａＳサーバ１０２は、現在日付がステップＳ１５０７にて復号化されたＷｅｂＡＰＩ提供者電子証明書に含まれる「有効期限２００７」の範囲内にあるか否かを判定する。範囲外の場合は、ステップＳ１５１２に進み、範囲内の場合は、ステップＳ１５１３に進む。すなわち、ステップＳ１５１１は、有効期限が切れているか否かを判定する処理の一例を示すステップである。
ステップＳ１５１２において、ＳａａＳサーバ１０２は、変数エラーフラグに３を設定する。

ステップＳ１５１３において、ＳａａＳサーバ１０２は、配列 認証結果のｉ番目の値として、エラーフラグの値を設定する。また、このエラーフラグの値を、Ｗｅｂサービスの「ＷｅｂＡＰＩ名」を検索キーにして、利用ＷｅｂＡＰＩテーブル２１００を検索し、「認証結果」の値として更新する。これにより、ＳａａＳマネジメントコンソールの画面を終了後も、各ＷｅｂＡＰＩの認証結果を保持することができる。これにより、ＷｅｂＡＰＩ利用者００２は、ＳａａＳマネジメントコンソールを起動した時だけでなく、利用ＷｅｂＡＰＩテーブル２１００を確認することで、利用するＷｅｂＡＰＩの認証状況を確認することができる。

ステップＳ１５１４において、ＳａａＳサーバ１０２は、変数ｉの値を１インクリメントし、変数ｉの値がＷｅｂＡＰＩ利用個数を超えない場合は、ステップＳ１５０２に戻り、超えた場合は、図１５の認証確認処理の一例を示すフローチャートを終了する。
以上で、図１５の説明を終了する。

ステップＳ１３０３において、ＳａａＳサーバ１０２は、ＳａａＳマネジメントコンソールにＷｅｂサービスで利用するＷｅｂＡＰＩのリストを表示する。具体的には、図１６のＷｅｂＡＰＩリスト表示処理の一例を示すフローチャートを用いて説明する。

ステップＳ１６０１において、ＳａａＳサーバ１０２は、変数ｉに１を代入し、ＷｅｂＡＰＩ利用個数分だけステップＳ１６０２〜ステップＳ１６０６をループする。

ステップＳ１６０２において、ＳａａＳサーバ１０２は、配列 認証結果のｉ番目の値を取得し、値が０の場合はステップＳ１６０３に進み、値が１の場合はステップＳ１６０４に進み、値が２の場合はステップＳ１６０５に進み、値が３の場合はステップＳ１６０６に進む。

ステップＳ１６０３において、ＳａａＳサーバ１０２は、ディスプレイ装置２１０にＷｅｂＡＰＩ名と「認証ＯＫ」のメッセージを表示する。（図２２の２２０１と２２１１）

ステップＳ１６０４において、ＳａａＳサーバ１０２は、ディスプレイ装置２１０にＷｅｂＡＰＩ名と「電子証明書を取得できませんでした」のメッセージを表示する（不図示）。また、メッセージの右には、利用可否チェックボックスを表示する。

ステップＳ１６０５において、ＳａａＳサーバ１０２は、ディスプレイ装置２１０にＷｅｂＡＰＩ名と「電子証明書が不正です」のメッセージを表示する（図２２の２２０２と２２１２）。また、メッセージの右には、利用可否チェックボックス２２２２を表示する。

ステップＳ１６０６において、ＳａａＳサーバ１０２は、ディスプレイ装置２１０にＷｅｂＡＰＩ名と「有効期限が切れています」のメッセージを表示する（図２２の２２０３と２２１３）。また、メッセージの右には、利用可否チェックボックス２２２３を表示する。すなわち、ステップＳ１６０４〜ステップＳ１６０６は、取得した認証情報を用いて、認証されているＡＰＩと認証されていないＡＰＩとを識別可能に通知する処理の一例を示すステップである。

ステップＳ１６０７において、ＳａａＳサーバ１０２は、変数ｉの値を１インクリメントし、変数ｉの値がＷｅｂＡＰＩ利用個数を超えない場合は、ステップＳ１６０２に戻り、超えた場合は、図１６のＷｅｂＡＰＩリスト表示処理を終了する。

本実施形態においては、ＳａａＳマネジメントコンソール（図２２）をディスプレイ装置２１０に表示することで、ＷｅｂＡＰＩの認証結果をＷｅｂＡＰＩ利用者００２に通知するとしたが、メールや運用監視のアラート等による通知であってもよい。言い換えれば、ＷｅｂＡＰＩ利用者００２がＷｅｂＡＰＩの認証結果を識別可能にする方法であればよい。

また、本実施形態においては、認証結果を０〜３の４種類としたが、これに限定するものではなく、より少なくても多くてもよい。当然、多い方が、認証エラー発生後、ＷｅｂＡＰＩ提供者００３への問い合わせする際において問題の切分けを迅速に行うことが可能になる。
以上により、インターネット上で提供されるＡＰＩの認証に従って、アプリケーションの実行を適切に制御する仕組みを提供することができる。

ステップＳ１３０４において、ＳａａＳサーバ１０２は、配列 認証結果の値がすべて０の場合は、ステップＳ１３０７に進み、０以外の値がある場合は、認証エラーのＷｅｂＡＰＩが存在するため、ステップＳ１３０５に進む。つまり、利用するＡＰＩの認証がすべて正常に行われた場合は、ステップＳ１３０５のダイアログ２２３０を表示することなく、自動的にＷｅｂサービスの実行が開始される。

ステップＳ１３０５において、ＳａａＳサーバ１０２は、ディスプレイ装置２１０にＷｅｂサービスの提供を行うか否かを判断するダイアログ２２３０を表示する。すなわち、ステップＳ１３０５は、アプリケーションの実行の可否を判定する処理の一例を示すステップである。なお、バッチによりＳａａＳマネジメントコンソールを起動する場合、ダイアログ２２３０を表示するのではなく、認証エラーが発生した場合、Ｗｅｂサービスを実行するか否か、認証エラーが発生したＷｅｂＡＰＩを利用するか否かについて、ＷｅｂＡＰＩ利用者００２が設定ファイルなどに「利用可否フラグ」として設定しておき、ステップＳ１３０５において、「利用可否フラグ」を参照することで、Ｗｅｂサービスの実行の可否、認証エラーが発生したＷｅｂＡＰＩの利用可否を決定するとしてもよい。

ステップＳ１３０６において、ＳａａＳサーバ１０２は、ダイアログ２２３０のボタン押下を受け付け、はいボタン２２３１が押下された場合は、ステップＳ１３０７に進み、いいえボタン２２３２が押下された場合は、図１３のＳａａＳマネジメントコンソールに係る処理を終了する。

すなわち、ステップＳ１３０６は、ＡＰＩが認証されていると判定された場合、アプリケーションを実行させるように制御し、ＡＰＩが認証されていないと判定された場合、アプリケーションの実行を抑止させるように制御する処理の一例を示すステップである。

例えば、図２２において、ＷｅｂＡＰＩ Ａ２２０１、ＷｅｂＡＰＩ Ｂ２２０２およびＷｅｂＡＰＩ Ｃ２２０３が認証されている場合に、アプリケーション（Ｗｅｂサービス）を実行するよう制御することが、「ＡＰＩが認証されていると判定された場合、アプリケーションを実行させるように制御する処理」の一例であり、ＷｅｂＡＰＩ Ａ２２０１、ＷｅｂＡＰＩ Ｂ２２０２またはＷｅｂＡＰＩ Ｃ２２０３のうち認証されていないＷｅｂＡＰＩが存在する場合、アプリケーションの実行を抑止するよう制御することが、「ＡＰＩが認証されていないと判定された場合、アプリケーションの実行を抑止させるように制御する処理」の一例である。

また、ステップＳ１３０６は、アプリケーションの実行の可否を判定する処理の一例を示すステップである。また、ステップＳ１３０６は、ＡＰＩの利用可否を判定する処理の一例を示すステップである。また、ステップＳ１３０６は、ＡＰＩを利用すると判定された場合、ＡＰＩを利用して前記アプリケーションを実行させるように制御し、ＡＰＩを利用しないと判定された場合、ＡＰＩを利用せずに前記アプリケーションを実行させるように制御する処理の一例を示すステップである。

つまり、図２２のように、利用可否チェックボックス２２２２がチェックされているＷｅｂＡＰＩ Ｃ２２０３を利用してアプリケーション（Ｗｅｂサービス）を実行することが、「ＡＰＩを利用すると判定された場合、前記ＡＰＩを利用してアプリケーションを実行させるように制御する処理」の一例であり、利用可否チェックボックス２２２２がチェックされているＷｅｂＡＰＩ Ｂ２２０２を利用せずにアプリケーションを実行することが、「ＡＰＩを利用しないと判定された場合、ＡＰＩを利用せずにアプリケーションを実行させるように制御する処理」の一例である。

以上により、認証されていないＷｅｂＡＰＩが存在する場合は、ダイアログを表示し、Ｗｅｂサービスの実行を抑止させるように制御することができるため、Ｗｅｂサービスのセキュリティを確保することができる。

ステップＳ１３０７において、ＳａａＳサーバ１０２は、利用可否チェックボックス（図２２の２２２２と２２２３）の値を、利用ＷｅｂＡＰＩテーブル２１００の「利用可否」の値として登録する。具体的には、Ｗｅｂサービスの「ＷｅｂＡＰＩ名」を検索キーにして、利用ＷｅｂＡＰＩテーブル２１００を検索し「利用可否」の値を、利用可否チェックボックスがチェックされている場合は「ＯＫ」、チェックされていない場合は「ＮＧ」に更新する。なお、認証が正常に行われたＷｅｂＡＰＩ（例えば、ＷｅｂＡＰＩ Ａ）については、「利用可否」の値を「ＯＫ」に更新する。

これにより、ＷｅｂＡＰＩ利用者００２（つまり、ＳａａＳ（Ｗｅｂサービス）提供者）の判断によって、認証エラーのＷｅｂＡＰＩの利用を個々に設定することが可能になる。例えば、図２２の２２２３は、ＷｅｂＡＰＩ利用者００２が、認証エラー「有効期限が切れています」であるＷｅｂＡＰＩ Ｃを利用すると判断した、ということである。つまり、有効期限が切れているＡＰＩであった場合、そのＡＰＩを利用できなくするのではなく、ＷｅｂＡＰＩ利用者００２の判断によって、そのＡＰＩを利用することができる。すなわち、ステップＳ１３０７は、有効期限が切れているＡＰＩが存在すると判定した場合であっても、そのＡＰＩを利用してアプリケーションを実行させるように制御する処理の一例を示すステップである。

以上により、認証されていないＷｅｂＡＰＩが存在する場合においても、ＷｅｂＡＰＩ毎に利用可否を設定することができるため、Ｗｅｂサービスの実行について、柔軟性を持った制御を行うことができる。具体的には、不動産情報検索Ｗｅｂサイトにおいて、地図表示ＡＰＩの認証有効期限が切れている場合も、Ｗｅｂサイト運営会社は、地図表示ＡＰＩの利用可否チェックボックスをチェックすることで、地図表示ＡＰＩを引き続き利用し、エンドユーザに地図表示のサービスを提供することもできる。また、地図表示ＡＰＩの利用可否チェックボックスのチェックを外すことで、地図表示ＡＰＩを利用せず、エンドユーザに地図表示のサービスを提供しないようにすることができる。なお、地図表示ＡＰＩを利用しない場合は、不動産情報検索Ｗｅｂサイトにおいては、地図表示ＡＰＩを利用する情報を提供することができないため、地図表示ボタンをクリックできないように無効化したり（不図示）、地図表示エリアに「現在、地図表示サービスは停止しております。」などのメッセージを表示したりする（不図示）などの対応が必要になる。

ステップＳ１３０８において、ＳａａＳサーバ１０２は、Ｗｅｂサービスを実行する（図８の８０４）。具体的には、図１７のＷｅｂサービス実行処理の一例を示すフローチャートを用いて説明する。

ステップＳ１７０１において、ＳａａＳサーバ１０２は、Ｗｅｂサービスを起動する。具体的には、Ｗｅｂサービスを実行するために必要な初期処理を実行する。なお、本実施形態においては、ステップＳ１３０４のＷｅｂＡＰＩ認証を確認し、Ｗｅｂサービスの提供開始を決定した後に、ステップＳ１７０１にてＷｅｂサービスを起動するとしたが、この処理順序に限定するものではなく、例えば、ステップＳ１３０１の前にＷｅｂサービスを起動しておき、ＷｅｂＡＰＩの認証に従って、利用するＷｅｂＡＰＩを制限する処理順序としてもよい。

ステップＳ１７０２において、ＳａａＳサーバ１０２は、Ｗｅｂサービス利用者００１が利用する情報処理装置１０１から送信されたＲｅｑｕｅｓｔ電文を受信する（図８の８０６）。

ステップＳ１７０３において、ＳａａＳサーバ１０２は、受信したＲｅｑｕｅｓｔ電文を解析し、どのＷｅｂＡＰＩを利用するＲｅｑｕｅｓｔかを特定する。このステップにより、利用するＷｅｂＡＰＩの識別情報（本実施形態においては、ＷｅｂＡＰＩ名）が特定できたとする。なお、本実施形態においては、受信したＲｅｑｕｅｓｔ電文から利用するＷｅｂＡＰＩを特定するとしたが、この方法に限定するものではなく、ＲｅｑｕｅｓｔのＵＲＬによってＷｅｂＡＰＩを特定する方法、Ｒｅｑｕｅｓｔ電文に含まれる引数の値でＷｅｂＡＰＩを特定する方法、ＨＴＴＰセッションやクッキーに含まれる値でＷｅｂＡＰＩを特定する方法、アクセスするＷｅｂページの識別情報によってＷｅｂＡＰＩを特定する方法などの方法であってもよい。

ステップＳ１７０４において、ＳａａＳサーバ１０２は、特定したＷｅｂサービスの「ＷｅｂＡＰＩ名」を検索キーにして、利用ＷｅｂＡＰＩテーブル２１００を検索し、「ＵＲＬ」「形式」「ＩＤ」「ＰＡＳＳＷＯＲＤ」「利用可否」を取得し、ＲＡＭ２０２に記憶する。

ステップＳ１７０５において、ＳａａＳサーバ１０２は、取得した「利用可否」の値がＯＫの場合はステップＳ１７０６に進み、ＮＧの場合はステップＳ１７０９に進む。

なお、「利用可否」の値がＮＧのＷｅｂＡＰＩについては、ステップＳ１７０９に進み、ＷｅｂＡＰＩは実行されないため、利用者側の端末では、このＷｅｂＡＰＩに対応する実行結果画面の全体またはその一部について表示がされないように構成される（図２６の２６２０）。

なお、実行結果画面には、「セキュリティを維持するため現在サービス停止中」など、Ｗｅｂサービスの一部が実行できない旨を表示させるようにすることで、よりセキュリティ（ＩＳＯ２７０１７）に準拠したシステムを提供することが可能となる。

なお、本実施形態においては、「利用可否」により対象のＷｅｂＡＰＩの利用を制御するとしたが、「認証結果」に従って対象のＷｅｂＡＰＩの利用を制御するとしてもよい。具体的には、ステップＳ１７０４において、「認証結果」が“０”の場合は認証ＯＫのためステップＳ１７０６に進み、対象のＷｅｂＡＰＩを利用し、「認証結果」が“０”以外の場合は認証エラーのためステップＳ１７０９に進み、対象のＷｅｂＡＰＩを利用しないとする。なお、「認証結果」によってＷｅｂＡＰＩの利用を制御すると、認証エラーの場合は利用が不可能になってしまうため、「利用可否」によってＷｅｂＡＰＩの利用を制御する方が、より柔軟性を持ったＷｅｂサービスの実行が可能になる。

ステップＳ１７０６において、ＳａａＳサーバ１０２は、ステップＳ１７０４にてＲＡＭ２０２に記憶した「ＵＲＬ」に対して、ステップＳ１７０４にてＲＡＭ２０２に記憶した「形式」に則って、ＷｅｂＡＰＩへのＲｅｑｕｅｓｔ電文を送信する。また、Ｒｅｑｕｅｓｔ電文には、ステップＳ１７０４にてＲＡＭ２０２に記憶した「ＩＤ」「ＰＡＳＳＷＯＲＤ」を含めるとしてもよい。

なお、この実施形態においては、ＷｅｂＡＰＩを利用するためのＲｅｑｕｅｓｔ電文の送信先「ＵＲＬ」を、ステップＳ１５０３のＷｅｂＡＰＩ提供者電子証明書を取得するためのＲｅｑｕｅｓｔ電文の送信先「ＵＲＬ」と同一としたが、これはあくまで例であって、同一の「ＵＲＬ」に限定するものではない。つまり、ＷｅｂＡＰＩを利用するためのＲｅｑｕｅｓｔ電文の送信先「ＵＲＬ」と、ＷｅｂＡＰＩ提供者電子証明書を取得するためのＲｅｑｕｅｓｔ電文の送信先「ＵＲＬ」とは、異なるＵＲＬであってもよい。

また、ＷｅｂＡＰＩを利用するためのＲｅｑｕｅｓｔ電文の送信先「ＵＲＬ」と、ＷｅｂＡＰＩ提供者電子証明書を取得するためのＲｅｑｕｅｓｔ電文の送信先「ＵＲＬ」とが同一のＵＲＬである場合は、Ｒｅｑｕｅｓｔ電文の中に引数として、ＷｅｂＡＰＩを利用するための引数やＷｅｂＡＰＩ提供者電子証明書を取得するための引数を付加する等によって、どちらのＲｅｑｕｅｓｔ電文かを区別するとしてもよい。

ステップＳ１７０７において、ＷｅｂＡＰＩサーバ１０３は、対応するＷｅｂＡＰＩを実行して、受信したＲｅｑｕｅｓｔ電文を処理し、ＳａａＳサーバ１０２に対して、ＷｅｂＡＰＩ処理結果としてＲｅｓｐｏｎｓｅ電文を送信する。（図８の８０５）
ステップＳ１７０８において、ＳａａＳサーバ１０２は、ＷｅｂＡＰＩサーバ１０３から送信されたＲｅｓｐｏｎｓｅ電文を受信する。

ステップＳ１７０９において、ＳａａＳサーバ１０２は、当該ＷｅｂＡＰＩを利用しない処理を実行する。なお、この処理は、ステップＳ１７０８にて受信したＲｅｓｐｏｎｓｅ電文を利用する場合も、利用しない場合もある。

ステップＳ１７１０において、ＳａａＳサーバ１０２は、情報処理装置１０１に対して、ステップＳ１７０８にて受信したＲｅｓｐｏｎｓｅ電文、およびステップＳ１７０９にて実行した処理結果をＲｅｓｐｏｎｓｅ電文として送信する（図８の８０６）。
以上で、図１７、図１３、図８の説明を終了する。
以上により、インターネット上で提供されるＡＰＩの認証に従って、アプリケーションの実行を適切に制御する仕組みを提供することができる。

なお、本実施形態においては、公開鍵暗号方式を利用し、インターネット上で提供されるＡＰＩの認証を行うとしたが、例えば、公開鍵暗号方式を利用せずに、ＳａａＳサーバ１０２から認証サーバ１０４にＷｅｂＡＰＩ名で認証確認要求を行い、その返信をもってＡＰＩが認証されているとしてもよい。そうすることで、本実施形態よりも、簡易なシステムでＡＰＩの認証を行うことができる。また、その際、認証サーバ１０４は、ＳａａＳサーバ１０２からの認証確認要求をトリガーにして、ＷｅｂＡＰＩサーバ１０３に認証情報を要求して、認証サーバ１０４が認証確認するとしてもよい。

より好適な例として説明した本実施形態のように、公開鍵暗号方式を利用することで、ＷｅｂＡＰＩサーバ１０３が提供するＡＰＩが、認証サーバ１０４が認証したＡＰＩと同一であることを証明することができるため、より強固な認証システムを構築することができるため、より厳重な認証を行うためには、本実施形態のように公開鍵暗号方式のような方式を利用する仕組みであることが求められる。なお、本実施形態では、公開鍵暗号方式を利用するとしたが、公開鍵暗号方式に限定するものではなく、ＷｅｂＡＰＩサーバ１０３が提供するＡＰＩが、認証サーバ１０４が認証したＡＰＩと同一であることを証明することができるのであれば、公開鍵暗号方式でない他の方式を利用してもよい。

以上により、インターネット上で提供されるＡＰＩについて、セキュリティが確保された認証を効率的に行う仕組みを提供することができる。また、これにより、インターネット上で提供されるＡＰＩを利用するアプリケーションについて、セキュリティが確保された状態を効率的に維持する仕組みを提供することができる。

〔第２の実施形態〕
次に、図２３〜図２７を用いて、第２の実施形態について説明する。
なお、第２の実施形態では、第１の実施形態における図１６のフローチャートを図２５に、第１の実施形態における図１７のフローチャートを図２７にそれぞれ置き換え、第１の実施形態のステップと同じ処理については、同じステップ番号を付与し説明を省略する。

図２３は、第２の実施形態に係るＳａａＳサーバ１０２が出力するＳａａＳマネジメントコンソール画面の一例を示す図である。図２４は、第２の実施形態に係るＳａａＳサーバ１０２において管理するＷｅｂＡＰＩリストの一例を示す図である。図２５は、第２の実施形態に係るＳａａＳマネジメントコンソール表示処理の一例を示すフローチャートである。

図２５のステップＳ２５０１において、ＳａａＳサーバ１０２は、ステップＳ１６０４〜ステップＳ１６０６にてディスプレイ装置２１０に表示されたメッセージの近傍に「ＷｅｂＡＰＩ提供者に通知」ボタン（図２３の２３０１、２３０２）を表示する。

ステップＳ２５０２において、ＳａａＳサーバ１０２は、「ＷｅｂＡＰＩ提供者に通知」ボタンの押下を受け付けたか否かを判定する。受け付けた場合、ステップＳ２５０３に進む。受け付けなかった場合、ステップＳ１６０７に進む。

ステップＳ２５０３において、ＳａａＳサーバ１０２は、ＷｅｂＡＰＩの認証結果（ステップＳ１６０４〜ステップＳ１６０６にてディスプレイ装置２１０に表示されたメッセージの内容）をＷｅｂＡＰＩ提供者に通知する。すなわち、ステップＳ２５０３は、判定されたＡＰＩの認証結果を、ＡＰＩを提供する提供者の連絡先情報を用いて通知する処理の一例を示すステップである。

具体的には、「電子証明書を取得できませんでした」「電子証明書が不正です」「有効期限が切れています」などのＷｅｂＡＰＩ認証結果を、ＷｅｂＡＰＩ提供者００３に通知する。ＷｅｂＡＰＩ提供者００３の連絡先は、図２４の利用ＷｅｂＡＰＩテーブル２４００の連絡先２４０１から取得する。

以上により、ＷｅｂＡＰＩ利用者００２が、ＷｅｂＡＰＩ提供者００３にＷｅｂＡＰＩの認証結果を簡単に通知することができるため、認証エラーとなったＷｅｂＡＰＩの提供するＷｅｂＡＰＩ提供者００３に対処してもらうことが簡単にできるようになり、ＷｅｂＡＰＩ利用者００２による利用するＷｅｂＡＰＩの管理を容易にすることができる。

図２６は、第２の実施形態に係る情報処理装置１０１に出力されるＷｅｂページの一例を示す図である。図２７は、第２の実施形態に係るＷｅｂサービス実行処理の一例を示すフローチャートである。

ＳａａＳサーバ１０２で実行するＷｅｂサービスにおいて利用するＷｅｂＡＰＩが利用可能な（図２７のステップＳ１７０５において「ＯＫ」）場合は、ＳａａＳサーバ１０２は、情報処理装置１０１にＷｅｂページ２６１０（図２６）のように、利用するＷｅｂＡＰＩの実行結果（図２７のステップＳ１７０８で受信した、図２６の２６１１〜２６１３を出力する電文）を含む画面情報（例えばＨＴＭＬ）を送信する（図２７のステップＳ１７１０）。

一方、ＳａａＳサーバ１０２で実行するＷｅｂサービスにおいて利用するＷｅｂＡＰＩが利用不可能な（図２７のステップＳ１７０５において「ＮＧ」）場合は、ＳａａＳサーバ１０２は、情報処理装置１０１にＷｅｂページ２６２０（図２６）のように、利用できないＷｅｂＡＰＩについて、「ＷｅｂＡＰＩを利用できない」旨のメッセージ（図２７のステップＳ２７０１で作成した、図２６のメッセージ２６２２）を含む画面情報を送信する（図２７のステップＳ１７１０）。この場合、利用できるＷｅｂＡＰＩについては、Ｗｅｂページ２６１０のＷｅｂＡＰＩ Ａ実行結果２６１１・ＷｅｂＡＰＩ Ｃ実行結果２６１３と同様、Ｗｅｂページ２６２０のＷｅｂＡＰＩ Ａ実行結果２６２１・ＷｅｂＡＰＩ Ｃ実行結果２６２３を出力する。

また、ＷｅｂＡＰＩ Ｃは、有効期限が切れているため、ＷｅｂＡＰＩ Ｃ実行結果２６２３には、実行結果とともに「有効期限が切れています」のような警告メッセージを表示するとしてもよい。

すなわち、ステップＳ２７０１は、認証されていると判定されたＡＰＩと、認証されていないと判定されたＡＰＩとを識別して表示する画面情報を生成する処理の一例を示すステップである。

以上により、利用するＷｅｂサービスのうち一部が実行できない旨を表示させることで、セキュリティ（ＩＳＯ２７０１７）に準拠した、かつ柔軟なシステムを提供することが可能となる。

以上により、インターネット上で提供されるＡＰＩについて、セキュリティが確保された認証を効率的に行う仕組みを提供することができる。また、これにより、インターネット上で提供されるＡＰＩを利用するアプリケーションについて、セキュリティが確保された状態を効率的に維持する仕組みを提供することができる。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、ＯＳ（オペレーティングシステム）に供給されるスクリプトデータ等の形態から成ってもよい。

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

００１ Ｗｅｂサービス利用者
００２ ＷｅｂＡＰＩ利用者
００３ ＷｅｂＡＰＩ提供者
００４ クラウドセキュリティ認証局
００５ ＩＳＭＳ認証機関
１００ 認証システム
１０１ 情報処理装置
１０２ ＳａａＳサーバ
１０３ ＷｅｂＡＰＩサーバ
１０４ 認証サーバ
１０５ ＩＳＭＳ認証サーバ
１０６ ネットワーク

Claims (12)

1. １以上の外部に公開されたサービスのＡＰＩの認証に係る認証装置と通信可能であり、ＡＰＩを利用するアプリケーションを実行するサーバであって、
   前記アプリケーションが利用するＡＰＩの認証に係る認証装置を決定する決定手段と、
   前記ＡＰＩの前記認証装置に係る秘密鍵を用いて暗号化された認証情報を取得する認証情報取得手段と、
   前記決定した認証装置との通信により取得した前記認証装置に係る公開鍵を用いて前記暗号化された認証情報を復号した認証情報に基づいて、当該認証情報の有効性を判定する判定手段と、
   前記判定手段による有効性の判定結果に基づき、前記アプリケーションの実行を制御する実行制御手段と
   を備えることを特徴とするサーバ。
2. 前記判定手段により前記認証情報が有効ではないと判定されたＡＰＩを識別可能に通知する非認証ＡＰＩ通知手段
   を更に備えることを特徴とする請求項１に記載のサーバ。
3. 前記認証情報が有効ではないと判定されたＡＰＩに対して、当該ＡＰＩを利用するかを受け付ける受付手段を備え、
   前記実行制御手段は、前記受け付けた結果に基づき、前記アプリケーションの実行を制御する特徴とする請求項２に記載のサーバ。
4. 前記アプリケーションが利用するＡＰＩに対する前記有効性の判定結果に基づく当該ＡＰＩの利用可否情報を記憶する利用可否記憶手段を更に備え、
   前記実行制御手段は、前記記憶された前記ＡＰＩの利用可否情報に基づき、前記アプリケーションの実行を制御することを特徴とする請求項１乃至３のいずれか１項に記載のサーバ。
5. 前記判定手段は、前記復号された認証情報の所定の項目に基づくハッシュ値と前記復号された認証情報が持つハッシュ値を用いて当該認証情報の有効性を判定することを特徴とする請求項１乃至４のいずれか１項に記載のサーバ。
6. 前記判定手段は、前記復号された認証情報が持つ有効期限に基づき、当該認証情報の有効性を判定すること
   を特徴とする請求項１乃至５のいずれか1項に記載のサーバ。
7. 前記ＡＰＩを利用するかを判定するＡＰＩ利用判定手段を更に備え、
   前記実行制御手段は、
   前記判定手段により前記ＡＰＩに係る認証情報が有効ではないと判定された場合であっても、前記ＡＰＩ利用判定手段により当該ＡＰＩを利用すると判定された場合、当該ＡＰＩを利用するアプリケーションを実行させるように制御すること
   を特徴とする請求項１乃至６のいずれか１項に記載のサーバ。
8. 前記アプリケーションを実行するかを判定する実行判定手段を更に備え、
   前記実行制御手段は、
   前記判定手段により前記ＡＰＩに係る認証情報が有効ではないと判定された場合であっても、当該ＡＰＩを利用するアプリケーションであって、前記実行判定手段により実行すると判定された当該アプリケーションを実行するように制御すること
   を特徴とする請求項１乃至７のいずれか１項に記載のサーバ。
9. 前記ＡＰＩに係る連絡先の情報を記憶する連絡先情報記憶手段と、
   前記連絡先情報記憶手段により記憶されている情報を用いて、前記連絡先に前記判定手段による判定結果に係る情報を通知する判定結果通知手段と
   を更に備えることを特徴とする請求項１乃至８のいずれか１項に記載のサーバ。
10. 前記判定手段により前記ＡＰＩに係る認証情報が有効ではないと判定されたＡＰＩを識別して表示する画面情報を生成する画面情報生成手段
    を更に備えることを特徴とする請求項１乃至９のいずれか１項に記載のサーバ。
11. １以上の外部に公開されたサービスのＡＰＩの認証に係る認証装置と通信可能であり、ＡＰＩを利用するアプリケーションを実行するサーバにおける処理方法であって、
    前記サーバが、
    前記アプリケーションが利用するＡＰＩの認証に係る認証装置を決定する決定ステップと、
    前記ＡＰＩの前記認証装置に係る秘密鍵を用いて暗号化された認証情報を取得する認証情報取得ステップと、
    前記決定した認証装置との通信により取得した前記認証装置に係る公開鍵を用いて前記暗号化された認証情報を復号した認証情報に基づいて、当該認証情報の有効性を判定する判定ステップと、
    前記判定ステップでの有効性の判定結果に基づき、前記アプリケーションの実行を制御する実行制御ステップと
    を実行することを特徴とする処理方法。
12. コンピュータを請求項１乃至１０のいずれか１項に記載のサーバとして機能させるためのプログラム。
    

Images