JP2017091221A - 権限委譲システム、その制御方法、認可サーバ及びプログラム - Google Patents

Abstract

【課題】ユーザの権限を委譲されたクライアントから、さらに別のクライアントに権限を委譲するシステムを提供する。
【解決手段】権限委譲システムは、第１、第２のクライアントおよびサービス提供装置と、認可サーバとを含む。第１のクライアントは、ユーザから第１のクライアントに対し特定の権限が委譲されたことを示す第１の認可情報を基に第２のクライアントのサービスを利用する。認可サーバは、利用に伴い送信される第１の認可情報から第１のクライアントを特定し、特定された第１のクライアントと第２のクライアントが関連付いているか否かを確認し、関連付いていると確認されたことに応じ、第２のクライアントに対し特定の権限が委譲されたことを示す第２の認可情報を発行する。第２のクライアントは、提供された第２の認可情報を基に、サービス提供装置のサービスを利用する。
【選択図】図７

Description

本発明は、権限委譲システム、その制御方法、認可サーバ及びプログラムに関する。

近年、クラウドサービスと呼ばれるインターネットを介してソフトウェアの機能を提供するサービスの利用が拡大している。例えば、インターネット上でＰＤＦ形式の電子文書を作成するサービスや電子文書を蓄積するサービスがある。このようなサービスを利用することでユーザは、自身が所有する端末自体にＰＤＦ作成機能がない場合でもＰＤＦを作成できるようになる他、端末の記憶容量以上に電子文書を保管できるようにもなる。さらに、クラウドサービスを連携させて付加価値を高めることができる。例えば、前述のクラウドサービスでＰＤＦ形式の電子文書を作成し、さらに作成した電子文書をユーザの所有する端末を経由することなく、直接インターネット上の電子文書を蓄積するサービスに保管できる、といったことが、サービス連携により実現できる。
従来、このようなサービス連携を実現するために、ＯＡｕｔｈと呼ばれる、権限委譲の標準プロトコルが広く利用されている。ＯＡｕｔｈについては以降で説明する。

クラウドサービスの利用が増加する中で、３つ以上のクラウドサービスを連携させたサービスを提供したいという要求がある。そのために、ユーザの権限を委譲されたクライアントが第１のリソースサービスを利用し、さらに第１のリソースサービスがクライアントとなって第２のリソースサービスを利用したい。そこで特許文献１は、アプリケーションを追加・削除可能なデバイスにおいて、ユーザがデバイスに権限委譲し、さらにデバイスがデバイス内アプリケーションに権限委譲するという、デバイス内で２段階の権限委譲をする技術を開示している。このＯＡｕｔｈを拡張した技術では、ユーザが認可確認をしてデバイスに権限委譲すると、その後は認可操作なしでデバイスからデバイス内のアプリケーションに権限委譲できる。

特開２０１４−０９９０３０号公報

しかしながら、特許文献１では、最初の権限委譲はデバイスに対して行うことしかできず、また２段階目の権限委譲もデバイス内のアプリケーションにしか行うことができない。

本発明は、ユーザの権限を委譲されたクライアントから、さらに別のクライアントに権限を委譲するシステムを提供することを目的とする。

上記課題を解決するために、本発明は、ネットワークを介してサービスを提供する第１のクライアントおよび第２のクライアントおよびサービス提供装置と、認可サーバとを含む権限委譲システムを提供する。第１のクライアントは、ユーザから前記第１のクライアントに対し特定の権限が委譲されたことを示す第１の認可情報を基に、前記第２のクライアントのサービスを利用する第１の利用手段を有する。認可サーバは、前記第１の利用手段による利用に伴い送信される前記第１の認可情報から前記第１のクライアントを特定し、特定された前記第１のクライアントと前記第２のクライアントが関連付いているか否かを確認する確認手段と、前記確認手段により関連付いていると確認されたことに応じ、前記第２のクライアントに対し特定の権限が委譲されたことを示す第２の認可情報を発行する発行手段とを有する。第２のクライアントは、前記発行手段から提供された前記第２の認可情報を基に、前記サービス提供装置のサービスを利用する第２の利用手段を有する。

本発明によれば、ユーザの権限を委譲されたクライアントから、さらに別のクライアントに権限委譲できる。

システム構成図である。 各装置のハードウェア構成図である。 各装置のソフトウェアモジュール構成図である。 ３つのサービスを連携したサービスの処理シーケンス図である。 ３つのサービスを連携したサービスの処理シーケンス図である。 認可処理に関連する画面の例である。 第２の認可トークン発行時の信頼関係確認処理のフローチャートである。 ３つのサービスを連携したサービスの処理シーケンス図である。 クライアントの信頼関係確認処理のフローチャートである。 ユーザ管理テーブル及びクライアント管理テーブルを示す図である。 認可トークン管理テーブルを示す図である。 クライアント信頼関係管理テーブルを示す図である。

