JP6141041B2 - 情報処理装置及びプログラム、制御方法 - Google Patents

Description

本発明は、情報処理装置及びプログラム、制御方法の技術に関する。

従来、アクセストークンを用いて認証する技術が開示されている。
特許文献１は画像形成装置が端末装置にトークンを発行して、端末装置は発行されたトークンを用いて画像形成装置による認証を受ける技術を開示している。また、トークンの検証を画像形成装置で行う技術についても開示している。

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

ここで識別子に対応する第１のトークンを用いて第１の外部情報処理装置からデータを取得して、取得したデータから文書を生成して、同じ識別子に対応する第２のトークンを用いて第２の外部情報処理装置に生成した文書を送信する環境を想定する。

しかし、特許文献１は前述の環境を想定していないため、識別子から第１のトークンと第２のトークンを特定できない。そのため、第１のトークンを用いて第１の外部情報処理装置からデータを取得することも、第２のトークンを用いて第２の外部情報処理装置に文書を送信することも当然できない。

よって本発明では、識別子に基づいて第１のトークンと第２のトークンを特定して、特定された第１のトークンを第１の外部情報処理装置に用いて、特定された第２のトークンを第２の外部情報処理装置に用いることで、トークンを活用することを目的とする。

上記の目的を達成するための本発明に係る情報処理装置は、
識別子を第１の外部情報処理装置から受け付ける受付手段と、
前記識別子に基づいて、前記第１の外部情報処理装置からデータを取得するための第１のトークンと、認証処理装置で検証結果を取得するための第２のトークンを特定する特定手段と、
前記第１のトークンを用いて前記第１の外部情報処理装置からデータを取得して、取得した前記データから文書を生成する生成手段と、
前記第２のトークンを前記認証処理装置に送信することで、前記認証処理装置から前記第２のトークンの前記検証結果を取得する取得手段と、
前記第２のトークンを用いて第２の外部情報処理装置に生成した前記文書を送信する送信手段と、を有することを特徴とする。

本発明によれば、識別子に基づいて第１のトークンと第２のトークンを特定して、特定された第１のトークンを第１の外部情報処理装置に用いて、特定された第２のトークンを第２の外部情報処理装置に用いることで、トークンを活用することができる。

ネットワーク構成を示す図である。 ハードウェア構成図である。 サービス提供サーバＡ５００のモジュール構成図である。 サービス提供サーバＣ５６０のモジュール構成図である。 サービス提供サーバＢ５５０のモジュール構成図である。 サービス提供サーバＢ５５０のスケジュールジョブ登録画面の例である。 サービス提供サーバＢ５５０の登録済みスケジュールジョブ一覧画面の例である。 サービス提供サーバＡ５００のバッチ印刷情報の設定画面の例である。 サービス提供サーバＢ５５０の秘密鍵登録画面の例である。 サービス提供サーバＡ５００のバッチ印刷情報の例である。 ブラウザ、サービス提供サーバＡ５００、認証サーバＡ４００が実行するフローである。 サービス提供サーバＡ５００が実行するフローである。 ブラウザ、サービス提供サーバＡ５００、認証サーバＢ４５０が実行するフローである。 ブラウザ、サービス提供サーバＡ５００、サービス提供サーバＢ５５０が実行するフローである。 サービス提供サーバＡ５００、サービス提供サーバＢ５５０、サービス提供サーバＣ５６０、認証サーバＡ４００が実行するフローである。 サービス提供サーバＡ５００が実行するフローである。 ダイジェスト認証のチャレンジの例である。 ダイジェスト認証のレスポンスの例である。 本発明の第２の実施の形態に係るサービス提供サーバＡ５００が実行するフローである。

クラウドプラットフォーム上で業務データの管理や各種処理を行う方法について説明する。ユーザは、クライアントＰＣのブラウザからインターネットを介してクラウドプラットフォームのＷｅｂページにアクセスし、そのＷｅｂページ上で閲覧したい業務データを表示する。例えば、その画面から文書作成指示を行うと、文書生成サーバにリダイレクトされ、文書生成サーバがクラウドプラットフォームにある業務データを取得して文書を生成し、文書をクライアントＰＣ２００やクラウドプラットフォームに送信する。クラウドプラットフォームの代表例として、例えば、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ社のＳａｌｅｓｆｏｒｃｅ ＣＲＭが挙げられる。

クラウドプラットフォームや文書生成サーバはマルチテナントで動作する。テナントとは、クラウドプラットフォームや文書生成サーバを使用する契約を締結した企業や組織の単位である。マルチテナントで動作するサービスは、１つのシステムで複数のテナントのデータを管理し、あるテナントのデータが別のテナントから参照できないよう各テナントのデータを分離して管理する。自身のテナントのデータのみを参照させるため、クラウドプラットフォームや文書生成サーバはユーザ認証を行う。

クラウドプラットフォームと文書生成サーバが連携を行う場合、ユーザがそれぞれのサーバで認証を行うことなくサーバ間で認証を連携させることが可能である。複数のサーバ間で認証を連携させる技術として、ＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によるシングルサインオン （以下ＳＳＯ） の仕組みが挙げられる。ＳＡＭＬのＳＳＯにおいて、ユーザは、認証サービスを提供する側（ＩｄｅｎｔｉｔｙＰｒｏｖｉｄｅｒ、以下ＩｄＰ）、および認証サービスの認証結果を信頼してサービスを提供する側（ＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒ、以下ＳＰ）の両方のユーザＩＤを保有している。ユーザがＩｄＰで認証を受けると、ＳＰはその認証結果を信頼して、そのアクセスをＳＰ内で管理するＩＤとして認証する（ＩｄＰ先行）。また、ＩｄＰで認証を受けていない未認証のユーザがＳＰにアクセスしてきた場合、ＳＰは、未認証のユーザを適切なＩｄＰへと誘導し、ＩｄＰで認証させる（ＳＰ先行）。

ＳＡＭＬによるＳＳＯを行う場合、ＩｄＰが保有するＩＤとＳＰが保有するＩＤを対応付け（以下、ユーザマッピングと称する）を行って管理する。特に、ユーザを識別することが不可欠なサービスと文書生成サーバを連携させる場合、ユーザマッピングによるＩＤ管理が必要となる。ユーザを識別することが不可欠なサービスには、文書をＩＤ毎に管理・印刷する印刷サービスが挙げられる。

しかしながら上記の方法には以下の問題が挙げられる。複数のサービス提供サーバの連携によって成立つ自動ワークフローシステム（夜間バッチ印刷など）をクラウド環境で実現する場合、ユーザが介在しないため、通常のユーザを基準とした認証の仕組みを用いることが出来ない。また、連携するサービス提供サーバ間の両方にユーザ名やパスワード等のアカウント情報を保持した場合、他のサービスのアカウント情報を管理しなければならないことになり、不正な成り済ましや情報漏洩等のセキュリティリスクが増大する。

さらに、クラウド環境における各サービスはマルチテナントで動作する必要があり、サーバ連携による自動ワークフロー実行時、それがどのテナントのフローなのか特定できなければならない。また、各テナントを特定するための情報はテナントごとに分離され安全に管理される必要がある。

以降、サービス提供サーバ同士が連携してスケジュールジョブを実行するシステムにおいて、夜間バッチ印刷等のユーザが介在しないシステム権限で動作するスケジュールジョブを実行する場合について説明する。その際、両サーバにユーザ名やパスワードを保持すること無く安全に連携を実現する方法についても説明する。

［実施例１］
図１は、本発明の実施例のシステム構成を示すブロック図である。

１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１０１）である。複数のＬＡＮ１０１は、ＷＡＮ１００を介することで互いの装置が通信可能になる。

