JP2017107342A - 認証連携システム及び認証連携方法、認可サーバー、アプリケーションサーバー及びプログラム - Google Patents

Abstract

【課題】ローカル認証とクラウドサービス認証との間でユーザーＩＤプロビジョニングする必要がない認証連携システム及び認証連携方法、認可サーバー、アプリケーションサーバー及びプログラムを提供する。
【解決手段】認可トークン生成要求を受信した認可サーバー１０６は、受信した認可トークンリクエストＳ１０．４（クライアントＩＤ、シークレット、スコープ）が認可サーバーが管理するクライアント情報に存在するならば、業務サーバー１０５への認可トークン生成応答として認可トークンを送信し、認可トークンとクライアント情報とを紐付けて管理する。認可トークン検証要求Ｓ１０．６を受信した認可サーバーは、パラメータとして受信した認可トークンとスコープに基づいた検証が成功した場合には、帳票サーバー１０７への認可トークン検証応答として、受信した認可トークンに紐付けて管理されるクライアント情報に基づいて認可トークン情報を送信する。
【選択図】図１４

Description

本発明は、たとえばクラウドサービスにおけるサービスとローカルサービスとの認証連携システム及び認証連携方法、認可サーバー、アプリケーションサーバー及びプログラムに関する。

近年、サーバーをインターネットに公開しクライアントにサービスを提供するクラウドコンピューティングサービス（或いはクラウドサービス）の形態が注目を集めている。クラウドコンピューティングサービスは、多くのコンピューティング・リソースを用いてデータ変換やデータ処理を分散実行し、多くのクライアントからの要求を分散並列処理により並行して処理することが主な特徴である。現在、このクラウドコンピューティングサービスを実現するクラウドコンピューティングサービス環境上にＷｅｂサービスを実装し、多種多様なサービスをＷｅｂ上で提供するベンダーが乱立しつつある。クラウドサービスの開発において、すでにＷｅｂ上に多く提供されているサービスを有効活用し新しい機能を提供することで、開発スピードや開発コストの面で優位になる。一方で事業者等は従来自らがサーバー等を保有し、運用する自社運用システム（以下、オンプレミスシステムとも呼ぶ。）が数多く運用されている。すべての社内システムをまとめてクラウドサービスに移行することは難しく、その結果、一部のオンプレミスシステムから段階的にクラウドサービスに移行するなど、オンプレミスサービスとクラウドサービスを連携させ両方を利用するユーザーが増えてきている。

特表２０１５−５１８１９８号公報

オンプレミスサービスとクラウドサービスを連携する場合、従来のオンプレミスのようなローカル認証（ＬＤＡＰなど）とクラウドの認証とが異なるため、シングルサインオン（Ｓｉｎｇｌｅ Ｓｉｇｎ Ｏｎ、以下ＳＳＯとも呼ぶ）が強く望まれる。従来技術ではオンプレミスのローカル認証をクラウドサービスに構築されたローカル認証サービスに同期し、クラウドサービスとオンプレミスのログインサービスの両方にログインすることでユーザーＩＤプロビジョニングを開始する。たとえばユーザーＩＤ等、ユーザーアカウントに関する情報の生成や保守などの管理を開始する。その後、ユーザーはクラウドサービスのローカル認証サービスにＶＰＮを使ってログインすると、ユーザーに紐づいたクレデンシャル情報でクラウドサービスにもログインできる。

しかしながら、ローカル認証とクラウドサービス認証とを連携するために全ユーザーのユーザーＩＤプロビジョニングが必要であるという課題があった。またユーザーの増減のたびにユーザーＩＤプロビジョニングをメンテナンスする必要があるためユーザー管理の運用コストが高くなってしまうという課題があった。

本発明は上記従来例に鑑みて成されたもので、ローカル認証とクラウドサービス認証との間でユーザーＩＤプロビジョニングする必要がない認証連携システム及び認証連携方法、認可サーバー、アプリケーションサーバー及びプログラムを提供することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。

本発明の一側面によれば、本発明は、認可トークン生成リクエストに応じてクライアント情報に基づいたクライアントの認証が成功した場合には、前記クライアントに対して認可トークンを応答し、前記認可トークン生成リクエストとともに受信したローカルユーザー情報を前記認可トークンと関連付けた認可トークン情報を生成して格納する手段と、
前記クライアントから前記認可トークンとともに処理リクエストを受けたアプリケーションサーバーから、前記認可トークンを含む認可トークン検証リクエストを受信し、受信した前記認可トークンと前記認可トークン情報とに基づいた認可トークンの検証が成功した場合には、前記認可トークン情報に含まれる前記ローカルユーザー情報を前記アプリケーションサーバーへ応答する応答手段と
を有することを特徴とする認可サーバーにある。

他の側面によれば、本発明は、テナントごとのローカル認証連携モードを格納する手段と、
クライアントから認可トークンとともに処理リクエストを受信すると、認可サーバーに対して認可トークン検証リクエストを送信し、前記認可トークン検証リクエストが成功した応答として、前記認可トークンと関連付けられたローカルユーザー情報を含む認可トークン情報を受信する手段と、
前記ローカルユーザー情報で示されるユーザーまたは前記クライアントに対して前記処理リクエストを処理する処理手段と
を有することを特徴とするアプリケーションサーバーにある。

さらに他の側面によれば、本発明は、認可サーバーとアプリケーションサーバーとを含む認証連携システムであって、
前記認可サーバーは、
認可トークン生成リクエストに応じてクライアント情報に基づいたクライアントの認証が成功した場合には、前記クライアントに対して認可トークンを応答し、前記認可トークン生成リクエストとともに受信したローカルユーザー情報を前記認可トークンと関連付けた認可トークン情報を生成して格納する手段と、
前記クライアントから前記認可トークンとともに処理リクエストを受けたアプリケーションサーバーから、前記認可トークンを含む認可トークン検証リクエストを受信し、受信した前記認可トークンと前記認可トークン情報とに基づいた認可トークンの検証が成功した場合には、前記認可トークン情報に含まれる前記ローカルユーザー情報を前記アプリケーションサーバーへ応答する応答手段とを有し、
前記アプリケーションサーバーは、
クライアントから前記認可トークンとともに処理リクエストを受信すると、前記認可サーバーに対して前記認可トークン検証リクエストを送信し、前記認可トークン検証リクエストが成功した応答として、前記認可トークンと関連付けられた前記ローカルユーザー情報を含む前記認可トークン情報を受信する手段と、
前記ローカルユーザー情報で示されるユーザーまたは前記クライアントに対して前記処理リクエストを処理する処理手段と
を有することを特徴とする。

本発明によれば、ローカル認証とクラウドサービス認証との間でＩＤプロビジョニングする必要もないため運用負荷を下げることができる。

システム構成図 各装置のハードウェア構成図 ローカル認証サーバーで管理するテーブル構造を示す図 業務サーバーで管理するテーブル構造を示す図 認可サーバーで管理するテーブル構造を示す図 帳票サーバーで管理するテーブル構造を示す図 データ変換サーバーで管理するテーブル構造を示す図 ストレージサーバーで管理するテーブル構造を示す図 モバイル端末の画面例を示す図 帳票ＳＶＧ生成フローを示す図 認可トークン発行フローを示す図 認可トークン利用フローを示す図 各装置のソフトウェア構成図 帳票ＳＶＧの生成フローを時系列に示すシーケンス図 帳票ＳＶＧの生成フローを時系列に示すシーケンス図

以下、本発明を実施するための形態について図面を用いて説明する。
［実施形態１］
＜システム構成＞
図１は、本発明の実施形態に係る認証連携システムを含むモバイル印刷システムの全体構成を示す図である。図１において、モバイル端末１０２はローカルネットワーク１０１を介して１台又は複数台接続されている。モバイル端末１０２は、ローカルネットワーク１０１を介してインターネットワーク１００にアクセスし、サーバー１０４〜１０９にアクセスすることができる。モバイル端末１０２は有線または無線ＬＡＮを介してネットワークに接続する。本実施形態では、モバイル端末１０２は無線ＬＡＮアクセスポイント１０３を介してネットワークに接続することを想定しているが、携帯データ通信キャリアが提供する無線ネットワークを介して接続する場合も本実施形態に含まれる。無線ＬＡＮアクセスポイント１０３は、一般的なネットワーク・ルーター機能を有した無線ＬＡＮの親機であり、家庭内や事務所などの中で無線ＬＡＮを提供している。なおモバイル端末のことを、クライアント端末あるいはクライアントあるいは端末と呼ぶこともある。