（第１実施形態）
まず、権限委譲システムの標準プロトコルであるＯＡｕｔｈについて説明する。ＯＡｕｔｈによれば、例えば、ユーザから権限委譲されたサービスＡが、サービスＢの管理するユーザのデータにアクセスできる。サービスＡのように、ユーザの権限を委譲されてユーザの代わりにサービスＢにアクセスするものをクライアントと呼ぶ。サービスＢのように、ユーザのデータを管理するものをリソースサーバ（サービス提供装置）と呼ぶ。クライアントがリソースサーバにアクセスする際、クライアントはアクセスするリソースの範囲を明らかにした上で、ユーザからアクセスに対する明示的な認可を得ることになっている。ユーザが明示的に認可を行うことを認可操作と称する。
ユーザが認可操作を行うと、クライアントはリソースサーバへのアクセスを認められたことを証明するトークン（以下、認可トークンと称する）を受け取る。以降、クライアントはその認可トークンを用いてリソースサーバにアクセスできるようになる。
認可トークンを用いるとクライアントは、ユーザの認証情報なしに、認可を行ったユーザの権限でリソースサーバにアクセスできる。そのため、ＯＡｕｔｈでは、セキュリティの観点から、クライアント・リソースサーバが認可トークンを外部に漏洩させてはいけないことを規定している。各クラウドサービスは、認可トークンを外部に漏洩しないように厳重かつ適正に管理する責務を負う。

ＯＡｕｔｈの認可トークンを利用して３つ以上のサービスを連携する方法として考えられる方法は、複数のサービスを利用するための認可トークンを取得して、この認可トークンをサービス間で受け渡していく方法である。しかしながら、ＯＡｕｔｈでは、セキュリティの観点から、認可トークンの受け渡しをクライアントとサービスの間のみに制限し、外部に認可トークンを漏らすことを禁止している。リソースサービスが別の外部リソースサービスに認可トークンを受け渡しすると、認可トークンの漏洩リスクが生じる。認可トークンを詐取した第三者は、ユーザの認証情報なしに、認可を行ったユーザの権限で複数のリソースサービスを利用できるようになってしまう。
そこで、本実施形態においては、サービス間で権限委譲する際に、ある認可トークンから権限を引き継ぐ新たな認可トークンを発行して、その認可トークンを受け渡すことで、ユーザの権限をサービス間で委譲させていく手段をとる。こうすることで、ＯＡｕｔｈの規定を遵守しながら、サービス間での権限委譲が実現できる。

また、３つ以上のサービス間での権限委譲では、ユーザの知らないところで、サービスから別のサービスに権限委譲がなされてしまう可能性がある。そこで、本実施形態においては、認可トークンの漏洩リスクを低減し、かつ、サービスが別のサービスに権限委譲することについてユーザの同意を得た上で、３つ以上のサービスの連携を実現するようにする。

本実施形態においては、オフィスフロアのプリンタを管理するフロア機管理サービス、帳票データを生成する帳票サービス、データを取得して印刷する印刷サービスが、インターネット上のサーバに設置されていることを想定している。以降、フロア機管理サービス、帳票サービス、印刷サービスのように、インターネット上で機能を提供しているサービスを、リソースサービスと呼ぶ。本実施形態においては、前述のフロア機管理サービス、帳票サービス、印刷サービスを連携することで、フロア機の利用状況のデータを帳票データに加工し、さらに、その帳票データを印刷するサービスを説明する。
また本実施の形態においては、ＰＣ、携帯端末のようなユーザ端末上のＷｅｂブラウザーやネィティブアプリケーションから上記サービスを利用することを想定している。ユーザ端末上のＷｅｂブラウザーやアプリケーションをサービス連携アプリケーションと呼ぶ。なお、本願発明を適用できるリソースサービスは、フロア機管理サービス、帳票サービス、印刷サービスには限られるものではない。

本実施形態に係る権限委譲システムは、図１に示すような構成のネットワーク上に実現される。
ＷＡＮ１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ）であり、本実施形態ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。ＬＡＮ１０１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）である。
認可サーバ２００はＯＡｕｔｈを実現するための認可サーバである。フロア機管理サーバ２２０、帳票サーバ２４０、印刷サーバ２６０はリソースサーバとして、認可サーバ２００と連携してユーザに各々のサービスを提供する。フロア機管理サーバ２２０は第１のクライアントであり、帳票サーバ２４０は第２のクライアントであり、印刷サーバ２６０はサービス提供装置に該当する。なお１台のリソースサーバに設置されるリソースサービスは１つでもよく、複数でもよい。また、認可サーバ、および、リソースサーバは１台ではなく複数台で構成されるサーバ群であってもよい。
ユーザ端末３００はパソコン、スマートフォンなどの情報機器であり、Ｗｅｂブラウザーやアプリケーションがインストールされている。ユーザはＷｅｂブラウザーやアプリケーションを用いてリソースサーバのサービスを利用する。また認可サーバ２００、フロア機管理サーバ２２０、帳票サーバ２４０、印刷サーバ２６０、ユーザ端末３００はそれぞれＷＡＮ１００およびＬＡＮ１０１を介して接続されている。なお認可サーバ２００、リソースサーバであるフロア機管理サーバ２２０、帳票サーバ２４０、印刷サーバ２６０、ユーザ端末３００はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また認可サーバ２００、リソースサーバであるフロア機管理サーバ２２０、帳票サーバ２４０、印刷サーバ２６０は同一のサーバ上に構成されていてもよい。

本実施形態に係る権限委譲システムは、図２に示すような構成の情報処理装置から成るシステム上に実現される。図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものである。本実施形態の認可サーバ２００、フロア機管理サーバ２２０、帳票サーバ２４０、印刷サーバ２６０、ユーザ端末３００のハードウェア構成を適用できる。