２００はユーザが操作するクライアントＰＣ２００であり、後述するサービス提供サーバＡ５００やサービス提供サーバＢ５５０に対してブラウザ２２０を用いてリクエストを発行する。以降、クライアントＰＣ２００上で実行されるブラウザ２２０を単にブラウザ２２０と呼ぶ。

３００はユーザのアクセスを適切なＩｄＰへと誘導する認証サービス決定サーバである。

４００および４５０はそれぞれ認証を行う認証サーバＡ，Ｂであり、ともにＩｄＰ（アイデンティティプロバイダ装置）として動作する。なお認証サービスは２つに限定されるものではない。どのＩｄＰが実際の認証を行うかはアクセスしてきたユーザによって異なる。５００や５５０や５６０はそれぞれサービスを提供するサービス提供サーバＡ５００，Ｂ５５０、Ｃ５６０であり、認証されたユーザに対してサービスを提供する。サービス提供サーバＡ５００はクライアントＰＣ２００やサービス提供サーバＢ５５０からのリクエストを受信して文書生成を行う。サービス提供サーバＢ５５０はクライアントＰＣ２００やサービス提供サーバＡ５００からのリクエストに応じて保持するデータの表示・更新等を行う。サービス提供サーバＣ５６０はクライアントＰＣ２００やサービス提供サーバＡ５００からのリクエストを受信して文書印刷を行う。なお、サービス提供サーバＡ５００，サービス提供サーバＢ５５０，サービス提供サーバＣ５６０は文書生成サービスやクラウドプラットフォーム、文書印刷サービスに限定されるものではなく、別のサービスであってもよい。またクライアントＰＣ２００、認証サービス決定サーバ３００、認証サーバＡ４００、認証サーバＢ４５０、サービス提供サーバＡ５００、サービス提供サーバＢ５５０、サービス提供サーバＣ５６０はそれぞれＷＡＮネットワーク１００およびＬＡＮ１０１を介して接続されている。なおクライアントＰＣ２００およびそれぞれのサーバはそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また同一のＰＣ上に構成されていてもよい。認証サービス決定サーバ３００、認証サーバＡ４００、サービス提供サーバＡ５００、サービス提供サーバＣ５６０は同じネットワーク内（イントラネット内）に構築されたサーバ群であり、認証サーバＢ４５０、サービス提供サーバＢ５５０は同じネットワーク内（イントラネット内）に構築されたサーバ群となる。また、さらに各サーバは１台で構成されていてもよいし、複数台で構成されていても構わない。このように１台又は複数台で構成されたシステムをサーバーシステムと呼ぶ。

クライアントＰＣ２００はまず、バッチ印刷用のスケジュールジョブを登録するためサービス提供サーバＢ５５０にアクセスする。サービス提供サーバＢ５５０は未認証のユーザアクセスを受け付けると、不図示の認証画面を表示し、ユーザ認証を行う。ユーザを認証すると、バッチ印刷用のスケジュールジョブ登録画面の表示を行う。

図６は、本実施の形態に係るサービス提供サーバＢ５５０がブラウザ２２０に提供するバッチ印刷用のスケジュールジョブ登録画面６０１の例である。スケジュールジョブ登録画面６０１は、スケジュールジョブの名前を設定するジョブ情報設定領域６０２、スケジュールジョブを開始する時刻を設定するジョブ開始時刻設定領域６０３、スケジュールジョブで実行されるバッチ印刷の印刷パラメータを設定する印刷パラメータ設定領域６０４、およびこれらの設定を登録する登録ボタン６０５から成る。ユーザ（管理者）は、スケジュールジョブ登録画面６０１を操作し、スケジュールジョブを実行したい時刻および印刷パラメータ等を入力して登録ボタン６０５を押す。登録ボタン６０５が押下されると、サービス提供サーバＢ５５０は、指示された設定をテナントごとの管理領域に保存する。保存されたスケジュールジョブに関する各種設定は、サービス提供サーバＢ５５０がブラウザ２２０に提供するスケジュールジョブ一覧画面でいつでも確認可能である。

図７は、本実施の形態に係るサービス提供サーバＢ５５０がブラウザ２２０に提供するスケジュールジョブ一覧画面７０１の例である。一覧表示により、スケジュールジョブの名前７０２やジョブの開始時刻７０３を確認することが出来る。

次にクライアントＰＣ２００は、バッチ印刷用の事前設定を行うためにサービス提供サーバＡ５００にアクセスする。サービス提供サーバＡ５００は未認証のユーザアクセスを受け付けると、不図示の認証画面を表示し、ユーザ認証を行う。ユーザを認証すると、バッチ印刷用の設定画面の表示を行う。

図８は、本実施の形態に係るサービス提供サーバＡ５００がブラウザ２２０に提供するバッチ印刷用の設定画面８０１の例である。バッチ印刷用の設定画面８０１には、サービス提供サーバＣ５６０のアクセストークン（以降、サーバＣアクセストークン）をサービス提供サーバＡ５００の管理領域に設定するためのボタン８０２、サービス提供サーバＢ５５０のアクセストークン（以降、サーバＢアクセストークン）をサービス提供サーバＡ５００の管理領域に設定するためのボタン８０３、サービス提供サーバＢ５５０から来るバッチ印刷要求の検証を行うための秘密鍵８０４が表示されている。アクセストークンは、各サービス提供サーバの機能へのアクセスを許可するトークンで、通常、ユーザによる事前認可操作を経て認証サーバから発行される。ユーザ（管理者）によりボタン８０２、８０３が押下されると、サービス提供サーバＡ５００は、それぞれのサーバから取得したアクセストークンをテナントの識別番号（テナントＩＤ）に紐付けて管理領域へ保存する。また、秘密鍵８０４については、テナントＩＤ発行時（新規にテナントを登録した時）に生成され、その際テナントＩＤに紐付けて管理する構成としても構わない。

さらにクライアントＰＣ２００は、バッチ印刷用の事前設定を行うためにサービス提供サーバＢ５５０にアクセスする。サービス提供サーバＢ５５０における認証手続きは前記と同様である。ユーザ認証済みであれば、秘密鍵登録画面の表示を行う。

図９は、本実施の形態に係るサービス提供サーバＢ５５０がブラウザ２２０に提供する秘密鍵登録画面９０１の例である。ユーザ（管理者）は、秘密鍵入力エリア９０２に対して、前記バッチ印刷用の設定画面８０１に表示された秘密鍵を入力し、登録ボタン９０３を押す。登録ボタン９０３が押下されると、サービス提供サーバＢ５５０は、秘密鍵をテナントごとの管理領域に保存する。

サービス提供サーバＢ５５０はスケジュールジョブの開始時刻になると、スケジュールジョブを開始し、サービス提供サーバＡ５００にバッチ印刷を要求する。

サービス提供サーバＡ５００はバッチ印刷の要求を受け付けると、その要求が妥当であるかを検証し、妥当であればサーバＢアクセストークンを使ってサービス提供サーバＢ５５０からデータを取得する。そして取得したデータに基づいて生成された文書をサーバＣアクセストークンを使ってサービス提供サーバＣ５６０に送信する。

図２は本実施の形態に係るクライアントＰＣ２００の構成を示す図である。また認証サービス決定サーバ３００、認証サーバＡ４００、認証サーバＢ４５０、サービス提供サーバＡ５００、サービス提供サーバＢ５５０、サービス提供サーバＣ５６０を提供するサーバコンピューターの構成も同様である。このように、本実施形態のクライアントＰＣ２００およびサーバには一般的な情報処理装置のハードウェア構成を適用できる。