セキュリティドメイン１１０〜１１２は認証・認可されたユーザーのアクセス可能範囲を示しておりセキュリティドメインを越えて認証・認可したユーザーや認可トークンを利用することはできない。すなわち認証や認可の効力の範囲を示すともいえる。ローカル認証セキュリティドメイン１１０はローカル認証サーバー１０４で認証されたユーザーでアクセス可能な範囲を示しており、業務サーバー１０５が属する。帳票サービスセキュリティドメイン１１１は認可サーバー１０６で発行された認可トークンでアクセス可能な範囲を示しており、帳票サーバー１０７やデータ変換サーバー１０８が属する。ストレージサービスセキュリティドメイン１１２は不図示のストレージサービスセキュリティドメイン認可サーバーで発行された認可トークンでアクセス可能な範囲を示しており、ストレージサーバー１０９が属する。図１においては、ローカル認証セキュリティドメイン１１０がオンプレミスシステムであり、帳票サービスセキュリティドメイン１１１およびストレージサービスセキュリティドメイン１１２がクラウドシステムに相当する。

ローカル認証サーバー１０４は業務サーバー１０５へアクセスするためのユーザー認証を実現するためのサーバーである。ユーザーはローカル認証サーバー１０４で認証されることで業務サーバー１０５にアクセスすることができる。ローカル認証方式としてＬＤＡＰが用いられることが多いが、本実施形態ではユーザー名、パスワード、ドメインの一致を確認するのみの簡易的な認証方式とする。これは説明の便宜であって、ユーザーごとに固有の認証情報を用いてユーザー認証を行う他の認証方式についても本実施形態の発明を適用することができる。

業務サーバー１０５はユーザー業務情報を管理するサーバーである。本実施形態では販売する製品を業務サーバー１０５で顧客毎に管理し、販売員が業務サーバー１０５の情報を用いて顧客に対して営業を行うユースケースを想定している。業務サーバー１０５はモバイル端末１０２からのリクエストに応じてユーザー業務情報を表示・編集するための画面を提供する。認可サーバー１０６はＯＡｕｔｈを実現するためのサーバーでありクライアント情報の管理や認可トークンの発行・管理を行う。帳票サーバー１０７は業務サーバー１０５からユーザー業務情報を受け取り、帳票テンプレートにユーザー業務情報を反映させて帳票ＰＤＦを生成し管理するサーバーである。そして帳票サーバー１０７はデータ変換サーバー１０８に生成した帳票ＰＤＦを帳票ＳＶＧに変換するリクエストを行う。データ変換サーバー１０８は、帳票サーバー１０７から帳票ＳＶＧ変換リクエストを受け付け、帳票ＰＤＦを帳票ＳＶＧにデータ変換し管理するサーバーである。ストレージサーバー１０９はファイル管理を行うサーバーであり、モバイル端末１０２や帳票サーバー１０７、データ変換サーバー１０８からのファイルアップロード／ダウンロードを受け付ける。なお、ＯＡｕｔｈは、ユーザーの権限をそのユーザーの同意を前提としてサービス間で安全に受け渡す（すなわち委譲する）ための仕組みであり、その仕組みを実現するサーバーが認可サーバー１０６である。たとえばＯＡｕｔｈによりユーザーが第１のサーバーで許諾された権限の全部または一部を第２のサーバーに委譲することで、第２のサーバーは、そのユーザーの権限の範囲内で第１のサーバーによるサービスを受けることができる。ＯＡｕｔｈによれば、ユーザーは、第１のサーバーにログインするための認証情報を第２のサーバーに教える必要がない。

ここで、サーバー１０６〜１０９の各サーバーはそれぞれ複数台のサーバーで冗長化されたクラウドサービスとしてインターネット上に公開されるが、本実施形態では説明を簡略化するため、それぞれ１台構成としている。またローカル認証サーバー１０４と業務サーバー１０５も複数台のサーバーで冗長化された構成をとることもできるが、本実施例では説明を簡略化するため、それぞれ１台構成としている。また、クラウドサービスを実現する各サーバーのうち、認可サーバー１０６とストレージサーバー１０９とを除いた、クライアントに対してアプリケーションを提供するためのサーバーをまとめてアプリケーションサーバーと呼ぶこともある。

＜モバイル端末１０２のハードウェア構成＞
図２（ａ）はモバイル端末１０２のハードウェア構成図である。ハードウェアの各構成要素は、システムバス２０２に接続されている。 ＲＯＭ２０４にはオペレーティングシステム及び、通話、データ通信を制御するアプリケーションが格納されており、ＣＰＵ２０３で実行される。 データ通信を制御するアプリケーションとしては、ＭａｉｌソフトやＷｅｂブラウザなどがある。ＲＡＭ２０５は、プログラムを実行するためのワークメモリエリアである。また、ＷｅｂブラウザがＷｅｂサーバーから取得してきたＷｅｂページデータやＷｅｂサービスにアクセスするための認証情報などを一時記憶するためのメモリでもある。記憶装置２１０は不揮発性の記憶装置であり、モバイル端末の再起動後も保持しておく必要のある各種動作モード設定や、稼働ログなどが記憶される。ＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ２０６は、無線ＬＡＮ通信部２１２、携帯キャリアの提供するネットワークに参加するための携帯電話データ通信部２１３の通信制御を行う。一般的に無線ＬＡＮのネットワークに参加できるとき、ＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ２０６は、無線ＬＡＮの接続を優先する。モバイル端末が無線ＬＡＮのネットワークエリアから外れた場合には、携帯キャリアが提供する無線通信ネットワークへ参加する。音声制御部２０７は、主に通話アプリケーションが起動しユーザーが電話をしているときに利用する。マイク・スピーカ２１４にて音声データの入出力を行い、音声制御部２０７は、その制御プログラムとの仲介を行っている。表示制御部２０８は、モバイル端末のディスプレイ２１５にて出力する情報の制御を行っている。入力制御部２０９は、モバイル端末のボタンやタッチパネル２１６にてユーザーが指示した情報の制御を行っている。これらの音声制御部２０７、表示制御部２０８、入力制御部２０９を利用して、モバイル端末上でのアプリケーションは、ネットワーク通信情報やモバイル端末のさまざまな情報をユーザーに提供する。位置検出制御部２１１は、ＧＰＳセンサー２１７からモバイル端末の位置情報を取得しＯＳに提供する。これらの制御は、ＣＰＵ２０３で動くＯＳにて制御される。

＜サーバーのハードウェア構成＞
図２（ｂ）は、１０４〜１０９の各サーバーのハードウェア構成の一例を示す図である。特に断らない限り、本実施形態に係る発明の機能が実行可能であるならば、単体の機器であっても、複数の機器からなるシステムであっても、本実施形態に係る発明が適用できることは言うまでもない。また、特に断らない限り、本実施形態に係る発明の機能が実行可能であるならば、ＬＡＮ、ＷＡＮ等のネットワークを介して接続が為され、処理が行われるシステムであっても本発明を適用できることは言うまでもない。本実施形態ではシステムバス２１９により各構成要素が接続されているものとして説明する。

ＣＰＵ２２０は情報処理装置の制御装置であり、記憶装置２２６に格納されているアプリケーションプログラム、プリントドライバプログラム、オペレーティングシステムや本発明のモバイル印刷システムプログラムを実行する。また、ＣＰＵ２２０はＲＡＭ２２２にプログラム実行に必要な情報、ファイル等を一時的に格納する制御を行う。また、ＣＰＵ２２０はディスプレイ２２７上の不図示マウスカーソル等で指示されたコマンドに基づいて登録された種々のウインドウを開き、種々のデータ処理を実行する。ＲＯＭ２２１は固定された情報を記憶するＲＯＭであり、内部には基本Ｉ／Ｏプログラム等のプログラム、文書処理の際に使用するフォントデータ、テンプレート用データ等の各種データを記憶する。ＲＡＭ２２２は情報を一時記憶するＲＡＭであり、ＣＰＵ２２０の主メモリやワークエリア等として機能する。表示制御部２２４は、ディスプレイ２２７にて出力する情報の制御を行っている。入力制御部２２５は、キーボード２２８より入力される情報を制御し、情報処理装置は入力制御部２２５を介して外部装置とのデータのやり取りを行う。記憶装置２２６は外部記憶の一つで、大容量メモリとして機能し、アプリケーションプログラム、プリントドライバプログラム、ＯＳ等を格納している。キーボード２２８は指示入力部であり、ユーザーが各サーバーへの指示等を入力指示するためのものである。ディスプレイ２２７は表示部であり、キーボード２２８から入力したコマンド等を表示するものである。