図２において、ＣＰＵ２０１は、ＯＳやアプリケーション等のプログラムを実行しシステムバス２０４に接続される各ブロックを制御する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各シーケンスの処理はこのプログラムの実行により実現できる。ＯＳやアプリケーションは、ＲＯＭ２０３のプログラム用ＲＯＭやハードディスク（ＨＤ）等の外部メモリ２１１に記憶され、ＲＡＭ２０２にロードされる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード２０９や不図示のポインティングデバイスからのキー入力を制御する。ＤＳＰコントローラ（ＤＳＰＣ）２０６は、ディスプレイ（ＤＳＰ）２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は、各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２１１におけるデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２０８は、ＷＡＮ１００もしくはＬＡＮ１０１を介して接続されたユーザ端末３００や他の機器との通信制御処理を実行する。
なお、後述の全ての説明においては、特に断りのない限りサーバにおける実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体は外部メモリ２１１にインストールされたアプリケーションプログラムである。

図３は本実施の形態に係る、認可サーバ２００、フロア機管理サーバ２２０、帳票サーバ２４０、印刷サーバ２６０、ユーザ端末３００のそれぞれのモジュール構成を示す図である。図３に示す何れのモジュールも、図２で示した各装置のＣＰＵが外部メモリにインストールされたアプリケーションプログラムをＲＡＭ上で実行することで実現されるモジュールである。
認可サーバ２００は認可サービスモジュール２１２を備える。認可サービスモジュール２１２は、ユーザ認証機能、クライアント認証機能、認可トークン発行機能、認可トークン検証機能を有する。フロア機管理サーバ２２０はフロア機管理サービスモジュール２２１を備える。フロア機管理サービスモジュール２２１はフロア機の利用状況をデータ出力する機能を有する。帳票サーバ２４０は帳票サービスモジュール２４１を備える。帳票サービスモジュール２４１は受領データから帳票データを生成する機能を有する。印刷サーバ２６０は印刷サービスモジュール２６１を備える。印刷サービスモジュール２６１は取得したデータを印刷する機能を有する。

ユーザ端末３００は、ＣＰＵがＯＳ３０２あるいは外部メモリに記憶されたＯＳを実行する事で各アプリケーションを制御する。ＯＳ３０２は、一般的にはＷｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標）等の汎用ＯＳやＡｎｄｒｏｉｄ（登録商標）、ｉＯＳ（登録商標）などのモバイル端末用ＯＳが使用される。
ユーザ端末３００は、サービス連携アプリケーション３０１を持つ。サービス連携アプリケーション３０１はＷＷＷを利用するためのユーザエージェントである。このサービス連携アプリケーション３０１はＷＷＷを利用できる一般的なＷｅｂブラウザーでもよいし、組込ブラウザーを内包するネィティブアプリケーションでもよい。なお、サービス連携アプリケーション３０１におけるサービス利用のシーケンスについては後述する。

図１０（Ａ）、図１０（Ｂ）、図１１、図１２（Ａ）は認可サーバ２００が外部メモリに記憶するデータテーブルである。データテーブルは、認可サーバ２００の外部メモリではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバに記憶するよう構成する事も出来る。
図１０（Ａ）はユーザ管理テーブル１２００である。ユーザ管理テーブル１２００は、ユーザＩＤ１２０１、パスワード１２０２、ユーザ種別１２０３から成る。認可サービスモジュール２１２は、ユーザＩＤ１２０１、パスワード１２０２の情報の組を検証し、正しければ認証情報を生成することで、各ユーザもしくはクライアントを認証する機能を備える。

図１０（Ｂ）はクライアント管理テーブル１３００である。クライアント管理テーブル１３００はクライアントＩＤ１３０１、クライアント名１３０２、リダイレクトＵＲＬ１３０３、アプリケーションＩＤ１３０４から成る。クライアントＩＤ１３０１は、ユーザ管理テーブル１２００のユーザＩＤ１２０１と関連付いており、互いに参照可能となっている。クライアント名１３０２、リダイレクトＵＲＬ１３０３は後述のＯＡｕｔｈのシーケンスで利用される値である。そして、アプリケーションＩＤ１３０４はクライアントがどのサービスで利用されるものかを特定するため値である。

図１１は認可トークン管理テーブル１４００である。認可トークン管理テーブル１４００は、認可トークンＩＤ１４０１、トークン種別１４０２、有効期限１４０３、スコープ１４０４、クライアントＩＤ１４０７、ユーザＩＤ１４０８、アプリケーションＩＤ１４０９から成る。さらに、認可トークン管理テーブル１４００は、リフレッシュトークンＩＤ１４０５、リフレッシュ期限１４０６も含む。これら認可トークン管理テーブル１４００の処理詳細については後述する。

図１２（Ａ）はクライアント信頼関係管理テーブル１５００である。クライアント信頼関係管理テーブル１５００は、トークン発行クライアント１５０１、権限委譲可能クライアント１５０２から成る。トークン発行クライアント１５０１、権限委譲可能クライアント１５０２は、クライアント管理テーブル１３００のアプリケーションＩＤ１３０４と関連付いており、互いに参照可能となっている。
クライアント信頼関係管理テーブル１５００は、サービス間で権限委譲する際にクライアント間での権限引き継ぎの可否判定に利用される。クライアント間の権限引継の可否判定の処理詳細は後述する。