図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはＨＤ（ハードディスク）２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。なお、ＨＤ２１１はＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｉｓｋ）であっても構わない。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するＨＤ２１１やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＮＣ２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。

尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はＨＤ２１１にインストールされたアプリケーションプログラムである。

加えて、ＣＰＵ２０１がＨＤ２１１に記憶されているプログラムに基づき処理を実行することによって、図３乃至５に示されるようなソフトウェア構成及び後述するフローの各ステップの処理が実現される。

図５は、本実施の形態に係るサービス提供サーバＢ５５０のモジュール構成図である。サービス提供サーバＢ５５０は、アクセス制御モジュール５５１、ページ生成モジュール５５２、スケジュールジョブ登録モジュール５５３１，５５４１、スケジュールジョブ情報管理モジュール５５３２，５５４２、スケジュールジョブ実行モジュール５５３３，５５４３、バッチ印刷要求モジュール５５３４，５５４４、秘密鍵管理モジュール５５３５，５５４５、認証情報付加モジュール５５３６，５５４６、業務データ管理モジュール５５３７，５５４７を備える。

サービス提供サーバＢ５５０がアクセスを受け付けると、ユーザのアクセスが認証済みであるか否かをアクセス制御モジュール５５１が判断し、未認証であればページ生成モジュール５５２が認証画面をブラウザ２２０に提供する。認証済みであればサービス提供サーバＢ５５０はサービスを提供する。

スケジュールジョブ登録モジュール５５３１，５５４１はスケジュールジョブを登録する。ジョブ開始時間等のスケジュールジョブ関連情報は、スケジュールジョブ情報管理モジュール５５３２，５５４２によって管理される。

スケジュールジョブの開始時刻になると、スケジュールジョブ実行モジュール５５３３，５５４３がスケジュールジョブを実行する。バッチ印刷要求モジュール５５３４，５５４４はスケジュールジョブ実行モジュール５５３３，５５４３から呼び出され、サービス提供サーバＡ５００に対してバッチ印刷の要求リクエストを行う。サービス提供サーバＡ５００にて前記バッチ印刷リクエストの妥当性検証を行うため、秘密鍵管理モジュール５５３５，５５４５が秘密鍵の保存および取得を行う。そして認証情報付加モジュール５５３６，５５４６が妥当性検証に必要な情報を生成してリクエストに付加する。

サービス提供サーバＢ５５０が業務データ取得のリクエストを受け付けると、業務データ管理モジュール５５３７，５５４７が業務データを取得し、リクエストの発行元に返却する。

また、サービス提供サーバＢ５５０は、スケジュールジョブ登録モジュール５５３１，５５４１、スケジュールジョブ情報管理モジュール５５３２，５５４２、スケジュールジョブ実行モジュール５５３３，５５４３、バッチ印刷要求モジュール５５３４，５５４４、秘密鍵管理モジュール５５３５，５５４５、認証情報付加モジュール５５３６，５５４６、業務データ管理モジュール５５３７，５５４７をテナント毎に管理する。なお、これらテナント毎に管理されるモジュールは同一のＨＤ２１１に記憶されてテナント毎のデータを論理的に分離して管理するようにしてもよいし、ＨＤ２１１を分けて物理的に分離して管理するようにしてもよい。また、これらのモジュールは実体としては１つである。サービス提供サーバＢ５５０がテナントＩＤを各モジュールに渡すことで、各モジュールはそのテナント専用の動作を行う。例えば、そのテナント固有のデータ領域のみアクセスが制限される。図５ではこのような意図をふまえてテナント毎にモジュールを記載している。

図３は、本実施の形態に係るサービス提供サーバＡ５００のモジュール構成図である。サービス提供サーバＡ５００は、アクセス制御モジュール５０１、データ取得モジュール５０２、文書生成モジュール５０３、ページ生成モジュール５０４、アクセストークン取得モジュール５０５、バッチ印刷情報管理モジュール５０６、秘密鍵生成モジュール５０７、文書送信モジュール５０８、認証情報検証モジュール５０９、アクセストークン検証モジュール５１０を備える。

サービス提供サーバＡ５００がアクセスを受け付けると、アクセス制御モジュール５０１はアクセスが認証済みかどうかを判断する。アクセスが認証済みであればサービス提供サーバＡ５００はサービスを提供する。

サービス提供サーバＡ５００は、サービス提供サーバＢ５５０からのバッチ印刷リクエストに応じてバッチ印刷を行う。バッチ印刷リクエストを受けると、認証情報検証モジュール５０９は、受理したバッチ印刷リクエストを検証する。検証に必要な情報は、あらかじめＨＤ２１１に保存されており、バッチ印刷情報管理モジュール５０６によって管理される。

図１０はＨＤ２１１に保存されたバッチ印刷情報の一例である。後述する秘密鍵およびサーバＢおよびＣのアクセストークンおよびリフレッシュトークンが、サービス提供サーバＡ５００のテナントＩＤに紐付けられて保存されている。なお、リフレッシュトークンとは、アクセストークンの期限が切れた際に、再発行を行う際必要になる無期限のトークンである。例では、テナントＩＤ「１０００ＡＡ」と「１０００ＢＢ」の２つのテナントに関するバッチ印刷情報が保存されている。バッチ印刷情報として保存されている秘密鍵は、バッチ印刷リクエストの検証に使用される。具体的な検証方法については後述する。

あらかじめＨＤ２１１に保存されるバッチ印刷情報のうち、秘密鍵については、秘密鍵生成モジュール５０７が生成したものであり、サービス提供サーバＡ５００のテナントＩＤに紐付けて管理されている。また、バッチ印刷情報のうち、サーバＢアクセストークンおよびサーバＣアクセストークンについては、アクセストークン取得モジュール５０５により夫々サービス提供サーバＢ５５０およびサービス提供サーバＣ５６０から取得される。そしてこちらもサービス提供サーバＡ５００のテナントＩＤに紐付けて管理されている。

データ取得モジュール５０２は、サーバＢアクセストークンを使用してサービス提供サーバＢ５５０から業務データを取得する。文書生成モジュール５０３は、不図示のフォーム管理モジュールが管理するフォームを取得して、データ取得モジュール５０２が取得した業務データとフォームから文書を生成する。文書送信モジュール５０８は、文書生成モジュール５０３が生成した文書を、サーバＣアクセストークンを使用してサービス提供サーバＣ５６０に送信する。アクセストークン検証モジュール５１０は、サーバＢおよびサーバＣアクセストークンの有効期限が切れていないかを判断し、切れている場合にトークンの再取得を行う。

図４は、本実施の形態に係るサービス提供サーバＣ５６０のモジュール構成図である。サービス提供サーバＣ５６０は、アクセス制御モジュール５６１、ページ生成モジュール５６２、文書印刷モジュール５６３を備える。

サービス提供サーバＣ５６０がアクセスを受け付けると、ユーザのアクセスが認証済みであるか否かをアクセス制御モジュール５６１が判断し、未認証であればページ生成モジュール５６２が認証画面をブラウザ２２０に提供する。認証済みであればサービス提供サーバＣ５６０はサービスを提供する。

文書印刷モジュール５６３は、サービス提供サーバＡ５００から送信された文書を印刷する。詳細についてはステップ１５２４の説明で述べる。

以降、図１１から図１４を用いてバッチ印刷を行うための準備について説明する。

図１１は本実施の形態に係る、ブラウザ２２０、サービス提供サーバＡ５００および認証サーバＡ４００が実行するフローである。本フローは、ブラウザ２２０に表示されるバッチ印刷用の設定画面８０１において、ユーザがサーバＣアクセストークンの設定ボタン８０２を押下することによって始まる（ステップ１１０１）。