＜モバイル端末１０２のソフトウェア構成＞
モバイル端末１０２およびサーバーのソフトウェア構成を、図１３を参照して説明する。モバイル端末１０２にはブラウザーアプリケーション（Ｗｅｂブラウザーとも呼ぶ。）１０２１がインストールされる。モバイル端末１０２にインストールされたブラウザーアプリケーション１０２１は図２（ａ）で示した記憶装置２１０に記憶されており、前述したようにＣＰＵ２０３によってＲＡＭ２０５にロードされ実行される。ユーザーはブラウザーアプリケーション１０２１がモバイル端末１０２のディスプレイ２１５に表示する画面を操作することにより、サーバー１０５〜１０９の各サーバーにリクエストを行う。ブラウザーアプリケーション１０２１は業務サーバー１０５や帳票サーバー１０７、ストレージサーバー１０９からのＨＴＭＬデータやＳＶＧデータを解析し画面に表示したりできる。後述する図９はブラウザーアプリケーション１０２１がモバイル端末１０２のディスプレイ２１５に表示する画面の一例である。モバイル端末１０２にはブラウザーアプリケーション以外にも様々なアプリケーションをインストールすることができる。本実施形態ではブラウザーアプリケーション１０２１のみを利用するため、以降の記載ではブラウザーアプリケーション１０２１をモバイル端末１０２として記載する。

＜ローカル認証サーバー１０４のソフトウェア構成＞
ローカル認証サーバー１０４は認証Ｉ／Ｆ、認証情報管理部１０４１、ローカル認証情報３００を格納するストレージを有している。各ソフトウェアモジュールは図２（ｂ）で示した記憶装置２２６に記憶されており、前述したようにＣＰＵ２２０によってＲＡＭ２２２にロードされ実行される。認証Ｉ／Ｆ１０４１はローカル認証サーバー１０４の各種インターフェースを提供し、受け付けた情報の妥当性の検証を行う。認証情報管理部１０４２は図３で説明するローカル認証情報３００を管理し、認証Ｉ／Ｆが受け付けたリクエストに応じて、ユーザー認証の成否を応答する。

＜業務サーバー１０５のソフトウェア構成＞
業務サーバー１０５はＷｅｂサーバー１０５１、業務情報管理部１０５２、クライアント情報４００およびテンプレート情報４１０を格納するストレージを有している。各ソフトウェアモジュールは図２（ｂ）で示した記憶装置２２６に記憶されており、前述したようにＣＰＵ２２０によってＲＡＭ２２２にロードされ実行される。Ｗｅｂサーバー１０５１は業務サーバー１０５の各種インターフェースを提供し、受け付けた情報の妥当性の検証を行い、ローカル認証サーバー１０４で認証を行う。業務情報管理部１０５２は、図４で説明するクライアント情報４００、テンプレート情報４１０を管理する。そしてまた業務情報管理部１０５２は、Ｗｅｂサーバー１０５１が受け付けたリクエストに応じて、後述の図９（ａ）や図９（ｂ）の業務画面を応答したり、帳票生成リクエストを受けて帳票サーバー１０７にプレビュー生成リクエストを行ったりする。

＜認可サーバー１０６のソフトウェア構成＞
認可サーバー１０６はＷｅｂサーバー１０６１、認可情報管理部１０６２、クライアント情報５００および認可トークン情報５１０を格納するストレージを有している。、各ソフトウェアモジュールは図２（ｂ）で示した記憶装置２２６に記憶されており、前述したようにＣＰＵ２２０によってＲＡＭ２２２にロードされ実行される。Ｗｅｂサーバー１０６１は認可サーバー１０６の各種インターフェースを提供し、受け付けた情報の妥当性の検証を行う。認可情報管理部１０６２は図５で説明するクライアント情報５００と認可トークン情報５１０を管理し、Ｗｅｂサーバー１０６１が受け付けたリクエストに応じて、認可トークンの発行・スコープ確認・有効期限確認などを行う。

＜帳票サーバー１０７のソフトウェア構成＞
帳票サーバー１０７は、Ｗｅｂサーバー１０７１、帳票生成部１０７２および帳票情報管理部１０７３、テンプレート情報６００、プレビュー情報６１０、テナント設定情報６２０を格納するストレージを有している。各ソフトウェアモジュールは図２（ｂ）で示した記憶装置２２６に記憶されており、前述したようにＣＰＵ２２０によってＲＡＭ２２２にロードされ実行される。Ｗｅｂサーバー１０７１は帳票サーバー１０７の各種インターフェースを提供し、受け付けた情報の妥当性の検証を行う。そして認可サーバー１０６に対して認可トークン検証リクエストや認可トークン情報取得リクエストを行う。帳票生成部はテンプレートに業務サーバー１０５から受け取った業務情報を反映させ帳票ＰＤＦを生成する。帳票生成部は生成した帳票ＰＤＦをストレージサーバー１０９にアップロードする。帳票情報管理部は図６で説明するテンプレート情報６００、プレビュー情報６１０、テナント設定情報６２０を管理し、Ｗｅｂサーバーが受け付けたプレビュー生成リクエストに応じて、帳票生成部で帳票ＰＤＦを生成し、データ変換サーバー１０８に帳票ＳＶＧ生成リクエストを行う。ストレージには、図６で説明する帳票サーバー１０７が保持している情報が格納されている。なおテナントとは、サービスリソースの提供先を区分する単位であり、ユーザーがクラウドサービスを利用し、管理する単位である。クライアントはクラウドサービスのユーザーであり、特定のテナントのクライアントとして動作し、ひとつのテナントで複数のクライアントが複数のサービスを利用するような構成があり得る。したがって本実施形態では、ローカル認証セキュリティドメイン１１０ではテナントの管理は行われず、クラウドサービスである帳票サービスセキュリティドメイン１１１ではテナントの管理が行われる。

＜データ変換サーバー１０８のソフトウェア構成＞
データ変換サーバー１０８は、Ｗｅｂサーバー１０８１、データ変換部１０８２およびデータ変換情報管理部１０８３、文書情報７００、データ変換情報７１０、テナント設定情報７２０を格納するストレージを有する。各ソフトウェアモジュールは図２（ｂ）で示した記憶装置２２６に記憶されており、前述したようにＣＰＵ２２０によってＲＡＭ２２２にロードされ実行される。Ｗｅｂサーバー１０８１はデータ変換サーバー１０８の各種インターフェースを提供し、受け付けた情報の妥当性の検証を行う。そして認可サーバー１０６に対して認可トークン検証リクエストや認可トークン情報取得リクエストを行う。データ変換部は帳票サーバー１０７がストレージサーバー１０９にアップロードした帳票ＰＤＦを受信し、帳票ＰＤＦを帳票ＳＶＧに変換を行う。データ変換部は生成した帳票ＳＶＧをストレージサーバー１０９にアップロードする。データ変換情報管理部は図７で説明する文書情報７００、データ変換情報７１０、テナント設定情報７２０を管理し、Ｗｅｂサーバーが受け付けた帳票ＳＶＧ生成リクエストに応じて、データ変換部で帳票ＳＶＧを生成する。ストレージは図７で説明するデータ変換サーバー１０８が保持している情報が格納されている。

＜ストレージサーバー１０９のソフトウェア構成＞
ストレージサーバー１０９はＷｅｂサーバー１０９１、ストレージ管理部１０９２、ファイル情報８００を格納するストレージを有する。各ソフトウェアモジュールは図２（ｂ）で示した記憶装置２２６に記憶されており、前述したようにＣＰＵ２２０によってＲＡＭ２２２にロードされ実行される。Ｗｅｂサーバー１０７１はストレージサーバー１０９の各種インターフェースを提供し、受け付けた情報の妥当性の検証を行う。そして不図示のストレージ認可サーバーに対して認可トークン検証リクエストを行う。ストレージ管理部は図８で説明するファイル情報８００を管理し、アップロードリクエストされたファイルの入出力を行う。ストレージは図８で説明するストレージサーバー１０９が保持している情報やストレージサーバー１０９受信したファイルが格納されている。

＜ローカル認証サーバー１０４が管理するデータ＞
図３はローカル認証サーバー１０４がストレージに記憶するデータテーブルである。これらのデータテーブルは、ローカル認証サーバー１０４のストレージではなく、インターネット１００やローカルネットワーク１０１を介して通信可能に構成された別のサーバーに記憶するように構成することもできる。ローカル認証サーバー１０４が保持するデータテーブルはローカル認証情報３００を含む。図３のローカル認証情報３００は、業務サーバー１０５にアクセス可能なユーザーのユーザー情報としてドメイン名（ドメイン識別情報）３０１、ユーザー名（ユーザー識別情報）３０２、パスワード３０３を含む。ローカル認証サーバー１０４は、ローカル認証の対象となるユーザーにより入力されたユーザー認証情報と、ローカル認証情報３００として登録されたユーザー認証情報の一致によりユーザーを認証する。ローカル認証情報３００は、ローカル認証セキュリティドメイン１１０内でローカルに通用する認証情報である。