図４及び図５を用いて、フロア機管理サービス、帳票サービス、印刷サービスの３つのサービスを連携したサービスを提供する処理を説明する。
図４及び図５は、３つのサービスを連携したサービスの処理のシーケンス図である。まず、ユーザがサービス連携アプリケーション３０１において、フロア機利用状況を帳票データ化して印刷するサービスの利用操作をする（Ｓ４０１）。すると、サービス連携アプリケーション３０１がフロア機管理サービスモジュール２２１にリソースサービス利用のリクエストを送信する（Ｓ４０２）。フロア機管理サービスモジュール２２１は、リソースサービス利用のリクエストを受け付けると、認可サービスモジュール２１２の認可エンドポイントに認可リクエストを送信する（Ｓ４０３）。これにより、フロア機管理サービスモジュール２２１をクライアントとする、ＯＡｕｔｈのフローが開始する。
このときフロア機管理サービスモジュール２２１は、送信する認可リクエストに、クライアントＩＤ、リクエストスコープ、リダイレクトＵＲＩをリクエストに含める。ここで、クライアントＩＤは、ｃｌｉ＿００００００００１を指定する。クライアントＩＤ「ｃｌｉ＿００００００００１」は、認可サーバのクライアント管理テーブル１３００に事前登録済みのフロア機管理サービスモジュール２２１のクライアントのクライアントＩＤである。リクエストスコープは、ＯＡｕｔｈで認可を受けたい権限範囲を示す値である。本実施形態では、３つのサービスを連携するために、リクエストスコープとして、フロア機利用状況出力、帳票、印刷の３つのスコープ値を指定したとして説明する。

認可サービスモジュール２１２は認可リクエストを受けると、フロア機管理サービスモジュール２２１を介してサービス連携アプリケーション３０１にログイン要求をする（Ｓ４０４）。この際、認可サービスモジュール２１２は、ユーザを認証するために、図６（Ａ）に示す認証画面であるログイン画面６０１をサービス連携アプリケーション３０１に表示する。
ユーザは、サービス連携アプリケーション３０１に示されたログイン画面６０１に対して、ユーザＩＤ、パスワードを入力して、ログインする（Ｓ４０５）。ここで、ユーザは図１０（Ａ）のユーザＩＤ「ｕｓｅｒ００１」のユーザＩＤ１２０１、パスワード１２０２の組を使ってログイン操作をする。すると、サービス連携アプリケーション３０１はフロア機管理サービスモジュール２２１を介して、認可サービスモジュール２１２にユーザが入力したユーザＩＤ、パスワードを含むログインリクエストを送信する（Ｓ４０６）。認可サービスモジュール２１２は、受信したユーザＩＤ、パスワードの情報の組を、ユーザ管理テーブル１２００に登録されている情報と合っているか検証する。登録されている情報と合っていれば、ログインしたユーザが正規のユーザであるとして、すなわち、認証成功として認証情報を生成する。もし、ユーザＩＤ、パスワードの情報の組が一致しなければ、認証エラーとして、認可サービスモジュール２１２がフロア機管理サービスモジュール２２１に再度Ｓ４０４のログイン要求を送信する。なお、Ｓ４０１の操作をする前にログイン済みの場合は、Ｓ４０４からＳ４０６の処理をスキップする。

認証が成功すれば、次に、認可リクエストに含まれているリダイレクトＵＲＬがフロア機管理サービスモジュール２２１のクライアントのリダイレクトＵＲＬかを検証する。その際、認可サービスモジュール２１２は、認可リクエストに含まれているクライアントＩＤとリダイレクトＵＲＬの組みが、クライアント管理テーブル１３００に登録されている情報と合っているか検証する（Ｓ４０７）。もし認可リクエストのリダイレクトＵＲＬとクライアントに登録されているリダイレクトＵＲＬが一致しない場合は、フロア機管理サービスモジュール２２１にリダイレクトＵＲＬのエラーレスポンスを返却する。なお、フロア機管理サービスモジュール２２１はリダイレクトのエラーをリダイレクトしてはいけない。

認可リクエストのリダイレクトＵＲＬとクライアントに登録されているリダイレクトＵＲＬが一致し、リダイレクトＵＲＬ検証が成功した場合、認可サービスモジュール２１２はクライアントが権限委譲可能なクライアントのリストを取得する（Ｓ４０８）。この処理では、まず、クライアント管理テーブル１３００から、フロア機管理サービスのクライアントのアプリケーションＩＤ１３０４を取得する。次に、クライアント信頼関係管理テーブル１５００で、前処理で取得したクライアントのアプリケーションＩＤ１３０４とトークン発行クライアント１５０１が一致するレコードの権限委譲可能クライアント１５０２を取得する。そして、クライアント管理テーブル１３００から、前処理で取得した権限委譲可能クライアント１５０２の値とアプリケーションＩＤ１３０４の値が一致するレコードを取得する。取得したレコードのリストが、フロア機管理サービスの権限委譲可能なクライアントのリストとなる。

そして、図６（Ｂ）に示す認可画面６０２を生成しサービス連携アプリケーション３０１に応答する（Ｓ４０９）。その際、Ｓ４０８で取得したフロア機管理サービスの権限委譲可能なクライアントのリストが認可確認画面に表示される。なお、認可確認画面には、本実施形態で説明した情報以外に、ここにクライアントの詳細な説明を追加して表示する事や、ログインしているユーザの情報を表示するよう構成する事もできる。また、認可リクエストにスコープを含む場合は、当該スコープの範囲を説明するアクセスするリソースに関する情報を認可画面６０２に表示するよう構成する事も出来る。また、認証情報をサービス連携アプリケーション３０１に対してＣｏｏｋｉｅ情報として格納して応答する。