ステップ１１０２でサービス提供サーバＡ５００は、サーバＣアクセストークンの設定要求を受け付ける。本フロー開始前に、ブラウザ２２０は、ログイン操作によりサービス提供サーバＡ５００へのユーザ認証を済ませており、サービス提供サーバＣ５６０の認証セッションＩＤは認証サーバＡ４００により発行済みである。サービス提供サーバＣ５６０の認証セッションＩＤは、ブラウザ２２０によりＵＲＬパラメータ「ＡＵＴＨ＿ＩＤ」に指定され、本ステップ１１０２の設定要求リクエストに含まれている。

なお、本実施例において、認証セッションＩＤはＣｏｏｋｉｅ「ＡＵＴＨ＿ＳＥＳＳＩＯＮ＿ＩＤ」に付加することを想定する。Ｃｏｏｋｉｅ以外の方法で認証セッションＩＤを付加するようことも可能である。

ステップ１１０３でサービス提供サーバＡ５００は、前記設定要求リクエストのＵＲＬパラメータとしてパラメータ「ＡＵＴＨ＿ＩＤ」に含まれるサービス提供サーバＣ５６０の認証セッションＩＤを取得する。

ステップ１１０４でサービス提供サーバＡ５００は、前記ステップ１１０２で取得したサービス提供サーバＣ５６０の認証セッションＩＤをパラメータに指定して認証サーバＡ４００のアクセストークン取得ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を呼び出す。

ステップ１１０５で認証サーバＡ４００は、サービス提供サーバＡ５００からのサーバＣアクセストークン取得ＡＰＩ呼び出しを受け付け、ステップ１１０６でサーバＣアクセストークンおよびサーバＣリフレッシュトークンを発行する。そして、発行したアクセストークンおよびリフレッシュトークンをサービス提供サーバＡ５００に返す。

ステップ１１０７でサービス提供サーバＡ５００は、サーバＣアクセストークンおよびサーバＣリフレッシュトークンをＡＰＩの戻り値として受理する。

ステップ１１０８でサービス提供サーバＡ５００は、ステップ１１０７で受理したサーバＣアクセストークンおよびサーバＣリフレッシュトークンを、サービス提供サーバＡ５００のテナントＩＤに紐付けてＨＤ２１１に保存する。なお、テナントＩＤは、本フロー開始前のログイン完了時に既に特定され、サービス提供サーバＡ５００が識別済みとする。

ステップ１１０９でサービス提供サーバＡ５００は、サーバＣアクセストークンおよびサーバＣリフレッシュトークンの保存が完了したことを示す保存完了画面を、ブラウザ２２０に返す。

ステップ１１１０でブラウザ２２０は、ステップ１１０９にて返された保存完了画面を表示する。

以上でブラウザ２２０、サービス提供サーバＡ５００および認証サーバＡ４００が実行するフローが終了する。なお、上記フローは認証サーバＡ４００のアクセストークン発行ＡＰＩによるアクセストークン取得のフローだが、サービス提供サーバＡ５００がサービス提供サーバＣ５６０にアクセスするために必要な情報が取得できるのであれば他の方法でも構わない。

図１２は本実施の形態に係る、サービス提供サーバＡ５００が実行するフローである。本フローは、サービス提供サーバＡ５００でのサーバＣアクセストークン取得時のエラー処理を示したフローである。なお、既に説明したステップと同じ処理については、既に説明したステップの番号と同一の番号を付与し、特に断りが無い限り説明は省略する。

ステップ１２０１でサービス提供サーバＡ５００は、ステップ１１０７においてサーバＣアクセストークンおよびサーバＣリフレッシュトークンを正しく取得できたかを判断する。例えば、ステップ１１０３で取得した認証セッションＩＤの有効期限が切れていた場合などに、アクセストークンの取得が失敗する可能性がある。

正しく取得できた場合、ステップ１１０８に遷移し、取得に失敗した場合、ステップ１２０２に遷移する。

サーバＣアクセストークンおよびサーバＣリフレッシュトークンの取得に失敗した場合、ステップ１２０２でサービス提供サーバＡ５００は、サーバＣアクセストークンおよびサーバＣリフレッシュトークンの取得に失敗したことを示すエラー画面を、ブラウザ２２０に返す。

以上でサーバＣアクセストークンの取得と保存に関するサービス提供サーバＡ５００が実行するフローは終了する。

図１３は本実施の形態に係る、ブラウザ２２０、サービス提供サーバＡ５００および認証サーバＢ４５０が実行するフローである。本フローは、ブラウザ２２０に表示されるバッチ印刷用の設定画面８０１において、ユーザがサーバＢアクセストークンの設定ボタン８０３を押下することによって始まる（ステップ１３０１）。

ステップ１３０２でサービス提供サーバＡ５００は、サービス提供サーバＢ５５０のアクセストークン設定要求を受け付ける。

ステップ１３０３でサービス提供サーバＡ５００は、認証サーバＢ４５０へリダイレクトするようブラウザ２２０に指示を行う。その際、認証サーバＢ４５０がアクセストークン設定要求元（すなわち、サービス提供サーバＡ）および認可完了後のリダイレクト先を識別できるように、リダイレクトパラメータとして、ＵＲＬにアクセストークン設定要求元のクライアント識別子およびリダイレクトＵＲＬを付与する。クライアント識別子とは認証サーバＢ４５０へのアクセス元がサービス提供サーバＡ５００であることを示す識別子である。

ステップ１３０４で認証サーバＢ４５０は、不図示のログイン画面の表示をブラウザ２２０に返す。

ステップ１３０５でブラウザ２２０は、ステップ１３０４にて返されたログイン画面を表示する。ユーザは、ブラウザ２２０に表示されたログイン画面に対して、サービス提供サーバＢ５５０のユーザＩＤおよびパスワードを入力し、認可の許可ボタンを押下する。

ユーザによる認可ボタン押下を受けて、ステップ１３０６でブラウザ２２０は、認証サーバＢ４５０に対して、サービス提供サーバＡ５００からサービス提供サーバＢ５５０へのアクセス許可要求を行う。

ステップ１３０７で認証サーバＢ４５０は、ブラウザ２２０からの認可要求を受け付ける。ステップ１３０８で認証サーバＢ４５０は、サービス提供サーバＡ５００へリダイレクトするようブラウザ２２０に指示を行う。リダイレクト先は、ステップ１３０３でサービス提供サーバＡ５００が認証サーバＢ４５０へのリダイレクトパラメータとして、ＵＲＬに付与したものである。サービス提供サーバＡ５００へのリダイレクトＵＲＬパラメータには認可コードが含まれる。認可コードとは、アクセストークンを取得するために使用される、ユーザのアクセス許可を表す短期間のみ有効なトークンである。

リダイレクトによるアクセスを受け付けると、ステップ１３０９でサービス提供サーバＡ５００は、認証サーバＢ４５０に対して、サーバＢアクセストークンの取得リクエストを行う。この際サービス提供サーバＡ５００は、リクエストのＵＲＬパラメータとして、リダイレクトのＵＲＬパラメータに含まれていた認可コードを含める。

ステップ１３１０で認証サーバＢ４５０は、サービス提供サーバＡ５００からのサーバＢアクセストークン取得リクエストを受理する。ステップ１３１１で認証サーバＢ４５０は、サーバＢアクセストークンおよびサーバＢリフレッシュトークンを発行する。そして、それらのトークンをサービス提供サーバＡ５００にレスポンスとして返却する。

ステップ１３１２でサービス提供サーバＡ５００は、サーバＢアクセストークンおよびサーバＢリフレッシュトークンをレスポンスとして受理する。

