(57)【特許請求の範囲】
【請求項１】
ユーザーが認可操作を行ったことでアプリケーションサーバーを利用する権限がクライアントデバイスに委譲され、委譲されたことで発行された第１の認可トークンを代表トークン情報として登録する前記クライアントデバイスから、前記代表トークン情報およびローカルユーザー情報とともに認可トークン生成リクエストを受信する手段と、
前記認可トークン生成リクエストとともに受信した前記代表トークン情報に基づいた認証が成功した場合には、前記クライアントデバイスに対して第２の認可トークンを応答し、前記認可トークン生成リクエストとともに受信したローカルユーザー情報を前記第２の認可トークンと関連付けた認可トークン情報を生成して格納する手段と、
前記クライアントデバイスから前記第２の認可トークンとともに処理リクエストを受けた前記アプリケーションサーバーから、前記第２の認可トークンを含む認可トークン検証リクエストを受信し、受信した前記第２の認可トークンと前記認可トークン情報とに基づいた認可トークンの検証が成功した場合には、前記認可トークン情報に含まれる前記ローカルユーザー情報を前記アプリケーションサーバーへ応答する応答手段と
を有することを特徴とする認可サーバー。
【請求項２】
前記代表トークン情報には、代表クライアントの識別情報と、該代表クライアントのテナントの識別情報とを含み、
前記応答手段は、前記代表クライアントのテナントの識別情報を、前記認可トークン情報の一部として応答することを特徴とする請求項１に記載の認可サーバー。
【請求項３】
前記ローカルユーザー情報は、ローカル認証サーバーにより認証されたユーザーのアクセス可能なドメインを示す情報と、前記ドメインにおけるユーザー識別情報とを含むことを特徴とする請求項１又は２に記載の認可サーバー。
【請求項４】
前記認可トークン検証リクエストは、前記認可トークンと共に前記クライアントデバイスから処理のリクエストを受け付けたアプリケーションサーバーから受信され、
前記ローカルユーザー情報は、前記アプリケーションサーバーにより、前記処理のリクエストの要求元のユーザーの識別のために用いられることを特徴とする請求項３に記載の認可サーバー。
【請求項５】
認可サーバーとアプリケーションサーバーとクライアントデバイスとを含む認証連携システムであって、
前記クライアントデバイスは、
ユーザーが認可操作を行ったことで前記アプリケーションサーバーを利用する権限が委譲され、委譲されたことで発行された第１の認可トークンを代表トークン情報として格納し、
前記認可サーバーに対して、ログインしたユーザーのローカルユーザー情報および前記代表トークン情報とともに認可トークン生成リクエストを送信し、
前記認可トークン生成リクエストに応じて第２の認可トークンを受信した場合、前記第２の認可トークンとともに、処理のリクエストをアプリケーションサーバーに送信し、
前記認可サーバーは、
前記クライアントデバイスから、前記代表トークン情報およびローカルユーザー情報とともに前記認可トークン生成リクエストを受信し、
前記認可トークン生成リクエストとともに受信した前記代表トークン情報に基づいた認証が成功した場合には、前記クライアントデバイスに対して前記第２の認可トークンを応答し、前記認可トークン生成リクエストとともに受信したローカルユーザー情報を前記第２の認可トークンと関連付けた認可トークン情報を生成して格納し、
前記クライアントデバイスから前記第２の認可トークンとともに処理リクエストを受けた前記アプリケーションサーバーから、前記第２の認可トークンを含む認可トークン検証リクエストを受信し、受信した前記第２の認可トークンと前記認可トークン情報とに基づいた認可トークンの検証が成功した場合には、前記認可トークン情報に含まれる前記ローカルユーザー情報を前記アプリケーションサーバーへ応答し、
前記アプリケーションサーバーは、
前記クライアントデバイスから前記第２の認可トークンとともに処理のリクエストを受信すると、前記認可サーバーに対して前記認可トークン検証リクエストを送信し、前記認可トークン検証リクエストが成功した応答として、前記第２の認可トークンと関連付けられた前記ローカルユーザー情報を含む前記認可トークン情報を受信し、
前記ローカルユーザー情報で示されるユーザーまたは前記クライアントデバイスに対して前記処理のリクエストを処理する
ことを特徴とする認証連携システム。
【請求項６】
前記代表トークン情報には、クライアントデバイスの識別情報と、該クライアントデバイスのテナントの識別情報とを含み、
前記認可サーバーは、検証が成功した前記認可トークンの生成を要求したクライアントのテナントの識別情報を、前記認可トークン情報の一部として応答し、
前記アプリケーションサーバーは、前記テナントの識別情報に応じて設定されたローカル認証連携モードがセットされている場合に、前記ローカルユーザー情報で示されるユーザーまたは前記クライアントデバイスに対して前記処理のリクエストを処理することを特徴とする請求項５に記載の認証連携システム。
【請求項７】
コンピュータを、
代表クライアントに対して発行した認可トークンが代表トークン情報として登録された、前記代表クライアントから権限の委譲を受けたクライアントデバイスから、前記代表トークン情報およびローカルユーザー情報とともに認可トークン生成リクエストを受信する手段と、
前記認可トークン生成リクエストとともに受信した前記代表トークン情報に基づいた認証が成功した場合には、前記クライアントデバイスに対して認可トークンを応答し、前記認可トークン生成リクエストとともに受信したローカルユーザー情報を前記認可トークンと関連付けた認可トークン情報を生成して格納する手段と、
認可トークン検証リクエストに応じて前記認可トークン情報に基づいた認可トークンの検証が成功した場合には、検証が成功した前記認可トークンに関連付けられた前記認可トークン情報を応答する応答手段と
して機能させるためのプログラム。
【請求項８】
認可サーバーとアプリケーションサーバーとクライアントデバイスとを含む認証連携システムにおける認証連携方法であって、
前記クライアントデバイスが、
ユーザーが認可操作を行ったことでアプリケーションサーバーを利用する権限が委譲され、委譲されたことで発行された第１の認可トークンを代表トークン情報として格納し、
前記認可サーバーに対して、ログインしたユーザーのローカルユーザー情報および前記代表トークン情報とともに認可トークン生成リクエストを送信し、
前記認可トークン生成リクエストに応じて第２の認可トークンを受信した場合、前記第２の認可トークンとともに、処理のリクエストをアプリケーションサーバーに送信し、
前記認可サーバーが、
前記クライアントデバイスから、前記代表トークン情報およびローカルユーザー情報とともに前記認可トークン生成リクエストを受信し、
前記認可トークン生成リクエストとともに受信した前記代表トークン情報に基づいた認証が成功した場合には、前記クライアントデバイスに対して前記第２の認可トークンを応答し、前記認可トークン生成リクエストとともに受信したローカルユーザー情報を前記第２の認可トークンと関連付けた認可トークン情報を生成して格納し、
前記クライアントデバイスから前記第２の認可トークンとともに処理リクエストを受けた前記アプリケーションサーバーから、前記第２の認可トークンを含む認可トークン検証リクエストを受信し、受信した前記第２の認可トークンと前記認可トークン情報とに基づいた認可トークンの検証が成功した場合には、前記認可トークン情報に含まれる前記ローカルユーザー情報を前記アプリケーションサーバーへ応答し、
前記アプリケーションサーバーが、
前記クライアントデバイスから前記第２の認可トークンとともに処理のリクエストを受信すると、前記認可サーバーに対して前記認可トークン検証リクエストを送信し、前記認可トークン検証リクエストが成功した応答として、前記第２の認可トークンと関連付けられた前記ローカルユーザー情報を含む前記認可トークン情報を受信し、
前記ローカルユーザー情報で示されるユーザーまたは前記クライアントデバイスに対して前記処理のリクエストを処理する
ことを特徴とする認証連携方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、たとえばクラウドサービスにおけるサービスとローカルサービスとの認証連携システム及び認証連携方法、認可サーバー及びプログラムに関する。
【背景技術】
【０００２】
近年、サーバーをインターネットに公開しクライアントにサービスを提供するクラウドコンピューティングサービス（或いはクラウドサービス）の形態が注目を集めている。クラウドコンピューティングサービスは、多くのコンピューティング・リソースを用いてデータ変換やデータ処理を分散実行し、多くのクライアントからの要求を分散並列処理により並行して処理することが主な特徴である。現在、このクラウドコンピューティングサービスを実現するクラウドコンピューティングサービス環境上にＷｅｂサービスを実装し、多種多様なサービスをＷｅｂ上で提供するベンダーが乱立しつつある。クラウドサービスの開発において、すでにＷｅｂ上に多く提供されているサービスを有効活用し新しい機能を提供することで、開発スピードや開発コストの面で優位になる。一方で事業者等は従来自らがサーバー等を保有し、運用する自社運用システム（以下、オンプレミスシステムとも呼ぶ。）が数多く運用されている。すべての社内システムをまとめてクラウドサービスに移行することは難しく、その結果、一部のオンプレミスシステムから段階的にクラウドサービスに移行するなど、オンプレミスサービスとクラウドサービスを連携させ両方を利用するユーザーが増えてきている。
【０００３】
オンプレミスサービスとクラウドサービスを連携する場合、従来のオンプレミスのようなローカル認証（ＬＤＡＰなど）とクラウドの認証とが異なるため、シングルサインオン（Ｓｉｎｇｌｅ  Ｓｉｇｎ  Ｏｎ、以下ＳＳＯとも呼ぶ）が強く望まれる。従来技術ではオンプレミスのローカル認証をクラウドサービスに構築されたローカル認証サービスに同期し、クラウドサービスとオンプレミスのログインサービスの両方にログインすることでユーザーＩＤプロビジョニングを開始する。たとえばユーザーＩＤ等、ユーザーアカウントに関する情報の生成や保守などの管理を開始する。その後、ユーザーはクラウドサービスのローカル認証サービスにＶＰＮを使ってログインすると、ユーザーに紐づいたクレデンシャル情報でクラウドサービスにもログインできる（例えば、特許文献１参照。）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特表2015-518198号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、ローカル認証とクラウドサービス認証を連携するために全ユーザーのＩＤプロビジョニングが必要であり、またユーザーの増減のたびにＩＤプロビジョニングをメンテナンスする必要があるためユーザー管理の運用コストが高くなってしまうという課題があった。
【０００６】
本発明は上記従来例に鑑みて成されたもので、ローカル認証とクラウドサービス認証との間でユーザーＩＤプロビジョニングする必要がない認証連携システム及び認証連携方法、認可サーバー及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するために本発明は以下の構成を有する。
【０００８】
第１の側面によれば、本発明は、ユーザーが認可操作を行ったことでアプリケーションサーバーを利用する権限がクライアントデバイスに委譲され、委譲されたことで発行された第１の認可トークンを代表トークン情報として登録する前記クライアントデバイスから、前記代表トークン情報およびローカルユーザー情報とともに認可トークン生成リクエストを受信する手段と、
前記認可トークン生成リクエストとともに受信した前記代表トークン情報に基づいた認証が成功した場合には、前記クライアントデバイスに対して第２の認可トークンを応答し、前記認可トークン生成リクエストとともに受信したローカルユーザー情報を前記第２の認可トークンと関連付けた認可トークン情報を生成して格納する手段と、
前記クライアントデバイスから前記第２の認可トークンとともに処理リクエストを受けた前記アプリケーションサーバーから、前記第２の認可トークンを含む認可トークン検証リクエストを受信し、受信した前記第２の認可トークンと前記認可トークン情報とに基づいた認可トークンの検証が成功した場合には、前記認可トークン情報に含まれる前記ローカルユーザー情報を前記アプリケーションサーバーへ応答する応答手段と
を有することを特徴とする認可サーバーにある。
【０００９】
第２の側面によれば、本発明は、認可サーバーとアプリケーションサーバーとクライアントデバイスとを含む認証連携システムであって、
前記クライアントデバイスは、
ユーザーが認可操作を行ったことでアプリケーションサーバーを利用する権限が委譲され、委譲されたことで発行された第１の認可トークンを代表トークン情報として格納し、
前記認可サーバーに対して、ログインしたユーザーのローカルユーザー情報および前記代表トークン情報とともに認可トークン生成リクエストを送信し、
前記認可トークン生成リクエストに応じて第２の認可トークンを受信した場合、前記第２の認可トークンとともに、処理のリクエストをアプリケーションサーバーに送信し、
前記認可サーバーは、
前記クライアントデバイスから、前記代表トークン情報およびローカルユーザー情報とともに前記認可トークン生成リクエストを受信し、
前記認可トークン生成リクエストとともに受信した前記代表トークン情報に基づいた認証が成功した場合には、前記クライアントデバイスに対して前記第２の認可トークンを応答し、前記認可トークン生成リクエストとともに受信したローカルユーザー情報を前記第２の認可トークンと関連付けた認可トークン情報を生成して格納し、
前記クライアントデバイスから前記第２の認可トークンとともに処理リクエストを受けた前記アプリケーションサーバーから、前記第２の認可トークンを含む認可トークン検証リクエストを受信し、受信した前記第２の認可トークンと前記認可トークン情報とに基づいた認可トークンの検証が成功した場合には、前記認可トークン情報に含まれる前記ローカルユーザー情報を前記アプリケーションサーバーへ応答し、
前記アプリケーションサーバーは、
前記クライアントデバイスから前記第２の認可トークンとともに処理のリクエストを受信すると、前記認可サーバーに対して前記認可トークン検証リクエストを送信し、前記認可トークン検証リクエストが成功した応答として、前記第２の認可トークンと関連付けられた前記ローカルユーザー情報を含む前記認可トークン情報を受信し、
前記ローカルユーザー情報で示されるユーザーまたは前記クライアントデバイスに対して前記処理のリクエストを処理することを特徴とする認証連携システムにある。
【発明の効果】
【００１０】
本発明によれば、ローカル認証とクラウドサービス認証との間でＩＤプロビジョニングする必要もないため運用負荷を下げることができる。
【図面の簡単な説明】
【００１１】
【図１】システム構成図
【図２】各装置のハードウェア構成図
【図３】プリンター認可フローを示す図
【図４】ユーザー認可画面を示す図
【図５】認証印刷フローを示す図
【図６】認可トークン発行フローを示す図
【図７】認可トークン利用フローを示す図
【図８】各装置のソフトウェア構成図
【図９】（ａ）ローカル認証サーバーで管理するテーブル構造を示す図、（ｂ）（ｃ）プリンターで管理するテーブル構造を示す図、（ｄ）（ｅ）認可サーバーで管理するテーブル構造を示す図
【図１０】データ変換サーバーで管理するテーブル構造を示す図
【図１１】ストレージサーバーで管理するテーブル構造を示す図
【発明を実施するための形態】
【００１２】
以下、本発明を実施するための形態について図面を用いて説明する。
【００１３】
［実施形態１］
＜システム構成＞
図１は、本発明の実施形態に係る認証連携システムを含むモバイル印刷システムの全体構成を示す図である。
図において、クライアント端末１０２、プリンター１０３は、ローカルネットワーク１０１を介して１台又は複数台接続されている。クライアント端末１０２は、ローカルネットワーク１０１を介してインターネットワーク１００にアクセスし、サーバー１０４〜１０９にアクセスすることができる。モバイル端末１０２は有線または無線ＬＡＮを介してネットワークに接続する。
【００１４】
セキュリティドメイン１１０〜１１２は認証・認可されたユーザーのアクセス可能範囲を示しておりセキュリティドメインを越えて認証・認可したユーザーや認可トークンを利用することはできない。ローカル認証セキュリティドメイン１１０はローカル認証サーバー１０４で認証されたユーザーでアクセス可能な範囲を示しており、業務サーバー１０５が属する。帳票サービスセキュリティドメイン１１１は認可サーバー１０６で発行された認可トークンでアクセス可能な範囲を示しており、帳票サーバー１０７やデータ変換サーバー１０８が属する。ストレージサービスセキュリティドメイン１１２は不図示のストレージサービスセキュリティドメイン認可サーバーで発行された認可トークンでアクセス可能な範囲を示しており、ストレージサーバー１０９が属する。図１においては、ローカル認証セキュリティドメイン１１０がオンプレミスシステムであり、帳票サービスセキュリティドメイン１１１およびストレージサービスセキュリティドメイン１１２がクラウドシステムに相当する。
【００１５】
ローカル認証サーバー１０４は業務サーバー１０５へアクセスするためのユーザー認証を実現するためのサーバーである。ユーザーはローカル認証サーバー１０４で認証されることで業務サーバー１０５にアクセスすることができる。ローカル認証方式としてＬＤＡＰが用いられることが多いが、本実施形態ではユーザー名、パスワード、ドメインの一致を確認するのみの簡易的な認証方式とする。これは説明の便宜であって、ユーザーごとに固有の認証情報を用いてユーザー認証を行う他の認証方式についても本実施形態の発明を適用することができる。
【００１６】
業務サーバー１０５はユーザー業務情報を管理するサーバーである。本実施形態では販売する製品を業務サーバー１０５で顧客毎に管理し、販売員が業務サーバー１０５の情報を用いて顧客に対して営業を行うユースケースを想定している。業務サーバー１０５はクライアント端末１０２からのリクエストに応じてユーザー業務情報を表示・編集するための画面を提供する。認可サーバー１０６はＯＡｕｔｈを実現するためのサーバーでありクライアント情報の管理や認可トークンの発行・管理を行う。帳票サーバー１０７は業務サーバー１０５からユーザー業務情報を受け取り、帳票テンプレートにユーザー業務情報を反映させて帳票ＰＤＦを生成し管理するサーバーである。そして帳票サーバー１０７は生成した帳票ＰＤＦをデータ変換サーバー１０８に保存するリクエストを行う。データ変換サーバー１０８は、帳票サーバー１０７から帳票ＰＤＦ保存リクエストを受け付け、帳票ＰＤＦデータを保存し管理するとともに、プリンター１０３からの印刷データ変換リクエストを受け付け印刷データの生成、管理を行う。ストレージサーバー１０９はファイル管理を行うサーバーであり、プリンター１０３、帳票サーバー１０７、データ変換サーバー１０８からのファイルアップロード／ダウンロードを受け付ける。なお、ＯＡｕｔｈは、ユーザーの権限をそのユーザーの同意を前提としてサービス間で安全に受け渡す（すなわち委譲する）ための仕組みであり、その仕組みを実現するサーバーが認可サーバー１０６である。たとえばＯＡｕｔｈによりユーザーが第１のサーバーで許諾された権限の全部または一部を第２のサーバーに委譲することで、第２のサーバーは、そのユーザーの権限の範囲内で第１のサーバーによるサービスを受けることができる。ＯＡｕｔｈによれば、ユーザーは、第１のサーバーにログインするための認証情報を第２のサーバーに教える必要がない。
【００１７】
ここで、サーバー１０６〜１０９の各サーバーはそれぞれ複数台のサーバーで冗長化されたクラウドサービスとしてインターネット上に公開されるが、本実施形態では説明を簡略化するため、それぞれ１台構成としている。またローカル認証サーバー１０４と業務サーバー１０５も複数台のサーバーで冗長化された構成をとることもできるが、本実施例では説明を簡略化するため、それぞれ１台構成としている。なお、クラウドサービスを実現する各サーバーのうち、認可サーバー１０６とストレージサーバー１０９とを除いた、クライアントに対してアプリケーションを提供するためのサーバー）をまとめてアプリケーションサーバーと呼ぶこともある。
【００１８】
また、本実施形態では、プリンター１０３がデータ変換サーバー１０８に保存されている帳票ＰＤＦを印刷する方法について説明する。業務サーバー１０５のデータを使用して帳票サーバー１０７での帳票ＰＤＦ生成し、帳票サーバー１０７からデータ変換サーバー１０８への帳票ＰＤＦの保存が済んでいるものとする。
【００１９】
＜クライアント端末１０２、サーバー１０４〜１０９のハードウェア構成＞
図２（ａ）は、クライアント端末１０２とサーバー１０４〜１０９の各サーバーのハードウェア構成の一例を示す図である。特に断らない限り、本実施形態に係る発明の機能が実行可能であるならば、単体の機器であっても、複数の機器からなるシステムであっても、本実施形態に係る発明が適用できることは言うまでもない。また、特に断らない限り、本実施形態に係る発明の機能が実行可能であるならば、ＬＡＮ、ＷＡＮ等のネットワークを介して接続が為され、処理が行われるシステムであっても本実施形態に係る発明を適用できることは言うまでもない。本実施形態ではシステムバス２１９により各構成要素が接続されているものとして説明する。
【００２０】
ＣＰＵ２２０は情報処理装置の制御装置であり、記憶装置２２６に格納されているアプリケーションプログラム、プリントドライバプログラム、オペレーティングシステムや本実施形態のプリントシステムプログラムを実行する。また、ＣＰＵ２２０はＲＡＭ２２２にプログラム実行に必要な情報、ファイル等を一時的に格納する制御を行う。また、ＣＰＵ２２０はディスプレイ２２７上の不図示マウスカーソル等で指示されたコマンドに基づいて登録された種々のウインドウを開き、種々のデータ処理を実行する。ＲＯＭ２２１は固定された情報を記憶するＲＯＭであり、内部には基本Ｉ／Ｏプログラム等のプログラム、文書処理の際に使用するフォントデータ、テンプレート用データ等の各種データを記憶する。ＲＡＭ２２２は情報を一時記憶するＲＡＭであり、ＣＰＵ２２０の主メモリやワークエリア等として機能する。表示制御部２２４は、ディスプレイ２２７にて出力する情報の制御を行っている。入力制御部２２５は、キーボード２２８より入力される情報を制御し、情報処理装置は入力制御部２２５を介して外部装置とのデータのやり取りを行う。記憶装置２２６は外部記憶の一つで、大容量メモリとして機能し、アプリケーションプログラム、プリントドライバプログラム、ＯＳ等を格納している。キーボード２２８は指示入力部であり、ユーザーが各サーバーへの指示等を入力指示するためのものである。ディスプレイ２２７は表示部であり、キーボード２２８から入力したコマンド等を表示するものである。ネットワークコントローラ２２３は、インターネットへ直接的または間接的に接続するためのネットワークインターフェース部である。
【００２１】
また、クライアント端末１０２は、例えば、デスクトップパソコン、ノートパソコン、モバイルパソコン、ＰＤＡ（パーソナルデータアシスタント）等から成り、Ｗｅｂブラウザー等のプログラムを実行する環境が内蔵されている。クライアント端末１０２にインストールされたＷｅｂブラウザーは図２（ａ）で示した記憶装置２２６に記憶されており、前述したようにＣＰＵ２２０によってＲＡＭ２２２にロードされ実行される。
【００２２】
＜プリンター１０３のハードウェア構成＞
図２（ｂ）は、プリンター１０３のハードウェア構成図である。ハードウェアの各構成要素は、システムバス２３０に接続されている。ＣＰＵ２３１は装置全体の制御を行って、システムバス２３０に接続される各種デバイスとのアクセスを統括的に制御する。この制御は、ＲＯＭ２３２に記憶された制御プログラム等あるいはディスクコントローラ(ＤＫＣ２３５)を介して接続された外部メモリ２３６に記憶された制御プログラムやリソースデータ(資源情報)等に基づく。ＲＡＭ２３３は、ＣＰＵ２３１の主メモリ、ワークエリア等として機能するＲＡＭで、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。記憶装置２４０は大容量メモリとして機能する外部記憶装置である。操作パネル（操作部）２３９は、画面を表示し、また、画面を介したユーザーの操作指示を受け付ける。また、プリンター１０３の動作モード等の設定やプリンター１０３の動作状況の表示や、印刷するコンテンツデータを指定する等の操作を行うためのボタンおよび液晶パネル等の表示部も配置される。ネットワークコントローラ２３４は、ネットワークインターフェースカード（ＮＩＣ）であり、該インターフェース２３４を介して外部装置とのデータのやり取りを行う。なお、図２（ｂ）で示したプリントエンジン２３８は既知の印刷技術を利用するものであり、好適な実施系として例えば電子写真方式(レーザービーム方式)やインクジェット方式、昇華方(熱転写)方式等が挙げられる。ラスタコントローラ２３７は、ＰＤＬ言語である印刷データを画像データに変換するコントローラである。機器Ｉ／Ｆ２４１は、ＵＳＢ等で接続可能な外部機器との接続Ｉ／Ｆである。本実施形態では、機器Ｉ／Ｆ２４１に、ＩＣカードリーダー２４２が接続されており、ＩＣカードに含まれるユーザー情報等を非接触で読み込み、プリンター１０３上で動作するアプリケーションプログラムが読み取った情報を利用することができるものである。
【００２３】
＜ローカル認証サーバー１０４のソフトウェア構成＞
次に、本実施例を実施するために必要な図１に図示される各サーバー、プリンターのソフトウェア構成と、夫々が扱う管理情報について説明する。ローカル認証サーバー１０４は認証Ｉ／Ｆ１０４１、認証情報管理部１０４２、ローカル認証情報３００を格納するストレージを含む。各ソフトウェアモジュールは図２（ａ）で示した記憶装置２２６に記憶されており、前述したようにＣＰＵ２２０によってＲＡＭ２２２にロードされ実行される。認証Ｉ／Ｆ１０４１はローカル認証サーバー１０４の各種インターフェースを提供し、受け付けた情報の妥当性の検証を行う。認証情報管理部１０４２は図９で説明するローカル認証情報３００を管理し、認証Ｉ／Ｆが受け付けたリクエストに応じて、ユーザー認証の成否を応答する。  図９に示すローカル認証情報３００はローカル認証サーバー１０４が外部メモリに記憶するデータテーブルである。これらのデータテーブルは、ローカル認証サーバー１０４のストレージではなく、インターネット１００やローカルネットワーク１０１を介して通信可能に構成された別のサーバーに記憶するように構成することもできる。ローカル認証サーバー１０４が保持するデータテーブルはローカル認証情報３００を含む。ローカル認証情報３００は、業務サーバー１０５にアクセス可能なユーザーのユーザー情報としてドメイン名（ドメイン識別情報）３０１、ユーザー名（ユーザー識別情報）３０２、パスワード３０３を含む。ローカル認証サーバー１０４は、ローカル認証の対象となるユーザーにより入力されたユーザー認証情報と、ローカル認証情報３００として登録されたユーザー認証情報の一致によりユーザーを認証する。ローカル認証情報３００は、ローカル認証セキュリティドメイン１１０内でローカルに通用する認証情報である。
【００２４】
＜プリンターのソフトウェア構成＞
プリンター１０３は、ログインアプリケーション１０３１、認可サーバー連携クライアント１０３２、プルプリントアプリケーション１０３３を含む。、各ソフトウェアモジュールは、図２で示した記憶装置２４０に記憶されており、ＣＰＵ２３１によってＲＡＭ３３にロードされ実行される。なお以下の説明ではアプリケーションを「アプリ」と略称する。
ログインアプリ１０３１は、ローカル認証サーバー１０４と連携し、ローカルセキュリティドメイン１１０における認証を行う。ログインアプリ１０３１は、ＩＣカードリーダー２４２からのログインするユーザーのユーザー認証情報（ユーザー情報とも呼ぶ。）の入力を受け付ける。そして、ローカル認証サーバー１０４に対して、ユーザー情報の妥当性の検証すなわちユーザー認証をリクエストする。ログインアプリ１０３１は、ローカル認証サーバー１０４からユーザー情報情報の検証が成功した、すなわちユーザー認証に成功したとの応答を受けた場合には、プルプリントアプリ１０３３に対してログインしたユーザーのユーザー情報を渡す。
認可サーバー連携クライアント１０３２は、OAuthの仕組みを利用して認可サーバー１０６と連携することで、プリンター１０３に対して、帳票サービスセキュリティドメイン１１１における権限の移譲を行う。本実施形態において、認可サーバー連携クライアント１０３２は、代表トークン４００、認可サーバー情報４１０を保持し、管理する。代表トークンの例は図９に示す。認可サーバー情報４１０は、認可サーバー連携クライアント１０３２が認可サーバー１０６を特定するための情報であり、例えば認可サーバー１０６のＵＲＬなどである。認可サーバー情報４１０は、認可サーバー連携クライアント１０３２に例えばユーザーなどにより設定されている。
プルプリントアプリ１０３３は、データ変換サーバー１０８に対して認証印刷に係るリクエストの送信と、ストレージサーバー１０９からの印刷データの取得、プリントエンジン２３８への印刷データの転送を行い、印刷を実行する。プルプリントアプリ１０３３は、認可トークン情報４２０と、ローカル認証連携情報４３０を保持し、管理する。ローカル認証連携情報４３０は、プルプリントアプリ１０３３が予め保持しており、ローカル認証セキュリティドメイン１１０との連携をするか否かをｔｒｕｅ／ｆａｌｓｅで示す。図９（ｂ）代表トークン情報４００については、図９（ｂ）に、認可サーバー連携クライアント１０３２が保持する代表トークン情報４００の例を示す。代表トークン情報４００は、認可サーバー１０６のクライアント情報５００に登録されているクライアントが発行した認可トークンの情報で、顧客テナントを代表するクライアントに紐づく認可トークンの情報である。認可トークンＩＤ４０１は認可トークンを一意に識別可能な識別子である。クライアントＩＤ４０２、テナントＩＤ４０３それぞれは、当該認可トークンを発行した際の認可サーバー１０６のクライアント情報５００で管理されるクライアントのクライアントＩＤ、テナントＩＤである。
【００２５】
認可サーバー連携クライアント１０３２は、この代表認可トークン情報４００を使用することで、認可サーバー１０６に対して、認可トークンの発行の要求を行うことができる。本実施形態では、後述のユーザー認可設定フローにおいて、テナントＩＤがuser_tenant1である顧客テナントの、クライアントＩＤがclient0001である代表クライアントによる認可トークン生成リクエストに対して発行した認可トークン情報が、代表認可トークン情報４００として登録される。
【００２６】
図９（ｃ）には、プルプリントアプリが管理し、データ変換サーバー１０８へのリクエストの際に付加する認可トークン情報４２０の例を示す。
後述の認証印刷フローの中で、プルプリントアプリ１０３３からのリクエストに従って、認可サーバー連携クライアント１０３２が代表トークン情報４００を使用して認可サーバー１０６に認可トークン生成リクエストを送信する。認可トークン情報４２０は、その認可トークン生成リクエストに応じて発行される認可トークンと、ローカル認証セキュリティドメイン１１０のユーザーとを関連付けた情報である。換言すれば、クラウドサービスのクライアントと、ローカルサービスのユーザーとを紐づけた情報であるともいえる。図９（ｃ）において、認可トークンＩＤ４２１は、認可トークンを一意に識別可能な識別子である。ユーザー名４２２、ドメイン名４２３はそれぞれ、ローカル認証サーバー１０５で管理される、ＩＣカード認証によってログインアプリ１０３１からプルプリントアプリ１０３３が受け取ったローカル認証情報３００に含まれるユーザー識別情報およびドメイン識別情報である。プルプリントアプリ１０３３は、認可サーバー連携クライアント１０３２から取得した認可トークンと、ログインアプ１０３１リから受け取ったログイン中のユーザー情報とを、トークン情報４２０によって紐付けて保持する。
【００２７】
＜認可サーバー１０６のソフトウェア構成＞
認可サーバー１０６はＷｅｂサーバー１０６１、認可情報管理部１０６２、クライアント情報５００と認可トークン情報５１０とを格納するストレージを有している。各ソフトウェアモジュールは図２（ａ）で示した記憶装置２２６に記憶されており、前述したようにＣＰＵ２２０によってＲＡＭ２２２にロードされ実行される。Ｗｅｂサーバー１０６１は認可サーバー１０６の各種インターフェースを提供し、受け付けた情報の妥当性の検証を行う。認可情報管理部１０６２はユーザー情報５００と認可トークン情報５１０を管理し、Ｗｅｂサーバー１０６１が受け付けたリクエストに応じて、認可トークンの発行・スコープ確認・有効期限確認などを行う。
【００２８】
図９（ｄ）に、データベースに保存されているユーザー情報５００の例を示す。
クライアント情報５００は、サーバー１０６〜１０８にアクセス可能なクライアント情報が登録されている。本実施形態においてクライアント情報５００には、プリンター１０３の情報がクライアントとして登録されている。クライアントＩＤは、クライアントを一意に識別する識別子である。シークレットは、ユーザーの正当性を判断するためのパスワードである。認可サーバー１０６は、クライアントから受信したクライアントＩＤとパスワードの組と、クライアント情報のクライアントＩＤ５０１とシークレット５０２の組との一致によりクライアントを特定する。スコープ５０３は、ＯＡｕｔｈのスコープであり認可サーバー１０６が発行する認可トークンでアクセス可能な範囲を示す。本実施形態のスコープの種類はPrintを定義する。Printスコープは、プリンター１０３がデータ変換サーバー１０８のインターフェースにアクセスする際に必要なスコープである。テナントＩＤ５０４は、顧客テナントを一意に識別する識別子である。本実施形態では、テナントＩＤがuser_tenant1である顧客テナントの代表ユーザーとして、ＩＤがuser0001のユーザーが定義し登録されている。
【００２９】
図９（ｅ）に、データベースに保存されている認可トークン情報５１０の例を示す。
認可トークン情報５１０は、認可サーバー１０６により認可トークン生成リクエストを受け付けた際に生成される。１つのリクエストについて１レコードが生成される。認可トークン５１１は認可トークンを一意に識別可能な識別子である。有効期限５１２は、認可トークンの有効期限であり認可トークン生成リクエスト受信時間から一定時間後の値が登録される。有効期限を過ぎた認可トークンは無効である。スコープ５１３は認可トークンが利用可能なスコープであり、認可サーバー１０６への認可トークン生成リクエストで渡されるスコープが登録される。クライアントＩＤ５１４、テナントＩＤ５１５は夫々、認可サーバー１０６への認可トークン生成リクエストで渡されるクライアントＩＤ、テナントＩＤが登録される。アプリケーションＩＤはクライアントが複数アプリケーションで利用される場合に各アプリケーションを識別する識別子である。アプリケーションＩＤは認可サーバー１０６への認可トークン生成リクエストでアプリケーションＩＤが渡された場合に登録される。認可サーバー１０６への認可トークン生成リクエストでアプリケーションＩＤが渡されなかった場合は登録されない。本実施形態ではプリンター１０３から認可サーバー１０６への認可トークン生成リクエストにおいてアプリケーションＩＤにローカルユーザー情報（ユーザー名＠ドメイン名）が指定され、アプリケーションＩＤ５１５として登録される。なお図３に示されたローカル認証情報からパスワードを除いたユーザー名とドメイン名とを含む情報をローカルユーザー情報と呼ぶことにする。
【００３０】
＜データ変換サーバー１０８のソフトウェア構成＞
データ変換サーバー１０８は、Ｗｅｂサーバー１０８１、データ変換部１０８２、データ変換情報管理部１０８３、文書情報７００、データ変換情報７１０、テナント設定情報７２０を格納するストレージを有する。各ソフトウェアモジュールは図２（ａ）で示した記憶装置２２６に記憶されており、前述したようにＣＰＵ２２０によってＲＡＭ２２２にロードされ実行される。Ｗｅｂサーバー１０８１はデータ変換サーバー１０８の各種インターフェースを提供し、受け付けた情報の妥当性の検証を行う。そして認可サーバー１０６に対して認可トークン検証リクエストや認可トークン情報取得リクエストを行う。データ変換部１０８２は、プリンター１０３からのリクエストに応じて、文書情報７００として管理される帳票ＰＤＦをプリンター１０３で解釈可能な印刷データに変換を行う。データ変換情報管理部１０８３は、帳票サーバー１０７によってストレージサーバー１０９に保存された帳票ＰＤＦを文書情報７００として管理するとともに、データ変換部１０８２で生成した印刷データをデータ変換情報７１０として管理する。さらに、データ変換情報管理部１０８３は、テナント設定情報７２０を管理し、Ｗｅｂサーバーが受け付けた印刷データ生成リクエストに応じて、データ変換部１０８１で印刷データを生成する。
【００３１】
図１０（ａ）に、データベースに保存されている文書情報７００の例を示す。文書情報７００は、データ変換サーバー１０８により帳票ＰＤＦ保存リクエスト受信時に生成される。１つのリクエストについて１レコードが生成される。文書ＩＤ７０１は、データ変換サーバー１０８が帳票ＰＤＦ保存リクエストを受信した際に発行する、文書を一意に識別する識別子である。テナントＩＤ７０２は、帳票ＰＤＦ保存リクエストした要求元のテナントのテナントＩＤすなわち一意に識別するための識別子であり、ユーザーＩＤ７０３は、帳票ＰＤＦ保存リクエストした要求元のテナントのユーザーのユーザーＩＤである。ユーザーＩＤ７０３には、認可サーバー１０６で管理されるクライアントＩＤやローカル認証サーバー１０４で管理されるローカルユーザー情報（ユーザー名３０２＠ドメイン名３０１）が登録される。文書ＵＲＬは帳票ＰＤＦが保存されているストレージサーバー１０９のＵＲＬパスである。
【００３２】
図１０（ｂ）に、データベースに保存されているデータ変換情報７１０の例を示す。
データ変換情報７１０は、データ変換サーバー１０８により印刷データ生成リクエスト受信時に生成される。１つのリクエストについて１レコードが生成される。データ変換ＩＤ７１１は、データ変換サーバー１０８が印刷データ生成リクエストを受信した際に発行する、データ変換処理を一意に識別する識別子である。テナントＩＤ７１２、ユーザーＩＤ７１３は、データ変換サーバー１０８が印刷データ生成リクエスト受信時に生成する、データ変換対象の文書情報７００のテナントＩＤ７０１、ユーザーＩＤ７０３とそれぞれ同じ値である。データＵＲＬは、データ変換サーバー１０８が生成する印刷データの保存先であるストレージサーバー１０９のＵＲＬである。なお、データ変換情報７１０には文書ＩＤのフィールドをさらに含めて、文書情報７００との関連付けを行ってもよい。
【００３３】
図９（ｃ）に、データベースに保存されているテナント設定情報７２０の例を示す。テナント設定情報７２０はデータ変換サーバー１０８におけるテナント毎の設定情報である。テナントＩＤ７２１の設定としてローカル認証連携モードを保持する。ローカル認証連携モードはローカル認証セキュリティドメイン１１０との連携をするか否かをｔｒｕｅ／ｆａｌｓｅで示す。たとえばｔｒｕｅは連携することを、ｆａｌｓｅは連携しないことを示す。テナント設定情報７２０に含まれた各テナントのローカル認証連携モードの設定は、各テナントのクライアントが保持するローカル認証連携情報と同期するのが望ましい。例えば、データ変換サーバー１０８のテナント設定情報７２０が設定されたなら、それをテナントに分配したり、逆にテナントにおいて設定されたローカル認証連携情報をデータ変換サーバー１０８が収集したり、あるいはその両方をおこなうことで同期を維持する。
【００３４】
＜ストレージサーバー１０９のソフトウェア構成＞
ストレージサーバー１０９はＷｅｂサーバー１０９１、ストレージ管理部１０９２、ファイル情報８００を格納するストレージを有する。各ソフトウェアモジュールは図２（ｂ）で示した記憶装置２２６に記憶されており、前述したようにＣＰＵ２２０によってＲＡＭ２２２にロードされ実行される。Ｗｅｂサーバー１０７１はストレージサーバー１０９の各種インターフェースを提供し、受け付けた情報の妥当性の検証を行う。そして不図示のストレージ認可サーバーに対して認可トークン検証リクエストを行う。ストレージ管理部１０９２は図８で説明するファイル情報８００を管理し、アップロードリクエストされたファイルの入出力を行う。ストレージは図８で説明するストレージサーバー１０９が保持している情報やストレージサーバー１０９受信したファイルが格納されている。
【００３５】
図１１に、データベースに保存されているファイル情報８００の例を示す。
ファイル情報８００はストレージサーバー１０９に保存するファイルの情報である。データＵＲＬはストレージサーバー１０９に保存するファイルを一意に特定することができるＵＲＬである。ファイルパスはストレージ上のファイルパスでありファイルの格納場所を示す。データＵＲＬに対してリクエストすることによりストレージのファイル操作を行うことができる。たとえば、データＵＲＬに対してＨＴＴＰ  ＧＥＴメソッドをリクエストすると対応するファイルがダウンロードできる。データＵＲＬに対してＨＴＴＰ  ＰＵＴメソッドにファイル添付してリクエストするとファイルをアップロードし保存できる。データＵＲＬに対してＨＴＴＰ  ＤＥＬＥＴＥメソッドをリクエストすると対応するファイルを削除できる。
【００３６】
＜ユーザー認可設定フロー＞
図３は、本実施の形態における、顧客テナントの代表ユーザーの権限のプリンター１０３への委譲を認可するフローを示した図である。
Ｓ３．１において、クライアント端末１０２のWebブラウザー１０２１は、プリンター１０３へ、必要なスコープを指定して、ユーザー認可設定リクエストを送信する。本実施形態では、たとえばプリンター１０３がデータ変換サーバー１０８のインターフェースにアクセスする際に必要なスコープであるPrintがスコープとして指定される。
Ｓ３．２において、プリンター１０３の認可サーバー連携クライアント１０３２は、ユーザー認可設定リクエストを受け付けると、認可設定画面へのリダイレクト指示をWebブラウザー１０２１に返す。そのリダイレクト指示は、Webブラウザー１０２１に、プリンター１０３の情報と必要な権限のスコープとを含む認可リクエストを認可サーバー１０６へ送信させるための指示である。
Ｓ３．３において、Webブラウザー１０２１は、受け取ったリダイレクト指示に従って認可サーバー１０６に対して認可設定画面リクエストを送信する。
Ｓ３．４において、認可サーバー１０６はWebサーバーで認可設定画面リクエストを受け取ると、認可設定画面リクエストに認証情報が付加されていない場合、ログイン状態でないと判断し、ログイン画面を返す。認証情報が付加されており、既にログインしている状態と判断した場合、認可サーバー１０６はクライアント情報５００を参照し、ログインユーザーを特定する。
【００３７】
ここで、図４（ａ）は、Ｓ３．３のリクエストに対するレスポンスとしてWebブラウザー１０２１が認可サーバー１０６から受け取り、表示するログイン画面の例である。Webブラウザー１０２１は、ログインボタン９０４押下によって、ユーザーの入力により予め認可サーバーに登録されているユーザー情報として、テナントID９０１、クライアントID９０２、パスワード９０３とともに、ログインリクエストを認可サーバー１０６に送信する。
認可サーバー１０６はログインリクエストを受け付けると、クライアント情報５００を参照してリクエストに含まれるテナントID、クライアントID、パスワードを検証する。すなわち、入力された認証情報と一致するレコードがクライアント情報５００に含まれているか判定する。検証の結果ログインが成功すると、ログインしたクライアント情報を特定することができ、Webブラウザー１０２１に認証情報を返す。Webブラウザー１０２１は、認証情報を各リクエストに付加することで、認証状態を保持することができ、各サーバーは認証情報からログイン中のユーザー情報を特定できる。
【００３８】
一方、Ｓ３．３の認可設定画面リクエストに認証情報が添付されていた場合、認可サーバー１０６は、ログイン中のユーザー情報５００を特定するとＳ３．３のリクエストに対するレスポンスを返す。このレスポンスとして、認可設定画面リクエストに含まれるスコープ、プリンター情報、ユーザー情報５００を含む認可確認画面９１０をWebブラウザーに返す。図４（ｂ）は、Webブラウザー１０２１に表示する認可確認画面９１０の例である。この例では、認可を確認するメッセージとともに、使用するクライアントID、テナントID、認可するプリンターのIPアドレスと、Scopeに紐づく権限を示す画面９１１を表示している。また、認可の実行を受け付けるためのＯＫボタン９１２と拒否するためのＮＧボタン９１３とを表示する。
【００３９】
クライアント端末１０２のWebブラウザー１０２１は、認可確認画面９１０において、OKボタン９１２の押下による認可実行を受け付けると、Ｓ３．４において、認可サーバー１０６に認可トークン生成リクエストを送信する。認可サーバー１０６は、認可トークン生成リクエストを受け付けると、ユーザー情報５００を参照し、認可トークン生成リクエストのパラメータであるスコープが該当するログイン中のユーザー情報５００に含まれるかを判定する。含まれる場合は認可トークンを生成し、認可トークン情報５１０に登録する。スコープが該当するユーザー情報５００に含まれない場合は、Webブラウザー１０２１にエラーを返す。認可サーバー１０６は、Ｓ３．４のレスポンスとして、生成した認可トークンをWebブラウザーに返す。
Ｓ３．５において、Webブラウザー１０２１は、認可サーバー１０６から受け取った認可トークンを、代表トークン登録リクエストとともにプリンター１０３の認可サーバー連携クライアント１０３２に送信する。プリンター１０３の認可サーバー連携クライアント１０３２は代表トークン登録リクエストを受け付けると、代表トークン情報４００として、受信した認可トークンの認可トークンＩＤ、クライアントＩＤ、テナントＩＤをそれぞれ登録する。
【００４０】
このフローにより、認可サーバー１０６に登録されているユーザー情報５００の権限をプリンター１０３に委譲することができ、プリンター１０３はこの代表トークン情報４００を使用することで、該当のユーザー情報５００の権限でデータ変換サーバー１０８にアクセスすることができる。この手順では、ログイン中の、あるいはログインしたユーザーをクラウドサービスの代表クライアントとして認可トークンを取得し、それを代表トークンとしてプリンター１０３に登録することで、クライアントの権限をプリンター１０３に委譲することができる。プリンター１０３は例えば後述する図５の手順で、委譲された権限を行使して文書の印刷等を実行できる。
【００４１】
＜認証プリント＞
図５は、本実施の形態における、認証プリントを行うフローを示した図である。ここでは、図３のユーザー認可設定フローが済んでおり、認可サーバー１０６のユーザー情報５００で管理されるユーザーによってプリンター１０３が認可され、代表トークン情報４００がプリンター１０３に登録されているものとする。図５のシーケンスでは、プリンター１０３がクラウドサービスのクライアントであり、プリンター１０３をクライアントデバイスとも呼ぶ。図５において、Ｓ５．Ｘはリクエストを示し、Ｓ５．ＸＲは、Ｓ５．Ｘのリクエストに対する応答を示す。
Ｓ５．１において、プリンター１０３のログインアプリは、ICカードリーダー２４２からドメイン名、ユーザー名、パスワードから成るローカル認証情報を受け付けると、Ｓ５．２において、ローカル認証サーバー１０４にユーザー認証リクエストを送信する。
ローカル認証サーバー１０４は、ローカル認証情報３００を参照し、リクエストに含まれるローカル認証情報と照合して結果をプリンターに返す。ローカル認証情報３００に該当するレコードがあれば認証は成功である。
プリンター１０３は、ローカル認証サーバー１０４から受け取った認証結果が失敗であった場合、エラーとして処理を終了する。認証結果が成功であった場合、プリンター１０３のログインアプリ１０３１は、ログインしたユーザーのローカル認証情報をプルプリントアプリ１０３３に渡す。さらに、プルプリントアプリ１０３３は、認可サーバー連携クライアント１０３２に対して、スコープとアプリケーションＩＤとを含む認可トークン取得リクエストを送る。ここで、プルプリントアプリ１０３３は、認可トークン生成リスエストに含めるアプリケーションIDとして指定する値をローカル認証連携情報４３０に応じて決定する。プルプリントアプリ１０３３は、ローカル認証連携情報４３０のローカル認証連携モードの値がtrueであった場合、アプリケーションIDとしてローカルユーザー情報（ユーザー名＠ドメイン名）を指定する。ローカル認証連携モードの値がfalseの場合にはデフォルトの値を使用する。本実施形態では、デフォルトの値として、プリンター１０３上で動作しているプルプリントアプリ１０３３を識別する予め決められたIDとする。しかし、任意の文字列、または、アプリケーションIDを指定しなくてもてもよい。
【００４２】
Ｓ５．３において、プリンター１０３の認可サーバー連携クライアント１０３２は、代表トークン情報４００の認可トークンとScope、アプリケーションIDを含む認可トークン生成リクエストを認可サーバー１０５に送信する。
認可サーバー１０６は、プリンター１０３から認可トークン生成リクエストを受け取ると、後述の図６に示す＜認可サーバー１０６の認可トークン発行フロー＞によって、認可トークンの発行を行いプリンター１０３に返す。認可サーバー連携クライアント１０３２は受け取った認可トークンをプルプリントアプリ１０３３に渡す。プルプリントアプリ１０３３は、認可トークンＩＤと、アプリケーションＩＤに含まれたローカルユーザー情報とを、認可トークンＩＤ４２１、ユーザー名４２２、ドメイン名４２３として認可トークン情報４２０に保持する。
Ｓ５．４において、プルプリントアプリ１０３３は、データ変換サーバー１０８に、Ｓ５．３で取得した認可トークンを含む文書情報取得リクエストを送信する。データ変換サーバー１０８は、文書情報取得リクエストを受け付けると、Ｓ５．４−１において、後述の＜データ変換サーバー１０８の認可トークン検証フロー＞（図６参照）を処理し、認可サーバー１０６に対して認可トークン検証リクエストを行って、認可トークンが正当なものであれば、当該認可トークンに対応する認可トークン情報５１０を取得する。認可トークン情報５１０にはアプリケーションＩＤが含まれており、それはＳ５．１でプリンター１０３にログインしたユーザーのローカルユーザー情報である。その場合データ変換サーバー１０８は、Ｓ５．４で決定したユーザーＩＤで、文書情報７００から該当するレコードを抽出し、Ｓ５．４のレスポンスとしてプリンター１０３に返す。
【００４３】
Ｓ５．５において、プリンター１０３のプルプリントアプリ１０３３は、Ｓ５．４で取得した文書情報７００を参照し、認可トークンと、文書ＩＤを含めた印刷データ生成リスエストとを変換サーバー１０８に送信する。データ変換サーバー１０８は、印刷データ生成リクエストを受け付けると、Ｓ５．５−１において、Ｓ５．４−１と同様に認可サーバー１０６に対して認可トークン検証リクエストを行って認可トークン情報５１０を取得し、ユーザーＩＤを特定する。さらに、データ変換サーバー１０８は、印刷データ生成リクエストに含まれる文書ＩＤと、Ｓ５．５−１で特定したユーザーＩＤとを使用して、文書情報７００から該当のレコードを抽出する。さらに、データ変換サーバー１０８は、抽出した文書情報７００の文書ＵＲＬを参照し、Ｓ５．５−２において、ストレージサーバー１０９から該当の文書データファイルを取得する。最後に、データ変換サーバー１０８は、Ｓ５．５−２で取得した文書データを印刷データに変換するとともに、変換して得た印刷データに対応するデータ変換ＩＤを新規に発行し、データ変換情報７１０にそのデータ変換ＩＤを持つレコードを登録する。さらにデータ変換サーバー１０８は、ストレージサーバー１０９に変換後の印刷データをアップロードし、データ変換情報７１０の印刷ＵＲＬ７１４に、アップロードした印刷データにアクセスするためのＵＲＬを登録する。データ変換サーバー１０８は、新規に登録した変換データ情報７１０の印刷ＵＲＬ７１４をＳ５．５の印刷データ生成リクエストのレスポンスとしてプリンター１０３に返す。
Ｓ５．６において、プリンター１０３のプルプリントアプリ１０３３は、Ｓ５．５の印刷データ生成リクエストで取得した印刷ＵＲＬにアクセスすることで印刷データの取得を行い、取得した印刷データをラスタコントローラ２３７、プリントエンジン２３８に転送し印刷を実行する。
【００４４】
＜認可サーバー１０６の認可トークン発行フロー＞
図６は認可サーバー１０６が認可トークン生成リクエスト（Ｓ５．３）を受信したときの認可トークン発行の処理フローの詳細である。
Ｆ６０１において認可サーバー１０６は認可トークン生成リクエストを受信する。認可サーバー１０６は認可トークン生成リクエストのパラメータとして代表認可トークン、スコープ、アプリケーションＩＤを受け取る。
Ｆ６０２において認可サーバー１０６は認可トークン情報５１０からＦ６０１で受信した代表認可トークンと一致するレコードを特定する。
Ｆ６０３において認可サーバー１０６はＦ６０２で特定したクライアント情報５００のスコープ５０３が、Ｆ６０１で受信したスコープと一致するか判定する。一致しない場合エラーとする（Ｆ６０５）。
Ｆ６０４において認可サーバー１０６は認可トークンＩＤを発行し、Ｆ６０１で受信したクライアントＩＤ、スコープ、アプリケーションＩＤを含むレコードを認可トークン情報５１０に登録する。本実施形態の前述Ｓ５．３のフローにおいては、ローカル認証連携モードがセットされていればアプリケーションＩＤにローカル認証情報（ユーザー名＠ドメイン名）が指定されるが、ローカル認証連携しないクライアントからのリクエストの場合、アプリケーションＩＤには空または異なる値が登録される。
【００４５】
＜データ変換サーバー１０８の認可トークン検証フロー＞
図７は、データ変換サーバー１０８が各種リクエスト（Ｓ５．４、Ｓ５．５）を受信したときの認可トークン検証の処理フローの詳細である。
Ｆ７０１において、データ変換サーバー１０８はリクエストを受信する。またリクエストのパラメータとして認可トークンを受信する。
Ｆ７０２において、データ変換サーバー１０８は認可サーバー１０６に対して認可トークン検証リクエストを行う。認可トークン検証リクエストの結果、認可トークン情報が得られなかった場合エラーとする（Ｆ７０６）。
Ｆ７０３において、データ変換サーバー１０８は、テナント設定情報７２０から認可トークン情報のテナントＩＤと一致するレコードを特定し、そのテナントのローカル認証連携モードが有効(true)であるかを判断する。
Ｆ７０３において、テナントのローカル認証連携モードが有効だった場合、データ変換サーバー１０８はＦ７０４において、認可トークン情報のテナントＩＤとアプリケーションＩＤに登録されているローカルユーザー情報３００（ユーザー名＠ドメイン名）を一意のユーザーとしてリクエストを処理する。
Ｆ７０３において、テナントのローカル認証連携モードが無効だった場合、データ変換サーバー１０８はＦ７０５において、認可トークン情報５１０のユーザーＩＤを一意のユーザーとしてリクエストを処理する。
【００４６】
以上のように、認可トークン発行時にローカルユーザー情報を紐付けておくことで、認可トークン利用時に認可トークン情報からローカルユーザー情報を取得することができ、データ変換サーバー１０８でローカル認証サーバー１０４のユーザーを一意のユーザーとして認識することができる。例えば認可トークンに紐づいたローカルユーザー情報をデータ変換サーバー１０８の課金処理や処理集計処理で一意のユーザーとして処理することで、ローカル認証サーバー１０４と連動して運用することができる。ローカル認証セキュリティドメイン１１０と帳票サービスセキュリティドメイン１１１の間でＩＤプロビジョニングする必要がなく運用負荷を下げることができる。また、業務サーバー１０５は一つのクライアントを使いまわして認可トークンを発行しているが、発行した認可トークンの利用はローカル認証情報で限定されるため、認可トークンで他のユーザーの情報にアクセスすることはできないためセキュアに認証連携することができる。
さらに、ローカル認証連携モードの有効／無効をテナント毎の設定として持つことによって、マルチテナント時に特定のテナントのみローカル認証連携を行うことができ、認証・認可において柔軟に顧客ニーズに応えることが出来る。
【００４７】
［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００４８】
１０２  クライアント端末、１０３  プリンター、１０４  ローカル認証サーバー、１０６  認可サーバー、１０８  データ変換サーバー、１０９  ストレージサーバー
【図１】
0006682254.tif 000002
【図２】
0006682254.tif 000003
【図３】
0006682254.tif 000004
【図４】
0006682254.tif 000005
【図５】
0006682254.tif 000006
【図６】
0006682254.tif 000007
【図７】
0006682254.tif 000008
【図８】
0006682254.tif 000009
【図９】
0006682254.tif 000010
【図１０】
0006682254.tif 000011
【図１１】
0006682254.tif 000012