次に、ユーザはサービス連携アプリケーション３０１に表示された認可画面６０２で権限委譲を許可する指示を行う（Ｓ４１０）。ユーザの指示を受けたサービス連携アプリケーション３０１は、認可サービスモジュール２１２に認可操作の結果である指示を返却する（Ｓ４１１）。
許可する指示を受けた認可サービスモジュール２１２は、次の処理を実行する。認可トークン管理テーブル１４００に認可コードを発行し、登録する。その際、認可トークンＩＤ１４０１に発行したトークンのＩＤ、トークン種別１４０２に認可コード、有効期限１４０３、および、認可リクエスト時に受け付けたクライアントＩＤをクライアントＩＤ１４０７に登録する。さらに、サービス連携アプリケーション３０１からＣｏｏｋｉｅとして送信された認証情報に紐づくユーザＩＤをユーザＩＤ１４０８に登録する（Ｓ４１２）。そして、認可コード応答として、サービス連携アプリケーション３０１のリダイレクトＵＲＬに対して認可コードの認可トークンＩＤを返却する（Ｓ４１３）。

認可コード応答を受けたフロア機管理サービスモジュール２２１は、認可サービスモジュール２１２に対して認可トークン要求を行う（Ｓ４１４）。この認可トークン要求には、認可コード応答で取得した認可コードの認可トークンＩＤ、フロア機管理サービスモジュールのクライアントＩＤ１３０１、クライアント名１３０２、リダイレクトＵＲＬ１３０３を含む。
認可トークン要求を受けた認可サービスモジュール２１２は以下の検証を行い、正しい場合は、第１の認可トークン（第１の認可情報）を生成する（Ｓ４１５）。認可サービスモジュール２１２は、トークン要求で受けつけたクライアントＩＤ、クライアント名の組が、ユーザ管理テーブル１２００に登録されているユーザＩＤ１２０１、パスワード１２０２の組と合っているか検証する。次に、トークン要求で受けつけた認可コードの認可トークンＩＤが、認可トークン管理テーブル１４００に登録されているか、有効期限内かを検証する。そして、トークン要求で受けつけたクライアントＩＤが、認可トークン管理テーブル１４００の認可トークンＩＤで特定されるクライアントＩＤ１４０７と合っているか検証する。さらに、トークン要求で受けつけたリダイレクトＵＲＬが、クライアント管理テーブル１３００のリダイレクトＵＲＬ１３０３と合っているかを検証する。ここで、リダイレクトＵＲＬ１３０３は、クライアント管理テーブル１３００ではなく、認可トークン管理テーブル１４００にカラムを追加し、認可コード発行時に登録して、該追加カラムと検証するよう構成する事もできる。

これらすべての検証が正しい場合に、認可サービスモジュール２１２は、認可トークンを生成する。その際、認可サービスモジュール２１２は認可トークン管理テーブル１４００に第１の認可トークンの情報を保存する。第１の認可トークンには、認可トークンＩＤ１４０１に発行したトークンのＩＤ、トークン種別１４０２に認可トークン、有効期限１４０３を登録する。第１の認可トークンにはさらに、認可コードから引き継ぐ情報として、クライアントＩＤ１４０７、ユーザＩＤ１４０８、アプリケーションＩＤ１４０９を登録する。この際登録されるアプリケーションＩＤは、クライアント管理テーブル１３００のクライアントＩＤ１３０１がクライアントＩＤ１４０７と一致するクライアントのアプリケーションＩＤ１３０４の値である。また、認可トークンをリフレッシュするためのリフレッシュトークンを発行し、リフレッシュトークンＩＤ１４０５、リフレッシュ期限１４０６を登録する。その後、生成した第１の認可トークンの認可トークンＩＤ１４０１をフロア機管理サービスモジュール２２１に応答する。この際、応答内容として同時に発行したリフレッシュトークンＩＤも含む（Ｓ４１６）。

フロア機管理サービスモジュール２２１はフロア機の利用状況のデータを出力する（Ｓ４１７）。そして、フロア機管理サービスモジュール２２１はＳ４１６で取得した第１の認可トークンとＳ４１７で出力したフロア機利用状況のデータを帳票サービスモジュール２４１に渡し、リソース要求として帳票出力を依頼する（Ｓ４１８）。リソース要求を受けた帳票サービスモジュール２４１は、要求に含まれる第１の認可トークンの認可トークンＩＤのトークン検証を認可サービスモジュール２１２に対して要求する（Ｓ４１９）。この認可トークン検証要求には、スコープを含める事ができる。

第１の認可トークン検証要求を受けた認可サービスモジュール２１２は、受け付けた認可トークンＩＤが、認可トークン管理テーブル１４００に登録されているか、有効期限内か、および、受け付けたスコープがスコープ１４０４の範囲内かを検証する。そして、検証結果を帳票サービスモジュール２４１に応答する（Ｓ４２０）。
検証の結果、アクセス許可と判断された場合は、帳票サービスモジュール２４１がフロア機の利用状況のデータを帳票出力する（Ｓ４２１）。

続いて、帳票サービスモジュール２４１が、認可サーバ２００に第２の認可トークン取得要求を行う（Ｓ４２２）。第２の認可トークン取得要求には、Ｓ４１８で受け取った認可トークンの認可トークンＩＤと、クライアント管理テーブル１３００に登録されている帳票サービスのクライアントのクライアントＩＤ、クライアント名、アプリケーションが含まれる。
第２の認可トークン取得要求を受けた認可サービスモジュール２１２は以下の処理を実行する。まず、第２の認可トークン取得要求に含まれるクライアントＩＤ、クライアント名の組がユーザ管理テーブル１２００のユーザＩＤ１２０１とパスワード１２０２の組と合っているかを検証する。正しい場合は、第２の認可トークン取得要求に含まれる認可トークンＩＤが認可トークン管理テーブル１４００に登録されており、有効期限内か確認する（Ｓ４２３）。