ステップ１３１３でサービス提供サーバＡ５００は、ステップ１３１２で受理したサーバＢアクセストークンおよびサーバＢリフレッシュトークンをサービス提供サーバＡ５００のテナントＩＤに紐付けてＨＤ２１１に保存する。なお、テナントＩＤは、本フロー開始前のログイン完了時に既に特定され、サービス提供サーバＡ５００が識別済みとする。

ステップ１３１４でサービス提供サーバＡ５００は、サーバＢアクセストークンおよびサーバＢリフレッシュトークンの保存が完了したことを示す保存完了画面を、ブラウザ２２０に返す。

ステップ１３１５でブラウザ２２０は、ステップ１３１４にて返された保存完了画面を表示する。

以上でサーバＢアクセストークンの取得と保存に関する、ブラウザ２２０、サービス提供サーバＡ５００および認証サーバＢ４５０のフローの説明を終了する。なお、上記フローはＯａｕｔｈによるアクセストークン取得のフローだが、サービス提供サーバＡ５００がサービス提供サーバＢ５５０にアクセスするために必要な情報が取得できるのであれば他の方法でも構わない。

図１４は本実施の形態に係る、ブラウザ２２０、サービス提供サーバＡ５００およびサービス提供サーバＢ５５０が実行するフローである。本フローは、サービス提供サーバＡ５００が提供することでブラウザ２２０に表示される不図示の秘密鍵発行画面において、ユーザが秘密鍵発行ボタンを押下することによって始まる（ステップ１４０１）。

ステップ１４０２でサービス提供サーバＡ５００は、秘密鍵発行要求を受け付ける。

ステップ１４０３でサービス提供サーバＡ５００は、秘密鍵の発行（生成）を行う。本実施例における秘密鍵は、サービス提供サーバＡ５００が生成するＵＵＩＤとサービス提供サーバＡ５００のテナントＩＤを組み合わせたものとするが、別な内容でも構わない。

ステップ１４０４でサービス提供サーバＡ５００は、ステップ１４０３で発行した秘密鍵を、サービス提供サーバＡ５００のテナントＩＤに紐付けてＨＤ２１１に保存する。なお、テナントＩＤは、本フロー開始前のログイン完了時に既に特定され、サービス提供サーバＡ５００が識別済みとする。また、一度本ステップ１４０４で秘密鍵が保存された後はステップ１４０３で再度秘密鍵の生成は行われない。

ステップ１４０５でサービス提供サーバＡ５００は、ユーザが、ステップ１４０３で発行された秘密鍵を確認するための秘密鍵確認画面８０１を、ブラウザ２２０に返す。

ステップ１４０６でブラウザ２２０は、ステップ１４０５にて返された秘密鍵確認画面８０１を表示する。ユーザは、後述する秘密鍵登録画面９０１にて秘密鍵の指定を行うために、表示された秘密鍵をメモもしくはコピーする。

ステップ１４０７でブラウザ２２０は、サービス提供サーバＢが提供する秘密鍵登録画面９０１にアクセスする。必要に応じてユーザ認証を行う。

ステップ１４０８でサービス提供サーバＢ５５０は、秘密鍵の登録操作を行うための秘密鍵登録画面９０１を、ブラウザ２２０に返す。

ステップ１４０９でブラウザ２２０は、ステップ１４０８にて返された秘密鍵登録画面９０１を表示する。そして、ユーザは表示された秘密鍵登録画面９０１にメモもしくはコピーした秘密鍵の入力を行う。

ステップ１４１０でブラウザ２２０は、サービス提供サーバＢ５５０に対して、秘密鍵登録リクエストを発行する。リクエストのＵＲＬのパラメータとして秘密鍵が含まれるため、クライアントＰＣ２００とサービス提供サーバＢ５５０間の通信は暗号化されることが望ましい。なお、ここではＵＲＬのパラメータを用いて秘密鍵を送信するＧＥＴの例を説明したが、当然ＰＯＳＴによって秘密鍵を送信しても構わない。

ステップ１４１１でサービス提供サーバＢ５５０は、ブラウザ２２０からの秘密鍵登録リクエストを受理する。

ステップ１４１２でサービス提供サーバＢ５５０は、ステップ１４１１で受理したリクエストに含まれる秘密鍵を、サービス提供サーバＡ５００のテナントＩＤに紐付けてＨＤ２１１に保存する。なお、テナントＩＤは、あらかじめ不図示の保存画面によりサービス提供サーバＢ５５０に保存済みである。サービス提供サーバＡ５００とサービス提供サーバＢ５５０のテナントＩＤは１対１に紐付いているものとする。また、秘密鍵およびサービス提供サーバＡ５００のテナントＩＤは、サービス提供サーバＢ５５０のテナントごとに別の領域に保存され、処理対象のテナント以外からはアクセスできないよう管理されていることが望ましい。また、秘密鍵はサービス提供サーバＢ５５０のテナントＩＤが同一であれば、スケジュールジョブが別であっても同じものが使用される。

以上でブラウザ２２０、サービス提供サーバＡ５００およびサービス提供サーバＢ５５０が実行するフローが終了する。

以降、図１１から図１４を用いて説明した準備が完了した後に行うバッチ印刷について説明する。

図１５Ａおよび図１５Ｂは本実施の形態に係る、サービス提供サーバＡ５００、サービス提供サーバＣ５６０、サービス提供サーバＢ５５０および認証サーバＡ４００が実行するフローである。本フローは、サービス提供サーバＢ５５０のスケジュールジョブ情報管理モジュール５５３２、５５４２が管理するスケジュールジョブの実行開始時間に従って、スケジュールジョブ実行モジュール５５３３、５５４３によりスケジュールジョブが開始されることによって始まる。

ステップ１５０１でサービス提供サーバＢ５５０のスケジュールジョブ実行モジュール５５３３、５５４３は、スケジュールジョブの実行を開始する。スケジュールジョブ実行モジュール５５３３、５５４３は、スケジュールジョブ情報管理モジュール５５３２、５５４２が管理するすべてのスケジュールジョブの実行開始時間を確認し、実行開始時間となったスケジュールジョブの実行を開始する。スケジュールジョブ実行モジュール５５３３、５５４３は、スケジュールジョブの実行を開始すると、バッチ印刷要求モジュール５５３４、５５４４を呼び出し、その後の処理を任せる。

ステップ１５０２でサービス提供サーバＢ５５０のバッチ印刷要求モジュール５５３４、５５４４は、サービス提供サーバＡ５００に対してバッチ印刷の要求を行う。バッチ印刷要求はユーザログインを必要としないスケジュールジョブとして実行されるため、通常のログインを経た印刷要求とは異なり、実行の主体はある特定のユーザではなくサービス提供サーバＢ５５０のシステムそのもの（システム権限）となる。このため、要求を受けるサービス提供サーバＡ５００は、バッチ印刷要求の妥当性をユーザやテナントＩＤから判断することが出来ない。

ステップ１５０３でサービス提供サーバＡ５００のアクセス制御モジュール５０１は、バッチ印刷要求を受け付ける。前述の通り、バッチ印刷要求には認証セッションＩＤ等のユーザを識別するための情報が含まれていないため、後述するステップ１５０４〜１５１２にてバッチ印刷要求を受け付けてよいかどうかの検証を行う。

ステップ１５０４でサービス提供サーバＡ５００の認証情報検証モジュール５０９は、サービス提供サーバＢ５５０に対して、ダイジェスト認証のチャレンジを送信する。