＜業務サーバー１０５が管理するデータ＞
図４（ａ）、図４（ｂ）は業務サーバー１０５がストレージに記憶するデータテーブルである。これらのデータテーブルは、業務サーバー１０５のストレージではなく、インターネット１００やローカルネットワーク１０１を介して通信可能に構成された別のサーバーに記憶するように構成することもできる。業務サーバー１０５が保持するデータテーブルはクライアント情報４００とテンプレート情報４１０を含む。図４（ａ）のクライアント情報４００は業務サーバー１０５が帳票サーバー１０７にアクセスするための情報であり、認可サーバー１０６で発行される。クライアントＩＤ４０１はクライアントを一意に識別するためのクライアントの識別情報、シークレット４０２はクライアントＩＤ４０１に対応したパスワードである。スコープ４０３はクライアントのアクセス権限の範囲を示す文字列である。図４（ａ）の例では、文字列「ＳＶＧ＿Ｐｒｅｖｉｅｗ」はたとえば、ＳＶＧ文書データのプレビュー要求がアクセス権限の範囲に含まれることを示す。図４（ｂ）のテンプレート情報４００は業務サーバー１０５が帳票サーバー１０７にプレビュー生成リクエストを行う際に指定するテンプレートＩＤ４１１を含む。テンプレートＩＤ４１１は帳票サーバー１０７のテンプレート情報６００に登録されているものを業務サーバー１０５が保持する。

＜認可サーバー１０６のデータ＞
図５（ａ）、図５（ｂ）は認可サーバー１０６がストレージに記憶するデータテーブルである。これらのデータテーブルは、認可サーバー１０６のストレージではなく、インターネット１００やローカルネットワーク１０１を介して通信可能に構成された別のサーバーに記憶するように構成することもできる。認可サーバー１０６が保持するデータテーブルは、クライアント情報５００、認可トークン情報５１０を含む。

図５（ａ）のクライアント情報５００にはサーバー１０６〜１０８にアクセス可能なクライアントの情報が含まれている。本実施形態においてクライアント情報５００には、業務サーバー１０５の情報がクライアントとして登録されている。クライアントＩＤ５０１は、クライアントを一意に識別するための識別子である。本実施形態では業務サーバー１０５のクライアントＩＤであるｃｌｉｅｎｔ０００１が登録されている。シークレット５０２はクライアントの正当性を判断するためのパスワードである。認可サーバー１０６は、クライアントから受信したクライアントＩＤとシークレットの組と、クライアント情報のクライアントＩＤ５０１とシークレット５０２の組との一致によりクライアントを特定する。スコープ５０３はＯＡｕｔｈのスコープであり認可サーバー１０６が発行する認可トークンでアクセス可能な範囲を示す。本実施形態のスコープ５０３の種類はＳＶＧ＿Ｐｒｅｖｉｅｗを定義する。ＳＶＧ＿Ｐｒｅｖｉｅｗスコープは業務サーバー１０が帳票サーバー１０７のインターフェースにアクセスする際に必要なスコープである。テナントＩＤ５０４は顧客テナントを一意に識別する識別子である。

図５（ｂ）の認可トークン情報５１０は、認可サーバー１０６により認可トークン取得リクエストを受け付けた際に生成される。１つのリクエストについて１レコードが生成される。認可トークン５１１は認可トークンを一意に識別可能な識別子である。有効期限５１２は認可トークンの有効期限であり認可トークン取得リクエスト受信時間から一定時間後の値が登録される。有効期限５１２を過ぎた認可トークン５１１は無効である。スコープ５１３は認可トークン５１１が利用可能なスコープであり、認可サーバー１０６への認可トークン取得リクエストで渡されるスコープが登録される。クライアントＩＤ５１４には認可サーバー１０６への認可トークン取得リクエストで渡されるクライアントＩＤが登録される。アプリケーションＩＤ５１５はクライアントが複数アプリケーションで利用される場合に各アプリケーションを識別する識別子である。アプリケーションＩＤ５１５は認可サーバー１０６への認可トークン取得リクエストでアプリケーションＩＤが渡された場合に登録される。認可サーバー１０６への認可トークン取得リクエストでアプリケーションＩＤが渡されなかった場合は登録されない。本実施形態では、業務サーバー１０５から認可サーバー１０６への認可トークン取得リクエストにおいてアプリケーションＩＤにローカルユーザー情報（ユーザー名３０２＠ドメイン名３０１）が指定され、アプリケーションＩＤ５１５として登録される。なお図３に示されたローカル認証情報からパスワードを除いたユーザー名とドメイン名とを除いた情報をローカルユーザー情報と呼ぶことにする。

＜帳票サーバー１０７が管理するデータ＞
図６（ａ）、図６（ｂ）、図６（ｃ）は、帳票サーバー１０７が外部メモリに記憶するデータテーブルである。これらのデータテーブルは、帳票サーバー１０７の外部メモリではなく、インターネット１００やローカルネットワーク１０１を介して通信可能に構成された別のサーバーに記憶するように構成することもできる。帳票サーバー１０７が保持するデータテーブルはテンプレート情報６００とプレビュー情報６１０とを含む。

図６（ａ）のテンプレート情報６００は帳票サーバー１０７が保持するテンプレートを管理する情報である。テンプレートＩＤ６０１はテンプレートを一意に識別する識別子であり、帳票サーバー１０７にテンプレートが登録された際に発行される。テナントＩＤ６０２はテンプレートを登録したテナントのテナントＩＤである。帳票サーバー１０７はテンプレートに対するアクセスをテナントＩＤ６０２毎に制御する。テンプレートＵＲＬパス６０３はテンプレートが保存されているストレージサーバー１０９のＵＲＬパスである。帳票サーバー１０７はテンプレートＩＤ６０１を含むＵＲＬパスで示されるフォルダ（及びファイル）をストレージサーバー１０９に生成し、そこにテンプレートを保存する。

図６（ｂ）のプレビュー情報６１０は帳票サーバー１０７がプレビュー処理を管理する情報である。プレビューＩＤ６１１は帳票サーバー１０７がプレビュー生成リクエストを受け付けた際に発行し登録する。テナントＩＤ６１２はプレビュー生成リクエストの要求元のテナントのテナントＩＤである。ユーザーＩＤ６１３はプレビュー生成リクエストの要求元のユーザーの識別子である。ユーザーＩＤ６１３には、本例では、テナントＩＤとローカルユーザー情報（ユーザー名３０２＠ドメイン名３０１）とを組み合わせた識別情報が登録される。このローカルユーザー情報は認可トークン情報５１０に含まれるアプリケーションＩＤ５１５に対応する。データ変換ＩＤ６１４は、帳票サーバー１０７が、データ変換サーバー１０８への帳票ＳＶＧ生成リクエストに対する応答で受信する、データ変換処理を識別する識別子である。帳票ＰＤＦＵＲＬパス６１５は帳票ＰＤＦが保存されているストレージサーバー１０９のＵＲＬパスである。帳票サーバー１０７はプレビューＩＤ６１１を含むＵＲＬパスで示されるフォルダ（及びファイル）をストレージサーバー１０９に生成し、そこに帳票ＰＤＦを保存する。

図６（ｃ）のテナント設定情報６２０は帳票サーバー１０７におけるテナント毎の設定情報である。テナントＩＤ６２１の設定としてローカル認証連携モード６２２を保持する。ローカル認証連携モード６２２はローカル認証セキュリティドメイン１１０との連携をするか否かをｔｒｕｅ／ｆａｌｓｅで示す。たとえばｔｒｕｅは連携することを、ｆａｌｓｅは連携しないことを示す。テナント設定情報はサーバーごとに設定されてもよいが、特定のサーバーに設定されたテナント共有情報を複数のサーバーで共有するよう構成してもよい。そのために例えば、特定のサーバーでテナント設定情報が更新されたなら、それを他のサーバーに分配するように構成してもよい。

＜データ変換サーバー１０８が管理するデータ＞
図７（ａ）、図７（ｂ）、図７（ｃ）はデータ変換サーバー１０８が外部メモリに記憶するデータテーブルである。データ変換サーバー１０８が保持するデータテーブルは、文書情報７００、データ変換情報７１０、テナント設定情報７２０を含む。

図７（ａ）の文書情報７００は、データ変換サーバー１０８により帳票ＳＶＧ生成リクエスト受信時に生成される。１つのリクエストについて１レコードが生成される。文書ＩＤ７０１は、データ変換サーバー１０８が帳票ＳＶＧ生成リクエストを受信した際に発行する、文書を一意に識別する識別子である。テナントＩＤ７０２は帳票ＳＶＧ生成リクエストした要求元のテナントのテナントＩＤである。ユーザーＩＤ７０３は帳票ＳＶＧ生成リクエストした要求元のユーザーの識別子である。ユーザーＩＤ７０３には、クライアントＩＤとローカルユーザー情報（ユーザー名３０２＠ドメイン名３０１）との組み合わせが登録される。文書ＵＲＬ７０４は帳票ＰＤＦが保存されているストレージサーバー１０９のＵＲＬパスである。帳票サーバー１０７からの帳票ＳＶＧ生成リクエストのパラメータとしてデータ変換サーバー１０８に渡される。