さらに、第２の認可トークン発行要求をしたクライアントが、第１の認可トークンの権限を委譲してよいクライアントか確認する（Ｓ４２４）。
この確認処理は、図７を用いて詳しく説明する。図７は、第２の認可トークン発行時の信頼関係確認処理のフローチャートである。
まず、認可サービスモジュール２１２が、認可トークン管理テーブル１４００を参照し、Ｓ４２２で受け取った第１の認可トークンを発行したクライアントを特定する情報を取得する（Ｓ７０１）。本実施形態では、第１の認可トークンを発行したクライアントを特定する情報として、第１の認可トークンのアプリケーションＩＤ１４０９を取得する。

次に、認可サービスモジュール２１２がクライアント管理テーブル１３００を参照し、第２の認可トークンの発行を要求したクライアントを特定する情報を取得する（Ｓ７０２）。本実施形態では、Ｓ４２２で受け取ったクライアントＩＤが一致するクライアントのアプリケーションＩＤ１３０４を取得する。
そして、認可サービスモジュール２１２は、第１の認可トークンを発行したクライアントと第２の認可トークン発行要求をしているクライアントが信頼関係にあるかどうかを確認するために、次の処理を行う。まず、認可サービスモジュール２１２は、クライアント信頼関係管理テーブル１５００を参照し、Ｓ７０１で取得した第１の認可トークンのアプリケーションＩＤとトークン発行クライアント１５０１が一致するレコードを取得する。次に、取得したレコードの権限委譲可能クライアント１５０２とＳ７０２で取得した第２の認可トークンを発行要求したクライアントのアプリケーションＩＤが一致するかどうか確認する（Ｓ７０３）。
Ｓ７０３でアプリケーションＩＤの値が一致しない場合は、信頼できないクライアントと判断し、エラーレスポンスを返却する（７０５）。

Ｓ７０３でアプリケーションＩＤの値が一致すれば、第１の認可トークンを発行したクライアントが、第２の認可トークン発行要求をしているクライアントを信頼していると判断する。その場合、認可サービスモジュール２１２は、第２の認可トークンを生成する（Ｓ７０４）。なお、本実施形態では、クライアントの信頼関係を確認するために、認可トークンのアプリケーションＩＤ属性とクライアントのアプリケーションＩＤを比較した。しかし、他にクライアントを特定できて、かつ、認可トークンとクライアントが共通にもつ属性があれば、その属性を使ってクライアントの信頼関係を確認してもよい。

第２の認可トークンは、新たに認可トークンＩＤを発行してそのＩＤを認可トークンＩＤ１４０１に、権限引継トークンをトークン種別１４０２に、第２の認可トークンの有効期限を有効期限１４０３に登録する。クライアントＩＤ１４０７には、第２の認可トークン発行要求をしたクライアントのクライアントＩＤを登録する。スコープ１４０４、ユーザＩＤ１４０８は、第２の認可トークン取得要求で受けつけた認可トークンＩＤによって特定されるレコードから値を引き継ぐ。アプリケーションＩＤ１４０９には、レコードのアプリケーションＩＤ１４０９に、第２の認可トークン発行要求で受け付けたクライアントのアプリケーションＩＤ１３０４の値を結合した値を保存する。レコードのアプリケーションＩＤ１４０９は、第２の認可トークン発行要求で受けつけた認可トークンＩＤによって特定されるレコードのアプリケーションＩＤ１４０９である。第２の認可トークンのアプリケーションＩＤ１４０９は、認可トークン発行時に経由したクライアントの特定に利用できる。そして、認可サービスモジュール２１２は、帳票サービスモジュール２４１に、生成した第２の認可トークンの認可トークンＩＤ１４０１を応答する（Ｓ４２５）。なお、第１の認可トークンから第２の認可トークンを発行する際の権限委譲については、Ｓ４１０で事前にユーザからの認可確認済みである。よって、改めてユーザに権限委譲することを通知しユーザの認可を受ける必要はないため、認可確認画面は表示しない。

その後、フロア機管理サービスモジュール２２１はＳ４２５で取得した第２の認可トークンとＳ４２１で出力したフロア機利用状況の帳票データを印刷サービスモジュール２６１に渡し、リソース要求として印刷を依頼する（Ｓ４２６）。
リソース要求を受けた印刷サービスモジュール２６１は、要求に含まれる第２の認可トークンの認可トークンＩＤの認可トークン検証を認可サービスモジュール２１２に対して要求する（Ｓ４２７）。認可トークン検証要求を受けた認可サービスモジュール２１２は、受け付けた認可トークンＩＤが、認可トークン管理テーブル１４００に登録されているか、有効期限内か、および、受け付けたスコープがスコープ１４０４の範囲内かを検証する。そして、検証結果を印刷サービスモジュール２６１に応答する（Ｓ４２８）。