図１７は、本実施の形態に係る認証情報検証モジュール５０９が送信するダイジェスト認証のチャレンジの例（ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅレスポンスヘッダの一部）である。ｒｅａｌｍ１７０２にはサービス提供サーバＡ５００のサービス名がセットされている。ａｌｇｏｒｉｔｈｍ１７０３はダイジェスト認証アルゴリズムで「ＳＨＡ−２５６」がセットされている。ｎｏｎｃｅ１７０４には認証情報検証モジュール５０９が生成するワンタイムトークンがセットされている。ここでワインタイムトークンとはダイジェスト認証の時に用いるダイジェスト認証専用のトークンを意味する。

ステップ１５０５でサービス提供サーバＢ５５０のアクセス制御モジュール５５１は、ダイジェスト認証のチャレンジを受信し、それを認証情報付加モジュール５５３６、５５４６に渡す。

ステップ１５０６でサービス提供サーバＢ５５０の秘密鍵管理モジュール５５３５、５５４５は、ステップ１４１２でＨＤ２１１に保存された秘密鍵を取得する。秘密鍵管理モジュール５５３５、５５４５は、当該スケジュールジョブに対応するテナントＩＤを特定し、そのテナントＩＤに紐付けられた秘密鍵を取得する。秘密鍵管理モジュール５５３５、５５４５は、取得した秘密鍵を認証情報付加モジュール５５３６、５５４６に渡す。

ステップ１５０７でサービス提供サーバＢ５５０の認証情報付加モジュール５５３６、５５４６は、スケジュールジョブに対応するテナントＩＤを取得する。

ステップ１５０８でサービス提供サーバＢ５５０の認証情報付加モジュール５５３６、５５４６は、ステップ１５０５でアクセス制御モジュール５５１から渡されたダイジェスト認証のチャレンジ、ステップ１５０６で秘密鍵管理モジュール５５３５、５５４５から渡された秘密鍵、ステップ１５０７で取得したサービス提供サーバＡ５００のテナントＩＤ、等からダイジェスト認証のレスポンスを作成する。

図１８は、本実施の形態に係る認証情報付加モジュール５５３６、５５４６が作成するダイジェスト認証のチャレンジ（Ａｕｔｈｏｒｉｚａｔｉｏｎリクエストヘッダの一部）の例である。ｕｓｅｒｎａｍｅ１８０２にはステップ１５０６で取得した秘密鍵に対応するサービス提供サーバＡ５００のテナントＩＤをセットする。ｒｅａｌｍ１８０３およびｎｏｎｃｅ１８０４には、前記ダイジェスト認証のチャレンジに含まれる同項目の値をセットする。ｃｎｏｎｃｅ１８０６には認証情報付加モジュール５５３６、５５４６が生成するワンタイムトークンをセットする。そして、ｒｅｓｐｏｎｓｅ１８０７には、ｕｓｅｒｎａｍｅ１８０２、ｒｅａｌｍ１８０３、ｎｏｎｃｅ１８０４、ｃｎｏｎｃｅ１８０６およびステップ１５０６で秘密鍵管理モジュール５５３５、５５４５から渡された秘密鍵を連結したものをさらにａｌｇｏｒｉｔｈｍ１８０５に指定の「ＳＨＡ−２５６」でダイジェスト化した値をセットする。

ステップ１５０９でサービス提供サーバＢ５５０の認証情報付加モジュール５５３６、５５４６は、サービス提供サーバＡ５００に対して、ステップ１５０８で作成したダイジェスト認証のレスポンスを送信する。なお、この際、認証情報付加モジュール５５３６、５５４６は、ダイジェスト認証のレスポンスとは別に、ステップ１５０７で取得したサービス提供サーバＡ５００のテナントＩＤをＵＲＬパラメータ「ｔｅｎａｎｔ＿ＩＤ」に設定する。

ステップ１５１０でサービス提供サーバＡ５００のアクセス制御モジュール５５１は、サービス提供サーバＢ５５０から送信されたダイジェスト認証のレスポンスおよびＵＲＬパラメータを受信する。アクセス制御モジュール５５１は、本ステップ１５１０にて、ＵＲＬパラメータ「ｔｅｎａｎｔ＿ＩＤ」の値を取得し、アクセスがどのテナントからのものかを判断する。

ステップ１５１１でサービス提供サーバＡ５００のバッチ印刷情報管理モジュール５０６は、ステップ１５１０で受信したＵＲＬパラメータ「ｔｅｎａｎｔ＿ＩＤ」の値をキーとして、ＨＤ２１１に保存されたバッチ印刷情報内を検索する。そして、該当のテナントＩＤに紐づく秘密鍵を特定し取得する。そして、バッチ印刷情報管理モジュール５０６は、取得した秘密鍵およびテナントＩＤを認証情報検証モジュール５０９に渡す。

ステップ１５１２でサービス提供サーバＡ５００の認証情報検証モジュール５０９は、ステップ１５１０で受信したダイジェスト認証のレスポンスの妥当性を検証する。認証情報検証モジュール５０９は、ステップ１５１０で受信したダイジェスト認証のレスポンス（Ａｕｔｈｏｒｉｚａｔｉｏｎリクエストヘッダ）のｕｓｅｒｎａｍｅ１８０２、ｒｅａｌｍ１８０３、ｎｏｎｃｅ１８０４、ｃｎｏｎｃｅ１８０６およびステップ１５１１で渡された秘密鍵を、認証情報付加モジュール５５３６、５５４６でのレスポンス生成時と同じ方法で結合し、ａｌｇｏｒｉｔｈｍ１８０５に指定された「ＳＨＡ−２５６」でダイジェスト化する。認証情報検証モジュール５０９は、そのダイジェスト化された値と、ダイジェスト認証のレスポンスのｒｅｓｐｏｎｓｅ１８０７の値とを比較して、一致するかで妥当性を検証する。一致すれば妥当であるとみなす。ダイジェスト認証のレスポンスが妥当と判断された場合、図１５Ｂのステップ１５１５に遷移する。レスポンスが不正と判断された場合、サービス提供サーバＡ５００のページ生成モジュール５０４はエラー画面を生成し、サービス提供サーバＢ５５０へ送信する。この場合、バッチ印刷のスケジュールジョブはここで中断される。

ここで前述のように図１５Ａの処理では秘密鍵を、ダイジェスト認証を行うための識別子として用いた。よって、図１５Ａでは秘密鍵そのもので復号化・暗号化を行わない例について示した。しかし、これに限らずダイジェスト認証のレスポンスそのものを秘密鍵で暗号化・復号化するように構成しても構わない。

以上のステップで、サービス提供サーバＡ５００でのバッチ印刷の受付が完了する。

図１５Ｂを用いて図１５Ａの続きであるサービス提供サーバＡ５００が受け付けたバッチ印刷の実行を行うフローについて説明する。

ステップ１５１５でサービス提供サーバＡ５００のバッチ印刷情報管理モジュール５０６は、ステップ１５１０で受信したＵＲＬパラメータ「ｔｅｎａｎｔ＿ＩＤ」の値をキーとして、ＨＤ２１１に保存されたバッチ印刷情報内を検索する。そして、該当のテナントＩＤに紐づくサーバＢアクセストークンを特定し取得する。

ステップ１５１６でサービス提供サーバＡ５００のバッチ印刷情報管理モジュール５０６は、ステップ１５１０で受信したＵＲＬパラメータ「ｔｅｎａｎｔ＿ＩＤ」の値をキーとして、ＨＤ２１１に保存されたバッチ印刷情報内を検索する。そして、該当のテナントＩＤに紐づくサーバＣアクセストークンを特定し取得する。

ステップ１５２０で、サービス提供サーバＡ５００のアクセストークン検証モジュール５１０は、ステップ１５１６で取得したサーバＣアクセストークンを指定して認証サーバＡ４００のアクセストークン有効性検証ＡＰＩを呼び出し、有効であるかを検証する。前記ステップ１５１９の文書生成は、取得した業務データが大量にある場合などに時間がかかる。このため、本ステップ１５２０にてサーバＣアクセストークンの有効性を事前に検証する。