図７（ｂ）のデータ変換情報７１０は、データ変換サーバー１０８により帳票ＳＶＧ生成リクエスト受信時に生成される。１つのリクエストについて１レコードが生成される。データ変換ＩＤ７１１は、データ変換サーバー１０８が帳票ＳＶＧ生成リクエストを受信した際に発行する、データ変換処理を一意に識別する識別子である。テナントＩＤ７１２、ユーザーＩＤ７１３、文書ＩＤ７１４は、データ変換サーバー１０８がデータ変換リクエスト受信時に生成する文書情報７００のテナントＩＤ７０２、ユーザーＩＤ７０３、文書ＩＤ７０１とそれぞれ同じ値である。インデックスＵＲＬ７１５は、データ変換サーバー１０８が生成する帳票ＳＶＧのＵＲＬリストであるインデックスファイルを保存するストレージサーバー１０９のＵＲＬである。生成した帳票ＳＶＧが複数ページだった場合には、複数の帳票ＳＶＧのストレージサーバー１０９上のＵＲＬがインデックスファイルに記載される。インデックスＵＲＬ７１５はデータ変換サーバー１０８が帳票ＳＶＧ生成完了時にストレージサーバー１０９で一意になるようＵＲＬパスにデータ変換ＩＤ７１１を含めて生成され保存される。ステータス７１６はデータ変換サーバー１０８のデータ変換状況を示しており、データ変換サーバー１０８がデータ変換状況に応じて更新する。ステータス７１６には"待機中"や"変換済み"がある。

図７（ｃ）のテナント設定情報７２０はデータ変換サーバー１０８におけるテナント毎の設定情報である。テナント設定情報７２０は帳票サーバー１０７のテナント設定情報６２０と同様の情報である。

＜ストレージサーバー１０９のデータ＞
図８はストレージサーバー１０９が外部メモリに記憶するデータテーブルである。これらのデータテーブルは、ストレージサーバー１０９の外部メモリではなく、インターネット１００やローカルネットワーク１０１を介して通信可能に構成された別のサーバーに記憶するように構成することもできる。ストレージサーバー１０９が保持するデータテーブルはファイル情報８００を含む。図８のファイル情報８００はストレージサーバー１０９に保存するファイルの情報である。データＵＲＬ８０１はストレージサーバー１０９に保存するファイルを一意に特定することができるＵＲＬである。ファイルパス８０２はストレージ上のファイルパスでありファイルの格納場所を示す。データＵＲＬ８０１に対してリクエストすることによりストレージのファイル操作を行うことができる。たとえば、データＵＲＬ８０１に対してＨＴＴＰ ＧＥＴメソッドをリクエストすると対応するファイルがダウンロードできる。データＵＲＬ８０１に対してＨＴＴＰ ＰＵＴメソッドにファイル添付してリクエストするとファイルをアップロードし保存できる。データＵＲＬ８０１に対してＨＴＴＰ ＤＥＬＥＴＥメソッドをリクエストすると対応するファイルを削除できる。

＜モバイル端末１０２の画面＞
図９（ａ）、図９（ｂ）、図９（ｃ）はモバイル端末１０２に表示するブラウザーアプリケーションの画面例であり図２（ａ）において表示制御部２０８を介してディスプレイ２１５に表示されるものである。図９（ａ）のログイン画面９００は、モバイル端末１０２から業務サーバー１０５への初回アクセス時に業務サーバー１０５が応答する、ローカル認証サーバー１０４へログインを行う画面である。ユーザー名９０１、パスワード９０２、ドメイン９０３が入力されログインボタン９０４が押下されると、業務サーバー１０５にローカル認証リクエストが送信される。ローカル認証リクエストとともに送信されるユーザー名９０１、パスワード９０２、ドメイン９０３が、ローカル認証サーバー１０４に登録されているローカル認証情報３００と照合されて認証される。図９（ｂ）の商談画面９１０はログイン画面９００でログインしたユーザーの業務情報を表示する画面である。業務サーバー１０５はローカル認証リクエストを受け付けローカル認証サーバー１０４で認証されると、認証されたユーザーの業務情報を含む商談画面９１０を応答する。商談画面９１０において帳票生成ボタン９１１が押下されると、業務サーバー１０５に帳票生成リクエストが送信される。図９（ｃ）のプレビュー画面９２０は帳票ＳＶＧを表示するための画面であり、帳票サーバー１０７が生成した帳票ＳＶＧがモバイル端末１０２の画面に表示される。

＜帳票ＳＶＧプレビューフロー＞
図１０はログイン画面９００でログインボタン９０４が押下され、プレビュー画面９２０が表示されるまでの処理フローである。また図１４、図１５は、処理フローを時系列で示したシーケンス図である。なお以下の説明で「送信する」「受信する」といっても、サーバー等の構成によっては必ずしも電気通信による送受信とは限らず、プロセス間の通信を含む場合もある。また図１０では矢印は要求を示しており、煩雑さを避けるために要求に対する応答は図示していない。しかし以下の説明の通り、要求に対しては一定の応答が返される。
Ｓ１０．１においてログイン画面９００でログインボタン９０４が押下されると、モバイル端末１０２からユーザー名、パスワード、ドメインをパラメータとして業務サーバー１０５に対してローカル認証リクエストが送信される。
モバイル端末１０２からローカル認証リクエストを受信した業務サーバー１９５は、Ｓ１０．２においてローカル認証サーバー１０４に対してローカル認証リクエストを送信する。Ｓ１０．１とＳ１０．２におけるローカル認証リクエストにおけるパラメータは同じものである。ローカル認証リクエストを受け付けたローカル認証サーバー１０４は、リクエストパラメータのユーザー名、パスワード、ドメインをローカル認証情報３００のドメイン名３０１、ユーザー名３０２、パスワード３０３と照合して認証する。そしてその認証結果を業務サーバー１０５に応答する。業務サーバー１０５はローカル認証サーバー１０４から受信した認証結果が成功だった場合、認証されたユーザーの業務情報で商談画面９１０を生成し、Ｓ１０．１の応答としてモバイル端末１０２に返す。認証が失敗であればその旨を示す画面がローカル認証サーバー１０４から業務サーバー１０５を介してモバイル端末１０２に応答されて表示される。
Ｓ１０．３において商談画面９１０で帳票生成ボタン９１１が押下されるとモバイル端末から業務サーバー１０５に帳票生成リクエストが送信される。Ｓ１０．３の帳票生成リクエストを受け付けた業務サーバー１０５は後述のＳ１０．４、Ｓ１０．５、Ｓ１０．７のステップを処理し、Ｓ１０．９でモバイル端末１０２にプレビュー画面のＵＲＬを、認可トークンおよびプレビューＩＤとともに応答する。

Ｓ１０．４において業務サーバー１０５は認可サーバー１０６に認可トークン生成リクエストを送信する。業務サーバー１０５は認可トークン生成リクエストのパラメータとして、クライアントＩＤ４０１、シークレット４０２、スコープ４０３を含むクライアント情報と、アプリケーションＩＤとしてＳ１０．２で認証されたユーザーのローカルユーザー情報（ユーザー名３０２＠ドメイン名３０１）とを送信する。クライアント情報はクレデンシャル情報とも呼ぶことがある。また、ローカルユーザー情報は、クラウドサービスのクライアントである業務サーバー１０５が、クラウドサービスを要求する元となった要求（この例ではＳ１０．３の帳票作成要求）の要求元ユーザーの識別情報であるともいえる。Ｓ１０．４の認可トークン生成リクエストを受信した認可サーバー１０６は、パラメータのクライアントＩＤ、シークレット、スコープがクライアント情報５００に存在するか判定する。そして、一致するクライアントＩＤ５０１、シークレット５０２、スコープ５０３が存在した場合に、認可トークン５１１を発行し認可トークン情報５１０に発行した認可トークンに対応するレコードの追加を行う。この時、認可サーバー１０６はＳ１０．４の認可トークン生成リクエストのパラメータで受信したスコープ、クライアントＩＤ、アプリケーションＩＤを認可トークン情報５１０に追加したレコードに登録する。そして認可サーバー１０６はＳ１０．４の認可トークン生成リクエストの応答として発行した認可トークン５１１を業務サーバー１０５に返す。

Ｓ１０．５において、認可トークン５１１を受信した業務サーバー１０５は帳票サーバー１０７にプレビュー生成リクエストを送信する。業務サーバー１０５はＳ１０．５のプレビュー生成リクエストのパラメータとして、Ｓ１０．４の認可トークン生成リクエストの応答として受信した認可トークン、テンプレートＩＤ４１１、Ｓ１０．２で商談画面９１０生成時に利用した業務情報を送信する。