検証の結果、アクセス許可と判断された場合は、印刷サービスモジュール２６１がフロア機の利用状況の帳票データを印刷する（Ｓ４２９）。
以上により、フロア機管理サービス、帳票サービス、印刷サービスを連携することで、フロア機の利用状況のデータを帳票データに加工し、さらに、その帳票データを印刷するサービスを実現できる。なお、本実施形態では、３つのサービスを連携したサービスの提供の例を説明したが、Ｓ４１８からＳ４２９の処理を繰り返すことで、３つ以上のサービスを連携したサービスも実現できる。

本実施形態によれば、認可トークンの漏洩リスクを低減し、かつ、ユーザの同意を得て、３つ以上のサービスに権限委譲することで、３つ以上のサービスの連携を実現できるようになる。

（第２実施形態）
第１実施形態では、権限委譲可能なクライアントが増減すると、その都度、クライアント信頼関係管理テーブル１５００にそのクライアントを追加する必要がある。また、ユーザに権限委譲するクライアントが増えることに同意してもらう必要がある。そこで、第２実施形態では、３つ以上のサービスを連携したサービスも実現する際に、権限委譲可能なクライアントが増減の度にクライアント信頼関係テーブルの情報をメンテナンスせずにすむようにすることを目的とする。
なお、第２実施形態は、第１実施形態とほぼ同様のため、異なる部分について以下、説明する。

図１２（Ｂ）は認可サーバ２００が外部メモリに記憶するクライアント信頼関係管理テーブル１６００である。クライアント信頼関係管理テーブル１６００は、第１実施形態の図１２（Ａ）と同様に、第１の認可トークンを発行したクライアントと第２の認可トークン発行要求をしているクライアントの信頼関係を確認するために用いる。クライアント信頼関係管理テーブル１６００において、権限委譲可能クライアント１６０２は、クライアントのアプリケーションＩＤと比較するための文字列である。権限委譲可能クライアント１６０２には、正規表現を含む文字列を設定できる。

図８は、第２実施形態におけるフロア機管理サービス、帳票サービス、印刷サービスの３つのサービスを連携したサービスを提供する処理シーケンスである。次のＳ８０１の処理が、第１実施形態の図４及び図５の処理シーケンスと異なる部分である。以下、処理内容を説明する。
認可サービスモジュール２１２はクライアントが権限委譲可能なクライアントのリストを取得する（Ｓ８０１）。この処理では、まず、クライアント管理テーブル１３００から、フロア機管理サービスのクライアントのアプリケーションＩＤ１３０４を取得する。次に、クライアント信頼関係管理テーブル１６００で、前処理で取得したクライアントのアプリケーションＩＤ１３０４とトークン発行クライアント１６０１が一致するレコードの権限委譲可能クライアント１６０２を取得する。そして、クライアント管理テーブル１３００から、前処理で取得した権限委譲可能クライアント１６０２の正規表現の値にマッチするアプリケーションＩＤ１３０４をもつクライアントのレコードを取得する。取得したリストが、フロア機管理サービスの権限委譲可能なクライアントのリストとなる。

図９は、第２の実施形態におけるクライアントの信頼関係確認処理を示す図である。次のＳ９０１の処理が第１実施形態と異なる部分である。以下、処理内容を説明する。
図８のクライアントの信頼関係確認処理では、図１２（Ａ）の代わりに図１２（Ｂ）を参照して、次の処理を行う。Ｓ７０２で第２の認可トークンを発行要求したクライアントのアプリケーションＩＤが、Ｓ８０１で取得したクライアント信頼関係管理テーブル１６００のレコードの権限委譲可能クライアント１６０２の正規表現にマッチするかどうかを確認する。（Ｓ９０１）。

第２実施形態では、クライアントのアプリケーションＩＤがｃｏｍ．ｅｘａｍｐｌｅ．＊またはｊｐ．ｅｘａｍｐｌｅ．＊に一致するクライアント全てに対する権限委譲について、ユーザの許可をあらかじめ取得しておくことができる。そのため、権限委譲可能なクライアントが増減にも対応できる。また、３つ以上のサービスを連携したサービスも実現する際に、権限委譲可能なクライアントが増減の度にクライアント信頼関係テーブルの情報をメンテナンスせずにすむようになる。

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

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

Claims (11)

1. ネットワークを介してサービスを提供する第１のクライアントおよび第２のクライアントおよびサービス提供装置と、認可サーバとを含む権限委譲システムであって、
   前記第１のクライアントは、
   ユーザから前記第１のクライアントに対し特定の権限が委譲されたことを示す第１の認可情報を基に、前記第２のクライアントのサービスを利用する第１の利用手段を有し、
   前記認可サーバは、
   前記第１の利用手段による利用に伴い送信される前記第１の認可情報から前記第１のクライアントを特定し、特定された前記第１のクライアントと前記第２のクライアントが関連付いているか否かを確認する確認手段と、
   前記確認手段により関連付いていると確認されたことに応じ、前記第２のクライアントに対し特定の権限が委譲されたことを示す第２の認可情報を発行する発行手段と、を有し、
   前記第２のクライアントは、
   前記発行手段から提供された前記第２の認可情報を基に、前記サービス提供装置のサービスを利用する第２の利用手段と、を有する
   ことを特徴とする権限委譲システム。
2. 前記認可サーバは、
   ユーザが操作する端末にて表示される認証画面を介して入力された認証情報を基に、前記ユーザが正規のユーザであるか否かを判断する認証手段と、
   前記発行手段は、さらに、前記認証手段により正規のユーザであると判断された前記ユーザが前記端末にて表示される認可画面を介し、前記第２のクライアントのサービスにおける前記ユーザの権限を前記第１のクライアントへ委譲することを許可する指示をした場合、前記ユーザの権限が前記第１のクライアントへ委譲されたことを示す前記第１の認可情報を発行する
   ことを特徴とする請求項１に記載の権限委譲システム。