ステップ１５２１で認証サーバＡ４００は、アクセストークン有効性検証ＡＰＩが呼び出されると、指定されたアクセストークンが有効かどうかを検証して、検証結果をサービス提供サーバＡ５００に返す。取得した検証結果がサーバＣアクセストークンは有効であることを示す場合、ステップ１５１７に遷移し、有効でない（すなわち無効である）場合、図１６のステップ１６０７に遷移する。有効でない場合のフローについては図１６で別途説明する。

ステップ１５１７で、サービス提供サーバＡ５００のデータ取得モジュール５０２は、サービス提供サーバＢ５５０に対して業務データの取得要求（クエリ）を行う。サービス提供サーバＢ５５０が公開するＷｅｂサービスＡＰＩのパラメータに対して、ステップ１５１５で取得したサーバＢアクセストークンを指定することで業務データの取得が可能となる。

ステップ１５１８でサービス提供サーバＢ５５０は、業務データ取得のＡＰＩ要求を受けて、サービス提供サーバＡ５００へ業務データを送信する。

ステップ１５１９で、サービス提供サーバＡ５００の文書生成モジュール５０３は、不図示のフォーム管理モジュールが管理するフォームを取得して、前記取得した業務データと前記取得したフォームから文書を生成する。ここでフォームは図６のスケジュールジョブ登録画面６０１で設定したものを用いる。

ステップ１５１９の処理の後に再度ステップ１５２０とステップ１５２１が行われる。これによりサービス提供サーバＡ５００はサーバＣアクセストークンの検証結果を再度取得する。これはステップ１５１７から１５１９の処理に時間がかかった場合に、ステップ１５１７の直前までサーバＣアクセストークンが有効であったとしても、ステップ１５１９の直後ではサーバＣアクセストークンが無効になっている可能性があるためである。

なお、図１５Ｂではステップ１５２０と１５２１を２度行なっているが、どちらか一方のみを実行するように構成しても構わない。

ステップ１５２２でサービス提供サーバＡ５００の文書送信モジュール５０８は、サービス提供サーバＣ５６０に対して、ステップ１５１９で生成した文書を送信する。サービス提供サーバＣ５６０が公開するＷｅｂサービスＡＰＩのパラメータに対して、ステップ１５１６で取得したサーバＣアクセストークンを指定することで文書の送信が可能となる。

ステップ１５２３でサービス提供サーバＣ５６０のアクセス制御モジュール５６１は、文書を受信し、ステップ１５２４で文書印刷モジュール５６３がその文書を印刷する。ここで印刷とは文書をＰＤＬの形式に変換して、プリンタにＰＤＬを送信してそのＰＤＬに基づいてプリンタが印刷することを指す。

ステップ１５２５でサービス提供サーバＡ５００の文書送信モジュール５０８は、ブラウザ２２０に対して、文書の送信完了通知を返す。なお、本フローでは、サービス提供サーバＣ５６０での文書印刷（ステップ１５２４）の完了を待たずに、文書送信完了通知をブラウザ２２０へ返しているが、文書印刷の完了を待って、印刷完了通知をブラウザ２２０へ返すようにしてもよい。

ステップ１５２６でブラウザ２２０は、ステップ１５２４にて返された文書の送信完了通知を受理する。

以上でサービス提供サーバＡ５００、サービス提供サーバＣ５６０、サービス提供サーバＢ５５０および認証サーバＡ４００が実行するフローが終了する。

図１６は本実施の形態に係る、サービス提供サーバＡ５００が実行するフローである。本フローは図１５Ｂで説明した処理に加えて、業務データ取得に必要となるサーバＢアクセストークンおよび文書送信に必要となるサーバＣアクセストークンの期限が切れた場合の処理を示したフローである。なお、既に説明したステップと同じ処理については、既に説明したステップの番号と同一の番号を付与し、特に断りが無い限り説明は省略する。

ステップ１６２０はサーバＣアクセストークンの有効性を検証する処理を示している。以降、ステップ１６２０で行われる処理について説明する。

ステップ１６０７でサービス提供サーバＡ５００のアクセストークン検証モジュール５１０は、ステップ１５２０で認証サーバＡ４００から返されたサーバＣアクセストークンの有効性検証結果をもとに、サーバＣアクセストークンが有効であるかどうかを判断する。

有効な場合ステップ１５１７に遷移し、有効でない場合ステップ１６０８に遷移する。図１５Ｂを用いて説明したようにステップ１６２０のサーバＣアクセストークンの有効性を検証する処理は２度行われる。よって、ステップ１５１９の後に実行されるステップ１６２０のステップ１６０７で有効でないと判断された場合にはステップ１５２２に遷移する。

ステップ１６０８でサービス提供サーバＡ５００のバッチ印刷情報管理モジュール５０６は、図１１のステップ１１０８で保存されたサーバＣリフレッシュトークンを特定して取得する。バッチ印刷情報管理モジュール５０６は、ステップ１５１０で受信したＵＲＬパラメータ「ｔｅｎａｎｔ＿ＩＤ」の値をキーとしてＨＤ２１１のバッチ印刷情報内を検索し、該当のテナントＩＤに紐付くサーバＣリフレッシュトークンを特定する。

ステップ１６０９でサービス提供サーバＡ５００のアクセストークン取得モジュール５０５は、認証サーバＡ４００のサーバＣアクセストークンの再取得ＡＰＩを呼び出す。この際サービス提供サーバＡ５００のアクセストークン取得モジュール５０５は、ＡＰＩの呼び出しパラメータとして、ステップ１６０８で取得したサーバＣリフレッシュトークンを指定する。ＡＰＩ呼び出しを受け付けた認証サーバＡ４００は、リフレッシュトークンの検証を行い、有効であればサーバＣアクセストークンを再度発行し、そのトークンをＡＰＩの戻り値としてサービス提供サーバＡ５００に返す。

ステップ１６１１でステップ１６０９によるサーバＣアクセストークンの再取得が成功したかどうかを判断する。判断の結果、再取得が成功した場合はステップ１６１０に遷移し、再取得が成功しなかった場合はステップ１６１２に遷移して処理を中断する。

ステップ１６１０でサービス提供サーバＡ５００のバッチ印刷情報管理モジュール５０６は、ステップ１６０９で認証サーバＡ４００から再取得したサーバＣアクセストークンを、サービス提供サーバＡ５００のテナントＩＤに紐付けてＨＤ２１１に再保存する。

次にステップ１５１７の次のステップであるステップ１６０１について説明する。ステップ１６０１でサービス提供サーバＡ５００のデータ取得モジュール５０２は、ステップ１５１７での業務データ取得が成功したかどうかを判断する。成功した場合ステップ１５１９に遷移し、失敗した場合ステップ１６０２に遷移する。アクセストークンの期限が切れた場合やデータ取得のクエリに何らかの問題がある場合に、業務データ取得が失敗する場合がある。

ステップ１６０２でサービス提供サーバＡ５００のデータ取得モジュール５０２は、業務データが取得できなかった場合にサービス提供サーバＢ５５０から発行されるエラーを解析して、サーバＢアクセストークンの期限切れエラーかどうかを判断する。期限切れエラーの場合ステップ１６０３に遷移し、そうでない場合、何らかの理由（例えば存在しないテーブルをクエリで指定している等）で業務データが取得できないと判断し、ステップ１６０６でフローを中断する。