Ｓ１０．６において帳票サーバー１０７はＳ１０．５のプレビュー生成リクエストで受信した認可トークンと、スコープとをパラメータとして、認可サーバー１０６に認可トークン検証リクエストを送信する。このとき、指定するスコープは例えばプレビュー生成リクエストに対応するＳＶＧ＿Ｐｒｅｖｉｅｗである。Ｓ１０．６の認可トークン検証リクエストを受信した認可サーバー１０６は、パラメータとして受信した認可トークンとスコープとが一致するレコードが認可トークン情報５１０の中にあるか検証する。そして、一致したレコードがあればそのレコード情報（以下、認可トークン情報と呼ぶ。）を応答する。なおここでは、応答する認可トークン情報にはさらに、認可トークン情報に含まれたクライアントＩＤ５１４に対応するテナントＩＤも含まれる。クライアント情報５００全体を含めてもよいが、本実施形態ではテナントＩＤだけで十分である。受信した認可トークン及びスコープに一致するレコードがない場合エラーを応答する。帳票サーバー１０７は認可トークン検証リクエストの応答として認可トークン情報を受信すると、プレビューＩＤ６１１を発行し、プレビュー情報６１０にレコードを登録する。そのレコードのテナントＩＤ６１２には受信した認可トークン情報のテナントＩＤが、ユーザーＩＤ６１３には認可トークン情報のアプリケーションＩＤが記録される。そして帳票サーバー１０７は発行したプレビューＩＤ６１１をＳ１０．５のプレビュー生成リクエストの応答として業務サーバー１０５に返す。

Ｓ１０．６−１において帳票サーバー１０７はＳ１０．５のプレビュー生成リクエストのパラメータとして受信したテンプレートＩＤと一致するテンプレートＩＤ６０１のテンプレートをテンプレート情報６００から特定する。そして、特定したテンプレートのテンプレートＵＲＬパス６０３からテンプレートファイルを取得する。そして帳票サーバー１０７はそのテンプレートファイルに業務情報を反映させ帳票ＰＤＦを生成する。帳票ＰＤＦとは、ＰＤＦ形式の帳票データである。帳票サーバー１０７は、Ｓ１０．６で生成したプレビューＩＤからストレージサーバー１０９上のＵＲＬパスを生成し、プレビュー情報６１０においてそのプレビューＩＤ６１１に対応する帳票ＰＤＦ ＵＲＬパス６１５に生成したＵＲＬパスを登録する。そして帳票ＰＤＦ ＵＲＬパス６１５に、生成した帳票ＰＤＦをアップロードする。

Ｓ１０．６−２において帳票サーバー１０７はデータ変換サーバー１０８に帳票ＳＶＧ生成リクエストを送信する。帳票サーバー１０７は帳票ＳＶＧ生成リクエストのパラメータとして、Ｓ１０．５のプレビュー生成リクエストとともに受信した認可トークンと、Ｓ１０．６−１で生成した帳票ＰＤＦ ＵＲＬパス６１５を指定する。
Ｓ１０．６−３においてデータ変換サーバー１０８は、Ｓ１０．６−２の帳票ＳＶＧ生成リクエストとともに受信した認可トークンと、スコープとをパラメータとして、認可サーバー１０６に認可トークン検証リクエストを送信する。指定するスコープは例えば帳票ＳＶＧ生成リクエストに対応するＳＶＧ＿Ｐｒｅｖｉｅｗである。認可トークン検証リクエストの処理は前述のＳ１０．６と同様である。

データ変換サーバー１０８はＳ１０．６−３の認可トークン検証リクエストの応答として認可トークン情報を受信すると、文書ＩＤ７０１とデータ変化ＩＤ７１１とを発行し、文書情報７００とデータ変換情報７１０とに新たなレコードとしてそれぞれ登録する。ここでテナントＩＤ７０２、７１２にはＳ１０．６−３で受信した認可トークン情報のテナントＩＤを登録する。ユーザーＩＤ７０３、７１３にはＳ１０．６−３で受信した認可トークン情報のアプリケーションＩＤを登録する。文書ＵＲＬパス７０４にはＳ１０．６−２で受信した帳票ＳＶＧ生成リクエストのパラメータである帳票ＰＤＦ ＵＲＬパスを登録する。文書ＩＤ７１４には文書情報７００の文書ＩＤ７０１と同じものを登録する。そしてデータ変換サーバー１０８はＳ１０．６−２の帳票ＳＶＧ生成リクエストの応答として、発行したデータ変換ＩＤ７１１を帳票サーバー１０７に返す。Ｓ１０．６−２の帳票ＳＶＧ生成リクエストの応答としてデータ変換ＩＤを受け取った帳票サーバー１０７は、受信したデータ変換ＩＤをプレビュー情報６１０のデータ変換ＩＤ６１４として登録する。

Ｓ１０．６−４においてデータ変換サーバー１０８は帳票ＰＤＦ ＵＲＬパス７０４から帳票ＰＤＦを取得し帳票ＰＤＦを帳票ＳＶＧに変換する。なお帳票ＳＶＧとはＳＶＧ形式の帳票データである。
Ｓ１０．６−５においてデータ変換サーバー１０８はストレージサーバー１０９上の帳票ＳＶＧ ＵＲＬパスとインデックスＵＲＬパスとを生成し、帳票ＳＶＧ ＵＲＬパスに、Ｓ１０．６−４で変換された帳票ＳＶＧをアップロードする。そしてデータ変換サーバー１０８は帳票ＳＶＧ ＵＲＬパスのリストであるインデックスファイルをインデックスＵＲＬパスにアップロードする。データ変換サーバー１０８はデータ変換情報７１０にインデックスＵＲＬパス７１５を登録する。

Ｓ１０．７において業務サーバー１０５は帳票サーバー１０７にプレビューＵＲＬ取得リクエストを送信する。業務サーバー１０５はＳ１０．７のプレビューＵＲＬ取得リクエストのパラメータとして、Ｓ１０．４の認可トークン生成リクエストの応答で受信した認可トークンとＳ１０．５のプレビュー生成リクエストの応答で受信したプレビューＩＤとを指定する。なお業務サーバー１０５はＳ１０．７のプレビューＵＲＬ取得リクエストをＳ１０．５のプレビュー生成リクエストの応答を受信した直後に先述のＳ１０．６−１〜Ｓ１０．６−５の処理とは非同期で行う。したがって、図１４のＳ１０．６−１〜Ｓ１０．６−５までの処理と、図１５ｂのＳ１０．７以降の処理とは非同期に進行する。したがって、Ｓ１０．１４でインデックス及び帳票ＳＶＧが要求された時点でＳ１０．６−５のインデックス及び帳票ＳＶＧ保存が完了していなければ帳票ＳＶＧはモバイル端末１０２に応答できない。その場合にはモバイル端末１０２はＳ１０．１４の試行を成功するまで繰り返し行うことになろう。

Ｓ１０．８において、プレビューＵＲＬ取得リクエストを受信した帳票サーバー１０７は、そのパラメータの認可トークンとスコープとをパラメータに指定し、認可サーバー１０６に認可トークン検証リクエストを行う。指定するスコープは例えばプレビューＵＲＬ取得リクエストに対応するＳＶＧ＿Ｐｒｅｖｉｅｗである。認可トークン検証リクエストの処理は前述のＳ１０．６と同様である。
帳票サーバー１０７は、Ｓ１０．８の認可トークン検証リクエストの応答として認可トークン情報を受信すると、Ｓ１０．７のプレビューＵＲＬ取得リクエストのパラメータとして受信したプレビューＩＤと一致するレコードをプレビュー情報６１０から特定する。そして、帳票サーバー１０７はＳ１０．７のプレビューＵＲＬ取得リクエストの応答として帳票サーバー１０７のプレビューＵＲＬを返す。ここで返す帳票サーバー１０７のプレビュー画面ＵＲＬにはＵＲＬパラメータとしてＳ１０．７で受信したプレビューＩＤと認可トークンとを指定する。
Ｓ１０．９において、業務サーバー１０５はＳ１０．３の帳票生成リクエストの応答としてモバイル端末１０２にＳ１０．７で受信した帳票サーバー１０７のプレビュー画面ＵＲＬを返す。またプレビュー画面ＵＲＬとともに、Ｓ１０．７のプレビューＵＲＬ取得リクエストの応答として受信したプレビューＩＤおよび認可トークンをモバイル端末１０２に送信する。