3. 前記認可画面には、前記第２のクライアントのサービスにおける前記ユーザの権限を委譲する前記第１のクライアント、及び、前記第１のクライアントが権限委譲可能なクライアントのリストが表示されている
   ことを特徴とする請求項２に記載の権限委譲システム。
4. 前記認可サーバは、
   前記第１の利用手段による利用に伴い送信される前記第１の認可情報を基に、前記第１の利用手段が前記ユーザの権限で前記第２のクライアントのサービスを利用することを認可するか否かを検証する第１の認可手段と、
   前記第２の利用手段による利用に伴い送信される前記第２の認可情報を基に、前記第２の利用手段が前記ユーザの権限で前記サービス提供装置のサービスを利用することを認可するか否かを検証する第２の認可手段と、を有する
   ことを特徴とする請求項１乃至３のいずれか１項に記載の権限委譲システム。
5. 前記認可サーバは、
   クライアント間の権限引継の可否の情報を記憶する記憶手段を有し、
   前記確認手段は、前記記憶手段が記憶する前記クライアント間の権限引継の可否の情報に基づき、特定された前記第１のクライアントと前記第２のクライアントが関連付いているか否かを確認する
   ことを特徴とする請求項１乃至４のいずれか１項に記載の権限委譲システム。
6. 前記クライアント間の権限引継の可否の情報は、前記第１の認可情報に含まれるアプリケーションＩＤと前記第２のクライアントのアプリケーションＩＤの組み合わせである
   ことを特徴とする請求項１乃至５のうちいずれか１項に記載の権限委譲システム。
7. 前記クライアント間の権限引継の可否の情報は、前記第１の認可情報に含まれるアプリケーションＩＤと、前記第２のクライアントのアプリケーションＩＤと比較するための文字列の組み合わせである
   ことを特徴とする請求項１乃至５のうちいずれか１項に記載の権限委譲システム。
8. 前記第１の認可情報は、認可トークンＩＤ、トークン種別、有効期限、スコープ、クライアントＩＤ、ユーザＩＤ、アプリケーションＩＤ、リフレッシュトークンＩＤ、リフレッシュ期限のうち少なくとも１つ以上を含み、
   前記スコープは、前記第２のクライアント及び前記サービス提供装置で利用できるサービスの範囲であり、
   前記第２の認可情報は、認可トークンＩＤ、トークン種別、有効期限、スコープ、クライアントＩＤ、ユーザＩＤ、アプリケーションＩＤのうち少なくとも１つ以上を含む
   ことを特徴とする請求項１乃至７のうちいずれか１項に記載の権限委譲システム。
9. ネットワークを介してサービスを提供する第１のクライアントおよび第２のクライアントおよびサービス提供装置と、認可サーバとを含む権限委譲システムの制御方法であって、
   前記第１のクライアントは、
   ユーザから前記第１のクライアントに対し特定の権限が委譲されたことを示す第１の認可情報を基に、前記第２のクライアントのサービスを利用する第１の利用工程を有し、
   前記認可サーバは、
   前記第１の利用工程において利用に伴い送信される前記第１の認可情報から前記第１のクライアントを特定し、特定された前記第１のクライアントと前記第２のクライアントが関連付いているか否かを確認する確認工程と、
   前記確認工程において関連付いていると確認されたことに応じ、前記第２のクライアントに対し特定の権限が委譲されたことを示す第２の認可情報を発行する発行工程と、を有し、
   前記第２のクライアントは、
   前記発行工程より提供された前記第２の認可情報を基に、前記サービス提供装置のサービスを利用する第２の利用工程と、を有する
   ことを特徴とする権限委譲システムの制御方法。
10. ネットワークを介してサービスを提供する第１のクライアントおよび第２のクライアントおよびサービス提供装置と接続された認可サーバであって、
    ユーザが操作する端末にて表示される認証画面を介して入力された認証情報を基に、前記ユーザが正規のユーザであるか否かを判断する認証手段と、
    前記認証手段により正規のユーザであると判断された前記ユーザが前記端末にて表示される認可画面を介し、前記第２のクライアントのサービスにおける前記ユーザの権限を前記第１のクライアントへ委譲することを許可する指示をした場合、前記ユーザの権限が前記第１のクライアントへ委譲されたことを示す前記第１の認可情報を発行する第１の発行手段と、
    前記第１のクライアントから送信される前記第１の認可情報を基に、前記第１の利用手段が前記ユーザの権限で前記第２のクライアントのサービスを利用することを認可するか否かを検証する認可手段と、
    前記第１のクライアントから送信される前記第１の認可情報から前記第１のクライアントを特定し、特定された前記第１のクライアントと前記第２のクライアントが関連付いているか否かを確認する確認手段と、
    前記確認手段により関連付いていると確認されたことに応じ、前記第２のクライアントに対し特定の権限が委譲されたことを示す第２の認可情報を発行する第２の発行手段と、
    前記第２クライアントから送信される前記第２の認可情報を基に、前記第２のクライアントが前記ユーザの権限で前記サービス提供装置のサービスを利用することを認可するか否かを検証する第２の認可手段と、を有する
    ことを特徴とする認可サーバ。
11. コンピュータを請求項１０に記載の認可サーバが備える各手段として機能させるためのプログラム。

Images