ステップ１６０３でサービス提供サーバＡ５００のバッチ印刷情報管理モジュール５０６は、図１３のステップ１３１３で保存されたサーバＢリフレッシュトークンを特定して取得する。バッチ印刷情報管理モジュール５０６は、ステップ１５１０で受信したＵＲＬパラメータ「ｔｅｎａｎｔ＿ＩＤ」の値をキーとしてＨＤ２１１のバッチ印刷情報内を検索し、該当のテナントＩＤに紐づくサーバＢリフレッシュトークンを特定する。

ステップ１６０４でサービス提供サーバＡ５００のアクセストークン取得モジュール５０５は、認証サーバＢ４５０に対して、サーバＢアクセストークンの再取得リクエストを行う。この際サービス提供サーバＡ５００のアクセストークン取得モジュール５０５は、リクエストのＵＲＬパラメータとして、ステップ１６０３で取得したリフレッシュトークンを含める。リクエストを受けた認証サーバＢ４５０は、リフレッシュトークンの検証を行い、有効であればサーバＢアクセストークンを再度発行し、そのトークンをレスポンスに含めてサービス提供サーバＡ５００に返す。

ステップ１６０５でサービス提供サーバＡ５００のバッチ印刷情報管理モジュール５０６は、ステップ１６０４で認証サーバＢ４５０から再取得したサーバＢアクセストークンを、サービス提供サーバＡ５００のテナントＩＤに紐付けてＨＤ２１１に再保存する。

［実施例２］
次に、本発明を実施するための第２の形態について図面を用いて説明する。なお第１の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。

図１９は本実施の第２の形態に係る、サービス提供サーバＡ５００が実行するフローである。なお、既に説明したステップと同じ処理については、既に説明したステップの番号と同一の番号を付与し、特に断りが無い限り説明は省略する。ステップ１９０１でサービス提供サーバＡ５００は、受け付けたリクエストが、サービス提供サーバＢ５５０からのバッチ印刷要求なのか、ブラウザ２２０からのユーザ操作による印刷要求なのかを判断する。判断は、リクエストのＵＲＬパラメータとしてパラメータ「ｓｅｓｓｉｏｎｉｄ」にサービス提供サーバＢ５５０の認証ユーザのセッションＩＤが含まれているかどうかで行う。セッションＩＤが含まれていない場合、バッチ印刷要求と判断しステップ１５０３に遷移し、セッションＩＤが含まれていた場合、ユーザ操作による印刷要求と判断し、ステップ１９０２に遷移する。ステップ１９０２でサービス提供サーバＡ５００は、前記セッションＩＤを用いてサービス提供サーバＢ５５０にアクセスし、業務データの取得を行い、ステップ１９０３で文書の生成を行う。ステップ１９０４でサービス提供サーバＡ５００は、前記ステップ１９０３で生成された文書をサービス提供サーバＣ５６０へ送信し印刷要求リクエストを発行する。サービス提供サーバＣ５６０への文書送信にはユーザ認証が必要になるが、印刷要求リクエストのＵＲＬパラメータとしてパラメータ「ＡＵＴＨ＿ＩＤ」にサービス提供サーバＣ５６０の認証セッションＩＤが含まれている。文書送信時にはその認証セッションＩＤを使用するものとする。

本実施の第２の形態によれば、サービス提供サーバＢ５５０からのバッチ印刷要求と、通常のブラウザ２２０からのユーザ操作による印刷要求とが混在した場合でも、サービス提供サーバＡ５００の構成を変更する事無く、両方の要求に応答することが可能となる。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。

即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

２００ クライアントＰＣ
４００ 認証サーバＡ
４５０ 認証サーバＢ
５００ サービス提供サーバＢ

Claims (11)

1. 識別子を第１の外部情報処理装置から受け付ける受付手段と、
   前記識別子に基づいて、前記第１の外部情報処理装置からデータを取得するための第１のトークンと、認証処理装置で検証結果を取得するための第２のトークンを特定する特定手段と、
   前記第１のトークンを用いて前記第１の外部情報処理装置からデータを取得して、取得した前記データから文書を生成する生成手段と、
   前記第２のトークンを前記認証処理装置に送信することで、前記認証処理装置から前記第２のトークンの前記検証結果を取得する取得手段と、
   前記第２のトークンを用いて第２の外部情報処理装置に生成した前記文書を送信する送信手段と、を有することを特徴とするサーバーシステム。
2. 前記取得手段は、前記生成手段による前記文書の生成の前に前記第２のトークンの検証結果を取得して、前記生成手段による前記文書の生成の後に前記第２のトークンの検証結果を再度取得することを特徴とする請求項１に記載のサーバーシステム。
3. 前記第２の外部情報処理装置は、前記文書を変換して、変換された文書をプリンタに送信することを特徴とする請求項１又は請求項２に記載のサーバーシステム。
4. 前記第１の外部情報処理装置からバッチ印刷の要求を受け付けた場合に、前記第１の外部情報処理装置の認証を行う認証手段と、を有し、
   前記受付手段は前記認証のレスポンスとして前記識別子を受け付けることを特徴とする請求項１に記載のサーバーシステム。
5. 前記取得手段が取得した前記検証結果が前記第２のトークンは有効であることを示す場合に、前記生成手段は、前記第１のトークンを用いて前記第１の外部情報処理装置からデータを取得して、取得した前記データから文書を生成することを特徴とする請求項１に記載のサーバーシステム。
6. コンピュータに、
   識別子を第１の外部情報処理装置から受け付ける受付工程と、
   前記識別子に基づいて、前記第１の外部情報処理装置からデータを取得するための第１のトークンと、認証処理装置で検証結果を取得するための第２のトークンを特定する特定工程と、
   前記第１のトークンを用いて前記第１の外部情報処理装置からデータを取得して、取得した前記データから文書を生成する生成工程と、
   前記第２のトークンを前記認証処理装置に送信することで、前記認証処理装置から前記第２のトークンの前記検証結果を取得する取得工程と、
   前記第２のトークンを用いて第２の外部情報処理装置に生成した前記文書を送信する送信工程と、を実行させることを特徴とするプログラム。
7. 前記取得工程は、前記生成工程による前記文書の生成の前に前記第２のトークンの検証結果を取得して、前記生成工程による前記文書の生成の後に前記第２のトークンの検証結果を再度取得することを特徴とする請求項６に記載のプログラム。
8. 前記第２の外部情報処理装置は、前記文書を変換して、変換された文書をプリンタに送信することを特徴とする請求項６又は請求項７に記載のプログラム。
9. 前記コンピュータに、
   前記第１の外部情報処理装置からバッチ印刷の要求を受け付けた場合に、前記第１の外部情報処理装置の認証を行う認証工程と、を実行させ、
   前記受付工程は前記認証のレスポンスとして前記識別子を受け付けることを特徴とする請求項６に記載のプログラム。
10. 前記取得工程で取得した前記検証結果が前記第２のトークンは有効であることを示す場合に、前記生成工程は、前記第１のトークンを用いて前記第１の外部情報処理装置からデータを取得して、取得した前記データから文書を生成することを特徴とする請求項６に記載のプログラム。
11. 識別子を第１の外部情報処理装置から受け付ける受付工程と、
    前記識別子に基づいて、前記第１の外部情報処理装置からデータを取得するための第１のトークンと、認証処理装置で検証結果を取得するための第２のトークンを特定する特定工程と、
    前記第１のトークンを用いて前記第１の外部情報処理装置からデータを取得して、取得した前記データから文書を生成する生成工程と、
    前記第２のトークンを前記認証処理装置に送信することで、前記認証処理装置から前記第２のトークンの前記検証結果を取得する取得工程と、
    前記第２のトークンを用いて第２の外部情報処理装置に生成した前記文書を送信する送信工程と、を有することを特徴とする制御方法。

Images