Ｓ１０．１０においてモバイル端末１０２は、Ｓ１０．９で受信したプレビュー画面ＵＲＬへプレビュー画面取得リクエストを行う。プレビュー画面ＵＲＬにより指定されたサーバー（ここでは帳票サーバー１０７）は、指定されたＵＲＬのコンテンツとして、Ｓ１０．１０−２を実行するためのスクリプトをモバイル端末１０２に応答する。
Ｓ１０．１０−２において、モバイル端末１０２は受信したスクリプトを実行してインデックスＵＲＬ取得リクエストを帳票サーバー１０７に送信する。このときインデックスＵＲＬ取得リクエストのパラメータとして、Ｓ１０．９において受信したプレビューＩＤおよび認可トークンも送信される。
Ｓ１０．１１において、インデックスＵＲＬ取得リクエストを受信した帳票サーバー１０７はＵＲＬパラメータで指定された認可トークンと、スコープとをパラメータに指定し、認可サーバー１０６に認可トークン検証リクエストを行う。指定するスコープは例えばインデックスＵＲＬ取得リクエストに対応するＳＶＧ＿Ｐｒｅｖｉｅｗである。認可トークン検証リクエストの処理は前述のＳ１０．６と同様である。
帳票サーバー１０７はＳ１０．１１の認可トークン検証リクエストの応答で認可トークン情報を受信すると、インデックスＵＲＬ取得リクエストのＵＲＬパラメータで指定された認可トークンプレビューＩＤと一致するレコードをプレビュー情報６１０から特定する。ここで帳票サーバー１０７は特定したプレビュー情報６１０にデータ変換ＩＤ６１４が登録されていない場合、帳票ＰＤＦがまだ生成されていないとしてＳ１０．１０にエラー応答する。

Ｓ１０．１２において、帳票サーバー１０７は、特定したプレビュー情報６１０にデータ変換ＩＤ６１４が登録されていた場合、データ変換ＩＤ６１４とＳ１０．７で受信した認可トークンとをパラメータとしてデータ変換サーバー１０８にインデックスＵＲＬ取得リクエストを送信する。
Ｓ１０．１３においてデータ変換サーバー１０８はインデックスＵＲＬ取得リクエストのパラメータである認可トークンとスコープとをパラメータに指定し、認可サーバー１０６に認可トークン検証リクエストを行う。認可トークン検証リクエストの処理は前述のＳ１０．６と同様である。指定するスコープは例えばインデックスＵＲＬ取得リクエストに対応するＳＶＧ＿Ｐｒｅｖｉｅｗである。

データ変換サーバー１０８はＳ１０．１３の認可トークン検証リクエストの応答で認可トークン情報を受信すると、データ変換情報７１０から、Ｓ１０．１２のインデックスＵＲＬ取得リクエストのパラメータとして受信したデータ変換ＩＤと一致するレコードを特定する。そして特定したデータ変換情報７１０のステータス７１６が"変換済み"だった場合に、インデックスＵＲＬパス７１５をＳ１０．１２のインデックスＵＲＬ取得リクエストへの応答として帳票サーバー１０７に返す。そして帳票サーバー１０７は、Ｓ１０．１０−２のインデックスＵＲＬ取得リクエストへの応答として、受信したインデックスＵＲＬパスをモバイル端末１０２に返す。ここで、特定したデータ変換情報７１０のステータス７１６が"変換済み"以外だった場合、データ変換サーバー１０８は帳票サーバー１０７に帳票ＳＶＧがまだ生成されていないとしてＳ１０．１２の応答としてエラーを返す。そして帳票サーバー１０７はＳ１０．１０−２のインデックスＵＲＬ取得リクエストにエラー応答する。モバイル端末１０２はＳ１０．１０−２に対する応答として、帳票ＳＶＧが生成され、そのインデックスＵＲＬパスを受信できるまでリトライする。
Ｓ１０．１４においてモバイル端末１０２はＳ１０．１０−２のインデックスＵＲＬ取得リクエストへの応答として取得したインデックスＵＲＬパスからインデックスを取得する。そしてインデックスに記載された帳票ＳＶＧ ＵＲＬから帳票ＳＶＧを取得しプレビュー画面９２０に帳票ＳＶＧを表示する。すなわち図１０、図１５では簡略化しているが、インデックス取得に引き続いて帳票ＳＶＧのリクエストが送信され、帳票ＳＶＧが応答される。

＜認可サーバー１０６の認可トークン発行フロー＞
図１１は認可サーバー１０６が認可トークンリクエスト（Ｓ１０．４）を受信したときの認可トークン発行の処理フローの詳細である。
Ｓ１１．１において認可サーバー１０６は認可トークンリクエストを受信する。認可サーバー１０６は認可トークンリクエストのパラメータとしてクライアントＩＤ、シークレット、スコープ、アプリケーションＩＤを受け取る。
Ｓ１１．２において認可サーバー１０６はクライアント情報５００からＳ１１．１で受信したクライアントＩＤと一致するレコードを特定する。
Ｓ１１．３において認可サーバー１０６はＳ１１．２で特定したクライアント情報５００のクライアントＩＤ５０１、シークレット５０２が、Ｓ１１．１で受信したクライアントＩＤ、シークレットと一致するか判定する。一致しない場合エラーとする（Ｓ１１．５）。
Ｓ１１．４において認可サーバー１０６はＳ１１．２で特定したクライアント情報５００のスコープ５０３が、Ｓ１１．１で受信したスコープと一致するか判定する。一致しない場合エラーとする（Ｓ１１．５）。
Ｓ１１．５において認可サーバー１０６は認可トークンＩＤ５１１を発行し、Ｓ１１．１で受信したクライアントＩＤ、スコープ、アプリケーションＩＤを認可トークン情報５１０にレコード登録する。前述のＳ１０．４のフローにおいてアプリケーションＩＤにローカルユーザー情報（ユーザー名３０２＠ドメイン名３０１）が指定されるが、ローカル認証連携しないクライアントからのリクエストの場合、アプリケーションＩＤには空または異なる値が登録される。

以上の手順により、認可トークン情報５１０として、認可トークンと関連付けて、ローカルユーザーを特定できるローカルユーザー情報が登録される。認可トークン情報５００は、認可サーバー１０６により認可トークンの検証が成功すると、検証の要求元に返される。そのため、リクエストともに受信した認可トークンの検証を要求したサーバーは、リクエストの要求元がローカルユーザーであれば、そのローカルユーザー情報も併せて取得できる。

＜帳票サーバー１０７・データ変換サーバー１０８の認可トークン検証フロー＞
図１２は帳票サーバー１０７またはデータ変換サーバー１０８が各種リクエスト（Ｓ１０．５、Ｓ１０．６−１、Ｓ１０．７、Ｓ１０．１０、Ｓ１０．１１、Ｓ１０．１２）を受信したときの認可トークン検証の処理フローの詳細である。
Ｓ１２．１において帳票サーバー１０７またはデータ変換サーバー１０８はリクエストを受信する。またリクエストのパラメータとして認可トークンを受信する。
Ｓ１２．２において帳票サーバー１０７またはデータ変換サーバー１０８は認可サーバー１０６に対して認可トークン検証リクエストを行う。認可トークン検証リクエストの結果、認可トークン情報が得られなかった場合エラーとする（Ｓ１２．６）。認可トークン検証が成功すると、その応答として認可トークン情報が返され、返される情報にはテナントＩＤが含まれている。
Ｓ１２．３において帳票サーバー１０７またはデータ変換サーバー１０８は、テナント設定情報６２０または７２０から認可トークン情報のテナントＩＤと一致するレコードを特定する。そして、そのテナントのローカル認証連携モード６２２または７２２が有効になっているかどうか判断する。
Ｓ１２．４においてテナントのローカル認証連携モードが有効だった場合、帳票サーバー１０７またはデータ変換サーバー１０８は、認可トークン情報のテナントＩＤとアプリケーションＩＤに登録されているローカルユーザー情報（ユーザー名３０２＠ドメイン名３０１）を一意のユーザーとしてリクエストを処理する。
Ｓ１２．５においてテナントのローカル認証連携モードが無効だった場合、帳票サーバー１０７またはデータ変換サーバー１０８は、認可トークン情報のクライアントＩＤを一意のユーザーとしてリクエストを処理する。

以上のように、認可トークン発行時に、ローカルユーザー情報によってローカル認証情報を認可トークンと紐付けておくことで、認可トークンを利用して検証を受けた時に認可トークン情報からローカルユーザー情報を取得することができる。そのローカルユーザー情報を利用することで、帳票サーバー１０７やデータ変換サーバー１０８において、ユーザーをローカル認証サーバー１０４のユーザーとして一意に認識することができる。例えば認可トークンに紐づいたローカルユーザー情報を帳票サーバー１０７やデータ変換サーバー１０８の課金処理や処理集計処理で一意のユーザーを示す識別情報として処理することで、ローカル認証サーバー１０４と連動して運用することができる。これによりローカル認証セキュリティドメイン１１０と帳票サービスセキュリティドメイン１１１の間でＩＤプロビジョニングする必要がなく、運用負荷を下げることができる。また、業務サーバー１０５は一つのクライアントを使いまわして認可トークンを発行しているが、発行した認可トークンの利用はローカル認証情報で限定されるため、認可トークンで他のユーザーの情報にアクセスすることはできない。そのためセキュアに認証連携することができる。

さらに、ローカル認証連携モードの有効／無効をテナント毎の設定として持つことによって、マルチテナント時に特定のテナントのみローカル認証連携を行うことができ、認証・認可において柔軟に顧客ニーズに応えることが出来る。

またローカルユーザー情報に代えてローカル認証情報を認可トークンと関連付けてもよい。また本実施形態では処理リクエストとして帳票生成リクエストを示したが、他の処理リクエストについても本実施形態に係る発明を適用することはできる。

［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０２ モバイル端末、１０４ ローカル認証サーバー、１０６ 認可サーバー、１０７ 帳票サーバー、１０８ データ変換サーバー、１０９ ストレージサーバー

Claims (14)

1. 認可トークン生成リクエストに応じてクライアント情報に基づいたクライアントの認証が成功した場合には、前記クライアントに対して認可トークンを応答し、前記認可トークン生成リクエストとともに受信したローカルユーザー情報を前記認可トークンと関連付けた認可トークン情報を生成して格納する手段と、
   前記クライアントから前記認可トークンとともに処理リクエストを受けたアプリケーションサーバーから、前記認可トークンを含む認可トークン検証リクエストを受信し、受信した前記認可トークンと前記認可トークン情報とに基づいた認可トークンの検証が成功した場合には、前記認可トークン情報に含まれる前記ローカルユーザー情報を前記アプリケーションサーバーへ応答する応答手段と
   を有することを特徴とする認可サーバー。
2. 前記クライアント情報には、クライアントの識別情報と、該クライアントのテナントの識別情報とを含み、
   前記応答手段は、検証が成功した前記認可トークンの生成を要求したクライアントのテナントの識別情報を、前記認可トークン情報の一部として応答することを特徴とする請求項１に記載の認可サーバー。
3. 前記ローカルユーザー情報は、ローカル認証サーバーにより認証されたユーザーのアクセス可能なドメインを示す情報と、前記ドメインにおけるユーザー識別情報とを含むことを特徴とする請求項１又は２に記載の認可サーバー。
4. 前記認可トークン検証リクエストは、前記認可トークンと共に前記クライアントから処理リクエストを受け付けたアプリケーションサーバーから受信され、
   前記ローカルユーザー情報は、前記アプリケーションサーバーにより、前記処理リクエストの要求元のユーザーの識別のために用いられることを特徴とする請求項３に記載の認可サーバー。
5. テナントごとのローカル認証連携モードを格納する手段と、
   クライアントから認可トークンとともに処理リクエストを受信すると、認可サーバーに対して認可トークン検証リクエストを送信し、前記認可トークン検証リクエストが成功した応答として、前記認可トークンと関連付けられたローカルユーザー情報を含む認可トークン情報を受信する手段と、
   前記ローカルユーザー情報で示されるユーザーまたは前記クライアントに対して前記処理リクエストを処理する処理手段と
   を有することを特徴とするアプリケーションサーバー。
6. テナントごとのローカル認証連携モードを格納する手段を更に有し、
   前記認可トークン情報には、前記クライアントのテナントの識別情報がさらに含まれており、
   前記処理手段は、前記テナントの識別情報で示されるテナントの前記ローカル認証連携モードが連携を示している場合には、前記ローカルユーザー情報で示されるユーザーに対して前記処理リクエストを処理し、連携を示していない場合には、前記処理リクエストを送信したクライアントに対して前記処理リクエストを処理することを特徴とする請求項５に記載のアプリケーションサーバー。
7. 認可サーバーとアプリケーションサーバーとを含む認証連携システムであって、
   前記認可サーバーは、
   認可トークン生成リクエストに応じてクライアント情報に基づいたクライアントの認証が成功した場合には、前記クライアントに対して認可トークンを応答し、前記認可トークン生成リクエストとともに受信したローカルユーザー情報を前記認可トークンと関連付けた認可トークン情報を生成して格納する手段と、
   前記クライアントから前記認可トークンとともに処理リクエストを受けたアプリケーションサーバーから、前記認可トークンを含む認可トークン検証リクエストを受信し、受信した前記認可トークンと前記認可トークン情報とに基づいた認可トークンの検証が成功した場合には、前記認可トークン情報に含まれる前記ローカルユーザー情報を前記アプリケーションサーバーへ応答する応答手段とを有し、
   前記アプリケーションサーバーは、
   クライアントから前記認可トークンとともに処理リクエストを受信すると、前記認可サーバーに対して前記認可トークン検証リクエストを送信し、前記認可トークン検証リクエストが成功した応答として、前記認可トークンと関連付けられた前記ローカルユーザー情報を含む前記認可トークン情報を受信する手段と、
   前記ローカルユーザー情報で示されるユーザーまたは前記クライアントに対して前記処理リクエストを処理する処理手段と
   を有することを特徴とする認証連携システム。
8. 前記クライアント情報には、クライアントの識別情報と、該クライアントのテナントの識別情報とを含み、
   前記応答手段は、検証が成功した前記認可トークンの生成を要求したクライアントのテナントの識別情報を、前記認可トークン情報の一部として応答することを特徴とする請求項７に記載の認証連携システム。
9. 前記ローカルユーザー情報は、ローカル認証サーバーにより認証されたユーザーのアクセス可能なドメインを示す情報と、前記ドメインにおけるユーザー識別情報とを含むことを特徴とする請求項７又は８に記載の認証連携システム。
10. 前記認可トークン検証リクエストは、前記認可トークンと共に前記クライアントから処理リクエストを受け付けた前記アプリケーションサーバーから受信され、
    前記ローカルユーザー情報は、前記アプリケーションサーバーにより、前記処理リクエストの要求元のユーザーの識別のために用いられることを特徴とする請求項９に記載の認証連携システム。
11. 前記アプリケーションサーバーは、テナントごとのローカル認証連携モードを格納する手段を更に有し、
    前記認可トークン情報には、前記クライアントのテナントの識別情報がさらに含まれており、
    前記処理手段は、前記テナントの識別情報で示されるテナントの前記ローカル認証連携モードが連携を示している場合には、前記ローカルユーザー情報で示されるユーザーに対して前記処理リクエストを処理し、連携を示していない場合には、前記処理リクエストを送信したクライアントに対して前記処理リクエストを処理することを特徴とする請求項７乃至１０のいずれか一項に記載の認証連携システム。
12. コンピュータを、
    認可トークン生成リクエストに応じてクライアント情報に基づいたクライアントの認証が成功した場合には、前記クライアントに対して認可トークンを応答し、前記認可トークン生成リクエストとともに受信したローカルユーザー情報を前記認可トークンと関連付けた認可トークン情報を生成して格納する手段と、
    前記クライアントから前記認可トークンとともに処理リクエストを受けたアプリケーションサーバーから、前記認可トークンを含む認可トークン検証リクエストを受信し、受信した前記認可トークンと前記認可トークン情報とに基づいた認可トークンの検証が成功した場合には、前記認可トークン情報に含まれる前記ローカルユーザー情報を前記アプリケーションサーバーへ応答する応答手段と
    して機能させるためのプログラム。
13. コンピュータを、
    テナントごとのローカル認証連携モードを格納する手段と、
    クライアントから認可トークンとともに処理リクエストを受信すると、認可サーバーに対して認可トークン検証リクエストを送信し、前記認可トークン検証リクエストが成功した応答として、前記認可トークンと関連付けられたローカルユーザー情報を含む認可トークン情報を受信する手段と、
    前記ローカルユーザー情報で示されるユーザーまたは前記クライアントに対して前記処理リクエストを処理する処理手段と
    して機能させるためのプログラム。
14. 認可サーバーとアプリケーションサーバーとを含む認証連携システムにより実行される認証連携方法であって、
    前記認可サーバーが、認可トークン生成リクエストに応じてクライアント情報に基づいたクライアントの認証が成功した場合には、前記クライアントに対して認可トークンを応答し、前記認可トークン生成リクエストとともに受信したローカルユーザー情報を前記認可トークンと関連付けた認可トークン情報を生成して格納し、
    前記アプリケーションサーバーが、クライアントから前記認可トークンとともに処理リクエストを受信すると、前記認可サーバーに対して前記認可トークン検証リクエストを送信し、
    前記認可サーバーが、前記クライアントから前記認可トークンとともに処理リクエストを受けたアプリケーションサーバーから、前記認可トークンを含む認可トークン検証リクエストを受信し、受信した前記認可トークンと前記認可トークン情報とに基づいた認可トークンの検証が成功した場合には、前記認可トークン情報に含まれる前記ローカルユーザー情報を前記アプリケーションサーバーへ応答し、
    前記アプリケーションサーバーが、前記認可トークン検証リクエストが成功した応答として、前記認可トークンと関連付けられた前記ローカルユーザー情報を含む前記認可トークン情報を受信し、前記ローカルユーザー情報で示されるユーザーまたは前記クライアントに対して前記処理リクエストを処理する
    ことを特徴とする認証連携方法。

Images