JP5759305B2 - アクセス管理システム、アクセス管理方法、アクセス管理サーバ、連携サーバ、およびプログラム - Google Patents

Description

本発明は、オンラインプリントサービスシステムにおける、ユーザアカウントを効率的に管理するためのアクセス管理システム、アクセス管理方法、アクセス管理サーバ、連携サーバ、およびプログラムに関する。

近年、クラウドコンピューティングあるいはクラウドというキーワードがＩＴ業界を中心に爆発的に広がっている。従来のコンピュータハードウェアとソフトウェアを購入・利用するモデルから、インターネット上のサービスを購入・利用するモデルへのシフトが加速している。

このようなサービスモデルとして例えば、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）があり、サービス提供者がインターネット経由でソフトウェアを提供し、サービス利用者は主にブラウザを使用して目的のソフトウェアを利用する。サービス提供者は、インターネット上にソフトウェアを提供するためのＷｅｂサイトを構築すればよく、ソフトウェアを配布する必要がない。サービス利用者の側では、専用のソフトウェアを自分のコンピュータにインストールする必要がなく、一般的にはブラウザおよびそのプラグインのみで目的のソフトウェアを利用可能である。

クラウドで提供されるサービスを利用するためには、利用者のユーザアカウントを登録するのが一般的である。利用者ごとに、ユーザアカウントを使用してサービスにログインし、サービスを利用する。ユーザアカウントの登録・無効化・削除などの管理は、管理者が手動で行うと大変手間がかかる。特にユーザアカウントの削除は、使用されていないユーザアカウントの不正使用を防止するなどの理由から、重要な管理作業である。

特許文献１によれば、ユーザＩＤの状態として、「通常」「削除」に加え、「予定削除」という新しい状態を設けることを提案している。予定削除状態にセットされたユーザＩＤは、一時的に使用不可となり、有効期限が経過した時点で物理的に削除される。この予定削除状態の導入により、物理的に削除されるまでの猶予期間を与えることができ、必要に応じてユーザＩＤを再度有効化することが可能である。また、将来、再度ユーザＩＤを再利用する可能性がある場合、適切な有効期限を設定して予定削除状態にセットすれば、ユーザＩＤを再度作成し直すことなく、再度有効化可能となる。これにより、ユーザＩＤの削除という管理作業に柔軟性を与え、管理者の余計な手間を減らす効果を提供する。

特開２０１１−１８１５６号公報

しかしながら、特許文献１の先行技術では、同じユーザＩＤを再利用する場合、以下の２つの課題がある。１つ目は、有効期限を経過してしまった場合は、ユーザＩＤの新規作成し直しが必要となる。この場合、管理者あるいはユーザ本人に新規作成作業の手間が発生してしまう。２つ目は、「予定削除」状態においては、再度有効化して「通常」状態へ戻すことができるようにするために、ユーザＩＤおよびその属性値などのデータを保持したままとなるので、データ量を節約できない。

上記の課題を解決するため、本発明のシステムは以下のような構成を有する。すなわち、ユーザアカウントおよび当該ユーザアカウントに対応するトークンを管理するアクセス管理サーバと、複数のサービス間の処理を連携させる連携サーバとを含むアクセス管理システムであって、前記アクセス管理サーバは、前記連携サーバの要求に従って、管理しているユーザアカウントに対応するトークンを発行する発行手段と、管理しているユーザアカウントのうち、予め定義された削除に関する条件を満たすユーザアカウントを削除するアカウント削除手段と、前記ユーザアカウントに対応して発行されたトークンのうち、期限切れのトークンを削除するトークン削除手段とを有し、前記連携サーバは、別のサーバから前記アクセス管理サーバに管理されたユーザアカウントに対応するトークンの取得を要求された際に、当該ユーザアカウントが前記アカウント削除手段にて削除されていない場合、前記ユーザアカウントに対応する発行済のトークンを取得し、当該ユーザアカウントが前記アカウント削除手段にてすでに削除されていた場合、当該ユーザアカウントを前記アクセス管理サーバに再び登録させ、再び登録させたユーザアカウントに対応して発行されたトークンを取得する取得手段と、前記取得手段にて取得された発行済のトークンが期限切れであった場合、トークンの再発行を前記発行手段に要求する要求手段とを有し、前記要求手段は、前記取得手段にて再び登録させたユーザアカウントに対応するトークンが、前記トークン削除手段にて削除されていた場合、当該再び登録したユーザアカウントに対応するトークンの再発行を前記発行手段に要求する。

本発明により、使用されていないユーザアカウントを定期的に自動削除し、その後自動削除されたユーザアカウントから再度利用要求があった場合は、自動的にユーザアカウントを再作成する。これにより、ユーザアカウント管理用のデータサイズを節約しながらも、同じユーザＩＤが再利用可能となる。

オンラインサービス構成図。 ネットワーク構成図。 コンピュータ構成図。 アクセス管理サービス構成図。 連携サービス構成図。 ＩＤ管理テーブルの例を示す図。 ユーザテーブルおよびユーザロールテーブルの例を示す図。 トークンテーブルの例を示す図。 ログテーブルの例を示す図。 第１の利用方法に係るシーケンス図。 第２の利用方法に係るシーケンス図。 テナントテーブルの例を示す図。 ユーザアカウントの削除処理に係るフローチャート。 トークンの削除処理に係るフローチャート。 ユーザアカウントの作成およびトークンの発行処理に係るフローチャート。 ユーザアカウントの作成およびトークンの発行処理に係るフローチャート。 ログイン処理に係るフローチャート。

［課題の説明］
図１を用いて本発明が解決しようとする特有の課題をより詳細に説明する。インターネット上では、様々なサービス提供者が様々なサービスを提供している。単一のサービス提供者が運営している単体のサービスもあれば、複数のサービスを組み合わせて、１つのワークフローを実現するという手法も存在する。後者は、マッシュアップなどと呼ばれ、表向きはあたかも１つのＷｅｂサイトあるいはＷｅｂサービスとして見えるが、実際にはバックエンドで、他のサービスと連携・連動して、必要な機能を組み合わせてワークフローを実現する。

例えば、写真共有のＷｅｂサイトを例にとって述べる。Ｗｅｂサイトを制御するＨＴＴＰサーバやアプリケーションサーバのホスティングを提供するサービス提供者と、写真という大量の画像ファイルを格納するオンラインストレージを提供するサービス提供者は別々のものを組み合わせることなどができる。なお、ここで言うサービスとは、Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどが提供する機能群のことである。Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどは、サーバコンピュータで実行されるソフトウェアである。

図１に示すように、インターネット上にオンラインサービスＡ１０１が存在する。サーバ１３１は、オンラインサービスＡ１０１をホスティングする単一のサーバまたはサーバ群である。オンラインサービスＡ１０１は、アクセス管理サービス１０２、印刷サービス１０３、ログサービス１０４を備える。アクセス管理サービス１０２はユーザアカウントを収容するためのユーザアカウント・データベース１０５を備える。

クライアントＡ１０６は、オンラインサービスＡ１０１にＷｅｂアクセスするブラウザなどある。例えば、文書ファイルを入稿・印刷したい場合、まずユーザはクライアントＡ１０６を介して、オンラインサービスＡ１０１にログインする。このとき、ユーザアカウントやパスワードが入力される。アクセス管理サービス１０２は、入力された情報に基づいて、ユーザアカウント・データベース１０５から該当ユーザの存在およびパスワードの真偽を確認し、ユーザを認証する。

次に、クライアントＡ１０６は、文書ファイルを印刷サービス１０３に入稿する。印刷サービス１０３は、入稿された文書ファイルをプリンタＡ１０７で出力可能な形式に変換し、プリンタＡ１０７は変換済みの印刷データを受信する。ユーザは、プリンタＡ１０７からオンラインサービスＡ１０１にログインすると、待機中の自身の印刷データからプリンタＡ１０７に印刷物を出力する。ログサービス１０４は、ユーザが行った入稿・印刷などの操作を記録する。以上が、オンラインサービスＡに対する第１の利用方法である。

オンラインサービスＡ１０１に対する第２の利用方法として、オンラインサービスＢ１２１がオンラインサービスＡ１０１の外部に存在し、オンラインサービスＡ１０１と連携して１つのワークフローを提供する。サーバ１３２は、オンラインサービスＢ１２１をホスティングする単一のサーバまたはサーバ群である。例えば、クライアントＢ１２２がオンラインサービスＢ１２１に文書ファイルを入稿すると、オンラインサービスＢ１２１がオンラインサービスＡ１０１に文書ファイルの印刷データへの変換を要求する。印刷サービス１０３は、文書ファイルから印刷データへ変換し、プリンタＢ１２３は印刷データを印刷サービス１０３から受信して、印刷物を出力する。

上記、第１の利用方法において、クライアントＡ１０６やプリンタＡ１０７の利用者がビジネスユーザのような、有料ライセンスモデルであるとする。この場合、ユーザ数が増加すると、ライセンス収入が増加する。増加した収入によって、コンピューティングリソースが増強できるので、さらに追加のユーザ数を収容することができるようになる。逆に、ユーザ数が減少する場合は、ユーザが解約をするので、ユーザアカウントを削除することができる。ユーザアカウントが削除されれば、空きコンピューティングリソースが再利用可能となり、その空きコンピューティングリソースに新たな他のユーザを収容することができる。

一方、上記、第２の利用方法において、コンシューマユーザのような、無料のユーザアカウントをコンピューティングリソースに収容することを想定する。オンラインサービスＢ１２１のユーザが、オンラインサービスＡ１０１を利用するためには、やはりオンラインサービスＡ１０１から発行されたユーザアカウントを用いて認証を受ける必要がある。これは、ログサービス１０４がユーザＩＤをキーとして、ユーザの操作を記録するためである。

ここで問題となるのは、コンシューマユーザの利用パターンとして、最初の数回だけ利用して、後はほとんど利用がない、といったいわゆるワンショット利用のケースが大変多いことである。もう１つの問題は、無料サービスの場合、例え解約や登録解除という処理を用意しておいたとしても、無料であるがゆえに、使用しなくなったユーザが自らこれらの解約・登録解除といった処理を行わないことが多く生じる。そのため、使用されなくなったユーザアカウントを削除するタイミングが実質として無いため、大量の無料ユーザアカウントがコンピューティングリソースであるユーザアカウント・データベース１０５に登録されてしまう。これにより、コンシューマユーザのような無料のユーザアカウントが不要となっていたとしても削除されないままとなり、ユーザアカウント・データベース１０５が肥大化して性能を圧迫する、あるいはデータ管理コストが増大する、という課題が発生する。

＜実施形態＞
［システム構成］
以下、本発明を実施するための最良の形態について図面を用いて説明する。図２は、各種オンラインサービスが存在する、本願発明に係るアクセス管理システムを構成するネットワークの構成を示している。ネットワーク２００は、インターネットなどのパブリックなネットワークである。ネットワーク２０１は、イントラネットなどのプライベートなネットワークである。文書管理サービス２０２は、オンラインでユーザの文書ファイルを保管する。プリンタ管理サービス２０３は、インターネットに接続されたプリンタを管理する。アクセス管理サービス２０４は、ユーザの認証・認可を管理する。連携サービス２０５は、オンラインサービス間の連携を制御する。印刷サービス２０６は、文書ファイルをプリンタが印刷できるデータに変換する。ログサービス２０７は、印刷サービス２０６をいつ、誰が、何を行ったかのユーザ操作の履歴（ログ）を記録する。

クライアント２１１および２２１は、クライアントコンピュータやモバイル端末など、オンラインサービスを利用する際に使用されるクライアントである。プリンタ２１２および２２２は印刷データを受信して、印刷する。ただし、本実施形態において、クライアント２２１およびプリンタ２２２は、アクセス管理サービス２０４および印刷サービス２０６を直接利用する対象であり、外部サービスである文書管理サービス２０２、プリンタ管理サービス２０３とは接続しない。

一方、クライアント２１１およびプリンタ２１２は、文書管理サービス２０２およびプリンタ管理サービス２０３を直接利用する対象であり、アクセス管理サービス２０４や印刷サービス２０６を、連携サービス２０５を介して間接的に利用する。サーバ２３１〜２３６は、各サービスをホスティングするサーバである。

ここで、文書管理サービス２０２（文書管理サーバ）とプリンタ管理サービス２０３（プリンタ管理サーバ）が、図１におけるオンラインサービスＢ１２１に属するものとする。同様に、連携サービス２０５（連携サーバ）、アクセス管理サービス２０４（アクセス管理サーバ）、印刷サービス２０６（印刷サーバ）、およびログサービス２０７（ログサーバ）が図１におけるオンラインサービスＡ１０１に属するものとする。

なお、本実施形態において、各種サービスはそれぞれ異なるサーバにて提供される構成としているが、この構成に限定するものではない。例えば、１台の物理的なサーバによって複数のサービスを提供するように構成しても構わないし、１のサービスを複数台のサーバにて提供するように構成しても構わない。

図３は、前述の各種サービスを構成するＷｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどのソフトウェアを実行するサーバコンピュータ（サーバ２３１〜２３６）の情報処理機能の論理構成を示している。ユーザインタフェース３０１は、ディスプレイ、キーボード、マウスなどによる、情報の入出力を行う。これらのハードウェアを備えないコンピュータは、リモートデスクトップなどにより、他のコンピュータから接続・操作することも可能である。ネットワークインタフェース３０２は、ＬＡＮなどのネットワークに接続して、他のコンピュータやネットワーク機器との通信を行う。

ＲＯＭ３０４は、組込済みプログラムおよびデータが記録する。ＲＡＭ３０５は一時メモリ領域である。二次記憶装置３０６は、ＨＤＤに代表されるような二次記憶装置である。ＣＰＵ３０３は、ＲＯＭ３０４、ＲＡＭ３０５、二次記憶装置３０６などから読み込んだプログラムを実行し、各種サービスを実現する。各部は入出力インタフェース３０７を介して接続されている。なお、この構成に加えて、更なる部位を備えても構わない。また、クライアント２１１、２２１やプリンタ２１２、２２２についても同様の構成を有していても構わない。本実施形態では、上述した構成により、各サーバが以下に示す各シーケンスの処理を実行することとなる。

図４は、アクセス管理サービス２０４の内部構造を示している。アクセス管理リクエスト処理部４０１は、インターネット２００またはイントラネット２０１を経由して、クライアント２２１やプリンタ２２２および他サービスからのリクエストを受信する。認証データ管理部４０３は、ユーザアカウントのデータを管理する。認可トークン管理部４０４は、認可トークンのデータを管理する。アクセス制御部４０２は、認証データ管理部４０３および認可トークン管理部４０４から取得するデータに基づき、認証・認可リクエストに対し応答データを生成し、アクセス管理リクエスト処理部４０１に応答データを返す。アクセス管理リクエスト処理部４０１は、応答データを他サービスに返信する。

図５は、連携サービス２０５の内部構造を示している。連携リクエスト処理部５０１は、インターネット２００を経由して、他サービスから文書ファイルのデータ変換のリクエストを受信する。サービス制御部５０２は、連携リクエスト処理部５０１からのリクエストを受けて、イントラネット２０１経由でアクセス管理サービス２０４および印刷サービス２０６に対し、必要な処理を行い、応答データを返す。連携リクエスト処理部５０１は応答データを呼び出し元に返す。

ここで、本明細書において用いる用語について説明する。本明細書において、「認証トークン」とは、ユーザＩＤおよびパスワード等を用いてログインを行った際に、ログイン成功すると払い出されるトークンを意味する。この認証トークンを同一のログインセッション間で使いまわすことにより、そのユーザがアクセス可能な機能すべてを使用可能となる。また、この認証トークンのライフサイクルは、ログインセッションであり、例えば、ログアウトやセッションタイムアウトなどにより、認証トークンは無効となる。

これに対し、「認可トークン」とは、正しいユーザＩＤ／パスワードを伴った認可トークン取得要求に応答して払い出されるトークンである。つまり、この認可トークンを使用したアクセスでは、ある特定機能の実行やある特定ＵＲＬへのアクセスを許諾する際に用いられ、その許諾された権限に限定される。例えば、この認可トークンにより、印刷サービス２０６の機能やデータ（ＵＲＬ）へのアクセスが許可される。この認可トークンは、ユーザ本人の代理で外部プログラムなどに代理実行などを行わせる際に用いられる。つまり、プログラム等に認可トークンを授与することにより、ユーザが有する権限を付与し、（例えば、Ｉｎｖｏｋｅｒとして）代理にて処理を実行させることが可能となる。認可トークンのライフサイクルは、設定された有効期限内であり、その有効期限内であれば、何度でも使いまわせる。なお、有効期限の具体的な値は、図８を用いて説明する。

［データ構造］
以下、本実施形態にて用いるデータ構造の説明を行う。なお、各テーブルにて示されるカラム名が同じもの（例えば、ユーザＩＤ）は、各テーブル間にて共通のものを示しているものとする。なお、以下に示すデータ構造は一例であり、他の構成要素を有していてもよい。また、データの値がとりうる構成（例えば、桁数や英数字による構成）は以下に示すものに限定するものではなく、異なる構成としても構わない。

図６は、プリンタ管理サービス２０３が保持する、ＩＤ管理のためのデータ構造をテーブル形式で表したＩＤ管理テーブル６００を示している。プリンタＩＤ６０１は、プリンタ２１２のプリンタＩＤを格納するカラムである。ユーザＩＤ６０２は、ユーザＩＤを格納するカラムである。パスワード６０３は、パスワードを格納するカラムである。認可トークン６０４は、認可トークンを格納するカラムである。ユーザＩＤ６０２、パスワード６０３、および認可トークン６０４は、いずれもアクセス管理サービス２０４から発行されるものを保持するカラムである。

図７は、認証データ管理部４０３で管理するデータをテーブル形式で表している。図７（Ａ）は、ユーザテーブル７００を示している。ユーザテーブル７００は、ユーザＩＤ７０１、パスワード７０２、テナントＩＤ７０３、最終ログイン日時７０４を構成要素として備える。ここでのテナントＩＤとは、マルチテナントを実現するための識別子である。例えば、あるオンラインサービスを単一システムで動作させているとする。このオンラインサービスを複数の顧客企業に販売する場合、他の顧客のデータへアクセスできないようにする、顧客ごとにサービス利用料金を計算する、などのマルチテナント機能が必要となる。これらのマルチテナント機能を実現するための識別子として、テナントＩＤ７０３がユーザＩＤ７０１ごとに必ず付与されることにより、テナントごとにユーザの分離、データの分離を実現する。クラウド化が進むことにより、１つのメモリに異なるドメインに所属するテナントのデータが管理されることになるので、マルチテナントという考え方はクラウドコンピューティングにおいて非常に重要な考え方である。

図７（Ｂ）は、ユーザロールテーブル７１０を示している。ユーザロールテーブル７１０は、ユーザＩＤ７１１およびロール７１２を構成要素として備える。ロールとは、所属テナントにおけるユーザの役割を定義するものである。例えば、ロール７１２の設定値として、管理者（Ａｄｍｉｎ）、インボーカ（Ｉｎｖｏｋｅｒ）、一般ユーザ（Ｕｓｅｒ）などが存在する。管理者ロールを持つユーザは、すべての機能・データにアクセス可能である。ロールにおけるインボーカとは、他サービスからのリクエスト呼び出しに使われる無人アカウント用のロールである。インボーカは、一部のリクエスト処理時のみに、限定的な機能・データにアクセス可能である。一般ユーザは、いわゆるエンドユーザに相当するロールである。エンドユーザが印刷サービスを利用するのに使用される。

図８は、認可トークン管理部４０４が管理するデータをテーブル形式で表したトークンテーブル８００を示している。トークンテーブル８００は、トークンＩＤ８０１、有効期限８０２、発行日時８０３、ユーザＩＤ８０４、テナントＩＤ８０５、およびクライアントＩＤを構成要素として備える。有効期限８０２は、認可トークンの有効期限を秒数で表した値である。発行日時８０３は、認可トークンが発行された発行日時である。ユーザＩＤ８０４は、この認可トークンがどのユーザに対して発行されたのかを示すユーザＩＤである。テナントＩＤ８０５は、ユーザＩＤ８０４が所属するテナントＩＤである。クライアントＩＤ８０６は、この認可トークンの発行要求元であるインボーカのユーザＩＤが記録されるクライアントＩＤである。

なお、本実施形態において、トークンテーブル８００は、認証トークンおよび認可トークンいずれも登録されているものとして説明する。しかし、それぞれ別のテーブルにて管理するようにしても構わない。その場合には、例えば、認証トークンには有効期間は設定されない。また、認可トークンにおいては、いずれの機能を利用可能か、どのデータにアクセス可能なといった情報が対応付けられても構わない。例えば、印刷サービス２０６が提供する印刷データを参照する際のＵＲＬなどが該当する。その場合には、トークンテーブル８００において、更なる情報を管理するように構成することが想定される。

図９は、ログサービス２０７が管理するデータをテーブル形式で表したログテーブル９００を示している。ログテーブル９００は、タイムスタンプ９０１、ユーザＩＤ９０２、テナントＩＤ９０３、およびアクションＩＤ９０４を構成要素として備える。タイムスタンプ９０１は、操作が行われた日時を記録するタイムスタンプである。ユーザＩＤ９０２は、操作を行ったユーザのユーザＩＤである。テナントＩＤ９０３は、操作を行ったユーザの所属するテナントのテナントＩＤである。アクションＩＤ９０４は、操作の種別を表すアクションＩＤである。

［第１の利用方法］
図１０を用いて、印刷サービス２０６の第１の利用方法を示す。これは、図１にて述べたオンラインサービスＡ１０１にクライアントＡ１０６が直接アクセスし、利用する方法に対応する。第１の利用方法では、クライアント２２１とプリンタ２２２は、アクセス管理サービス２０４および印刷サービス２０６のみを直接利用する。

まず、印刷サービス２０６の利用者は、アクセス管理サービス２０４に登録したユーザアカウントを使用して、クライアント２２１を用いてアクセス管理サービスにログインする（Ｓ１００１）。アクセス管理サービス２０４は、ユーザテーブル７００と照合して、ログイン成功・失敗を判定し、ログイン成功の場合、認証トークンを発行する（Ｓ１００２）。アクセス管理サービス２０４は、発行した認証トークンの情報を図８に示すようにトークンテーブル８００に記録する。なお、認証が失敗した場合は、アクセス管理サービス２０４は、その旨をユーザに対して通知する。

次に、クライアント２２１は、印刷サービス２０６に文書ファイルをアップロードする（Ｓ１００３）。この際、認証トークンも一緒に渡される。印刷サービス２０６は、アクセス管理サービス２０４に問い合わせ、受信した認証トークンの有効性を検証する（Ｓ１００４）。アクセス管理サービス２０４は、トークンテーブル８００と照合し、認証トークンが有効であるか判定する。認証トークンが有効である旨を受信した場合、印刷サービス２０６は、アップロードされた文書ファイルから、プリンタで印刷可能なデータを生成し、一旦保管する（Ｓ１００５）。なお、認証トークンが有効ではない旨を受信した場合、印刷サービス２０６は、エラー終了する。印刷サービス２０６は、印刷データ生成・保管の後、印刷データを生成したという操作ログを、ログサービスに記録する（Ｓ１００６）。

次に、利用者はプリンタ２２２を用いて、アクセス管理サービス２０４にログインする（Ｓ１００７）。アクセス管理サービス２０４は、ユーザテーブル７００と照合して、ログイン成功・失敗を判定し、ログイン成功の場合、認証トークンを発行する（Ｓ１００８）。プリンタ２２２は、ログインしたユーザの保管済み印刷データの受信を印刷サービス２０６に要求する（Ｓ１００９）。この際、認証トークンも一緒に渡される。印刷サービス２０６は、アクセス管理サービス２０４に問い合わせ、認証トークンの有効性を検証する（Ｓ１０１０）。認証トークンが有効な場合、印刷サービス２０６は印刷データの受信を許可し、プリンタ２２２は、印刷サービス２０６から印刷データを受信する（Ｓ１０１１）。印刷サービス２０６は、印刷データの送信を完了すると、それをログサービスに記録する（Ｓ１０１２）。プリンタ２２２は、印刷データを用紙に出力する（Ｓ１０１３）。以上が、印刷サービス２０６の第１の利用方法としての流れの一例である。

［第２の利用方法］
図１１を用いて、印刷サービス２０６の第２の利用方法を示す。これは、図１にて述べたオンラインサービスＢ１２１を介して、オンラインサービスＡ１０１を利用する方法に対応する。第２の利用方法では、クライアント２１１とプリンタ２１２は、文書管理サービス２０２およびプリンタ管理サービス２０３を利用している。しかし、文書管理サービス２０２およびプリンタ管理サービス２０３が、印刷データ生成の機能を持たないため、印刷サービス２０６を利用する。利用者は、文書管理サービス２０２のユーザ認証を使用するが、一方で印刷サービス２０６を利用するためには、アクセス管理サービス２０４にもユーザアカウントを登録して、印刷サービス２０６を利用する必要がある。つまり、文書管理サービス２０２におけるユーザ認証と、印刷サービス２０６におけるユーザ認証は異なる。

まず、利用者はクライアント２１１を用いて、文書管理サービス２０２にログインする（Ｓ１１０１）。利用者はクライアント２１１を用いて、文書管理サービス２０２に文書ファイルをアップロードする（Ｓ１１０２）。利用者は、クライアント２１１から文書管理サービス２０２に対し、文書ファイルの印刷指示を出す（Ｓ１１０３）。文書管理サービス２０２は、プリンタ管理サービス２０３に印刷要求を送信する（Ｓ１１０４）。このとき、印刷対象である文書データが格納された位置情報（文書ファイルＵＲＬ）および文書ファイルを取得する際に必要となる認可トークンも併せて送信する。なお、ここで送信される認可トークンとは、文書管理サービス側で発行される認可トークンであり、アクセス管理サービス２０４にて発行される認可トークンとは異なる。この文書管理サービス側で発行された認可トークンを用いることにより、連携サービスは文書管理サービス側のサービスの提供（文書データの取得等）を受けることが可能となる。

プリンタ管理サービス２０３は、連携サービス２０５に認可トークン取得要求を送信する（Ｓ１１０５）。連携サービス２０５は、アクセス管理サービス２０４から認可トークン発行を受ける（Ｓ１１０６）。ここで言う認可トークンとは、印刷サービス２０６へのアクセス許可・利用許可を示すトークンＩＤ８０１のことである。

連携サービス２０５およびプリンタ２１２から印刷サービス２０６を利用する際に、認可トークンを使用して、印刷サービス２０６の利用許可を得る。連携サービス２０５は、プリンタ管理サービス２０３に認可トークンを通知する（Ｓ１１０７）。プリンタ管理サービス２０３は、Ｓ１１０４で受け取った印刷対象の文書ファイルＵＲＬを連携サービス２０５に通知する（Ｓ１１０８）。このとき、併せて文書管理サービス２０２から受信した認可トークンも渡される。連携サービス２０５は、通知された文書ファイルＵＲＬから文書ファイルを取得する（Ｓ１１０９）。このとき、文書管理サービス２０２は、Ｓ１１０４にて送信した認可トークンを確認し、この認可トークンが正当なものである場合に、文書ファイルを連携サービスに提供する。

連携サービス２０５は、取得した文書ファイルを印刷サービス２０６に登録する（Ｓ１１１０）。この際に、認可トークンも一緒に渡される。印刷サービス２０６はアクセス管理サービス２０４に問い合わせ、認可トークンの有効性を検証する（Ｓ１１１１）。認可トークンが有効な場合、印刷サービス２０６は、文書ファイルからプリンタで印刷可能な印刷データを生成し、一旦保管する（Ｓ１１１２）。印刷サービス２０６は、印刷データを生成したという操作ログを、ログサービスに記録する（Ｓ１１１３）。

印刷サービス２０６は、Ｓ１１１２にて生成した印刷データが保管されている位置情報（印刷データＵＲＬ）を連携サービス２０５に通知する（Ｓ１１１４）。連携サービス２０５は、印刷データＵＲＬをプリンタ管理サービス２０３に通知する（Ｓ１１１５）。プリンタ管理サービス２０３は、印刷データＵＲＬとＳ１１０７で受信した認可トークンとをプリンタ２１２に通知する（Ｓ１１１６）。プリンタ２１２は、印刷サービス２０６に印刷データ受信要求を送信する（Ｓ１１１７）。この際に認可トークンも渡される。印刷サービス２０６は、アクセス管理サービス２０４に問い合わせ、認可トークンの有効性を検証する（Ｓ１１１８）。認可トークンが有効な場合、印刷サービス２０６は印刷データの受信を許可し、プリンタ２１２は、印刷データＵＲＬに基づいて、印刷サービス２０６から印刷データを受信する（Ｓ１１１９）。印刷サービス２０６は、印刷データの送信を完了すると、それをログサービスに記録する（Ｓ１１２０）。そして、プリンタ２１２は、印刷データを用紙に出力する（Ｓ１１２１）。

［第２の利用方法に対するアカウントの収容方法］
図１２〜図１７を用いて、本実施形態に係る、第２の利用方法で文書管理サービス２０２およびプリンタ管理サービス２０３が利用する大量のユーザアカウントを効率的に収容する方法について説明する。なお、本明細書において、“自動”とは、ユーザからの操作を都度要求せずに、システム側で自発的に処理を行うことを意味する。

図１２は、認証データ管理部４０３にて管理されるテナント情報のデータをテーブル形式で表したテナントテーブル１２００を示す。テナントテーブル１２００は、テナントＩＤ１２０１、ユーザアカウント削除条件１２０２、および設定閾値１２０３を構成要素として備える。ユーザアカウント削除条件１２０２は、テナントごとのユーザアカウント削除条件を示す値である。例えば、値の定義として、０：ユーザアカウントを自動削除しない、１：最終ログイン日時を条件に自動削除する、２：ユーザアカウント総数を条件に自動削除する、などである。なお、削除条件に関しては、上記の条件以外にも、他の条件を設定するようにしても構わない。設定閾値１２０３は、自動削除条件の設定閾値である。認証データ管理部４０３は、プリンタ管理サービス２０３および連携サービス２０５に対し、テナントＩＤを１つ割り当て、管理者ロールを持つユーザアカウント、インボーカロールを持つユーザアカウントを発行する。

図１３は、テナントごとに使用されていないユーザアカウントを自動削除する流れを示したフローチャートである。本処理は、アクセス管理サービス２０４を提供するサーバが備えるＣＰＵが記憶部であるＲＯＭ等に記憶されたプログラムをＲＡＭ等に読み出して実行することにより実現される。

アクセス管理サービス２０４は、テナントテーブル１２００のユーザアカウント削除条件１２０２から使用する削除条件を判定する（Ｓ１３０１）。削除条件が“０”の場合は、アクセス管理サービス２０４は、とのテナントＩＤに対応付けられたユーザアカウントを自動削除しない。削除条件が“１”の場合、アクセス管理サービス２０４は、図７に示すユーザテーブル７００から、テナントＩＤが一致するユーザアカウントのうち、現在日時と最終ログイン日時７０４との差が設定閾値１２０３より大きいレコードを削除する（Ｓ１３０２）。つまり、最終ログイン日時から所定の時間が経過したユーザアカウントを削除の対象とする。ただし、ここでの削除対象は、一般ユーザ（Ｕｓｅｒ）のロールのみを持つユーザアカウントとする。

削除条件が“２”の場合、アクセス管理サービス２０４は、まずユーザテーブル７００から、該当テナントに所属するユーザアカウント総数を取得する（Ｓ１３０３）。なお対象のユーザアカウントは一般ユーザのロールのみを持つユーザアカウントとする。次にアクセス管理サービス２０４は、ユーザアカウント総数と設定閾値の差を計算し、Ｎとする（Ｓ１３０４）。アクセス管理サービス２０４は、Ｎが“０”より大きいかどうかを判定する（Ｓ１３０５）。Ｎが“０”より大きい場合（Ｓ１３０５にてＹＥＳ）、アクセス管理サービス２０４は、対象のユーザアカウントを最終ログイン日時による昇順ソート条件付で、先頭のＮ件をユーザテーブル７００から削除する（Ｓ１３０６）。つまり、予め定義されたアカウント数を超えた場合に、超えた分のユーザアカウントを古い順に削除対象とする。

本処理を例えば１日１回として定期的に実行することで、削除条件が“１”または“２”に設定されているテナントから使用されていないユーザアカウントを古いものから順に自動削除できる。その結果、認証データ管理部４０３の管理対象データサイズが節約できる。なお、本処理を実行するタイミングは、上記のように１日１回の周期に限らず、予め定義された周期にて実行するようにしても構わない。更に、管理者からの指示に起因して開始するようにしても構わない。

図１４は、テナントごとに古いトークンを削除する流れを示したフローチャートである。トークン削除に係る本処理は、アクセス管理サービス２０４を提供するサーバが備えるＣＰＵが記憶部であるＲＯＭ等に記憶されたプログラムをＲＡＭ等に読み出して実行することにより実現される。

アクセス管理サービス２０４は、現在日時と発行日時８０３の差（秒数）が、有効期限８０２より大きい場合、該当トークンは期限切れであるため、トークンテーブル８００からレコードを削除する（Ｓ１４０１）。

本処理を例えば１日１回として定期的に実行することで、使用されない期限切れのトークンを自動的に削除することが可能となる。その結果、認可トークン管理部４０４の管理対象データサイズが節約できる。なお、本処理を実行するタイミングは、上記のように１日１回の周期に限らず、予め定義された周期にて実行するようにしても構わない。また、管理者からの指示に従って開始するようにしても構わない。

図１３および図１４で示した方法により、テナントごとに、使用されていないユーザアカウントの自動削除を適用するか、適用しないかを選択することができる。なお、本実施形態において、前述の第１の利用方法で利用している有料ライセンスを保有するテナントに対しては、ユーザアカウントの自動削除を適用しない。これは、第１の利用方法においては、解約されない限りはライセンス料金が回収できるので、ユーザアカウントデータを保持するコストがまかなえるためである。また、有料ライセンスユーザの場合は、使用されていないユーザアカウントであるとして自動削除してしまうと、万が一同じユーザアカウントを再利用したい場合、有料ライセンスユーザであるのに、ユーザに不便をかけることになる。

一方、前述の第２の利用方法により、無料ユーザアカウントを収容するためのテナントには、ユーザアカウントの自動削除を適用する。これにより、コンシューマユーザのような大量のユーザアカウントを収容する際に、データ総量を抑制して、ユーザアカウントデータ管理コストを低減できる。また、ユーザアカウント・データベース１０５の肥大化を防止して、第１の利用方法で利用しているテナントのユーザへの影響を低減できる。

［第２の利用方法に対するアカウントの再作成方法］
図１５および図１６は、認可トークン取得要求時に、ユーザアカウントが存在しない場合に認可トークンを自動的に作成（再作成）し、発行する流れを示したフローチャートである。

まず、文書管理サービス２０２は、プリンタ管理サービス２０３に印刷要求を送信する（Ｓ１５０１）。プリンタ管理サービス２０３は、受信した印刷要求に従って、連携サービス２０５に認可トークン取得要求を送信する（Ｓ１５０２）。引数として、テナント管理者ユーザＩＤ、テナント管理者パスワード、テナント管理者の認可トークン、一般ユーザＩＤ、一般ユーザパスワード、および一般ユーザ認可トークンが渡される。

ここで、プリンタ管理サービス２０３は、図６に示すようにＩＤ管理テーブル６００に、プリンタＩＤ６０１およびプリンタごとにアクセス管理サービス２０４のユーザＩＤ６０２、パスワード６０３、認可トークン６０４を保持している。すなわち、プリンタ管理サービス２０３は、プリンタが１台ごとに、プリンタ固有の値であるプリンタＩＤ６０１とアクセス管理サービス２０４のユーザＩＤ６０２とのペアを保持する。これにより、図１１に示したＳ１１１５で、連携サービス２０５から印刷データＵＲＬの通知を受けた際に、プリンタ管理サービス２０３は、ユーザＩＤ６０２とペアになっているプリンタＩＤ６０１を特定する。そして、プリンタ管理サービス２０３は、印刷データＵＲＬを適切なプリンタ２１２に転送することができる。

ユーザによる本システムへのアクセスが、初回アクセスである場合には、プリンタ管理サービス２０３は、一意なユーザＩＤ６０２およびランダムなパスワード６０３を生成して、認可トークンを空のまま認可トークン取得要求を呼び出す（Ｓ１５０２）。連携サービス２０５は、プリンタ管理サービス２０３から渡された認可トークンを判定する（Ｓ１５０３）。認可トークンが空の場合、すなわち未発行の場合（Ｓ１５０３にてＹＥＳ）、Ｓ１５０４に進む。認可トークンが発行済みの場合（Ｓ１５０３にてＮＯ）、Ｓ１５０７に進む。認可トークンが未発行の場合、連携サービス２０５は、まず管理者ユーザＩＤでアクセス管理サービス２０４にログインする（Ｓ１５０４）。Ｓ１５０４はサブルーチンであり、図１７にそのサブルーチンを示す。

連携サービス２０５からアクセス管理サービス２０４に対し、ユーザログインが呼び出される（Ｓ１７０１）。引数として、テナント管理者ユーザＩＤ、テナント管理者パスワードが渡される。ログインに成功すると、その応答としてテナント管理者の認証トークンが返される（Ｓ１７０２）。なお、ログインに失敗した場合には、エラー終了となる。

ユーザログイン処理の後、連携サービス２０５は、アクセス管理サービス２０４に対して、一般ユーザ作成の要求を送信する（Ｓ１５０５）。このとき、引数として、テナント管理者の認証トークン、およびユーザ情報が渡される。ユーザ情報には、ユーザＩＤ６０２、およびパスワード６０３が含まれる。アクセス管理サービス２０４において一般ユーザの作成に成功すると、アクセス管理サービス２０４から連携サービス２０５に作成が成功した旨の応答が返される（Ｓ１５０６）。この後、図１６の記号Ａに続く。

一方、認可トークンが発行済みの場合（Ｓ１５０３にてＮＯ）、連携サービス２０５はアクセス管理サービス２０４に、認可トークン情報取得要求を送信する（Ｓ１５０７）。このとき、引数として、インボーカＩＤ、インボーカパスワード、一般ユーザＩＤ、一般ユーザパスワード、および一般ユーザの認可トークンが渡される。まず、アクセス管理サービス２０４は、ユーザテーブル７００およびユーザロールテーブル７１０に照会して、連携サービス２０５から受信したインボーカＩＤとインボーカパスワードが正しいかどうかを検証する。これは、アクセス管理サービス２０４の呼び出し元である連携サービス２０５が、正しいインボーカＩＤとインボーカパスワードを使用しているかを検証するためである。

検証に成功した場合、アクセス管理サービス２０４は、渡された一般ユーザＩＤと一般ユーザパスワードを用いて、インボーカによる代理認証を試みる。アクセス管理サービス２０４は、ユーザテーブル７００およびユーザロールテーブル７１０に照会して、一般ユーザＩＤが存在し、一般ユーザパスワードが正しいかどうかを検証する。一般ユーザＩＤと一般ユーザパスワードが正しいと判定された場合、代理認証は成功となる。この場合、アクセス管理サービス２０４は、要求された一般ユーザに対する認可トークン、発行日時、有効期限をトークンテーブル８００から取得して連携サービス２０５に返す（Ｓ１５０８）。代理認証が失敗した場合は、アクセス管理サービス２０４は、その旨を連携サービス２０５へ返す。

連携サービス２０５は、Ｓ１５０８の戻りが一般ユーザの代理認証エラーなどの例外でないかを判定する（Ｓ１５０９）。一般ユーザの代理認証のエラーと判定された場合（Ｓ１５０９にてＹＥＳ）、Ｓ１５１０に進む。エラーではない場合（Ｓ１５０９にてＮＯ）、図１６の記号Ｂに進む。一般ユーザの代理認証のエラーと判定された場合、連携サービス２０５は、管理者ユーザＩＤでアクセス管理サービス２０４にログインする（Ｓ１５１０）。Ｓ１５１０はＳ１５０４と同様、図１７に示すサブルーチンである。ユーザログイン処理の後、連携サービス２０５は、アクセス管理サービス２０４にユーザ情報取得要求を送信する（Ｓ１５１１）。このとき、引数として、テナント管理者の認証トークン、および一般ユーザＩＤが渡される。アクセス管理サービス２０４は、ユーザテーブル７００から要求されたユーザＩＤを検索してユーザ情報を連携サービス２０５に返す（Ｓ１５１２）。このとき、削除されたユーザアカウントと同一のユーザアカウント（ユーザＩＤ）にて、再作成されることとなる。アクセス管理サービス２０４は、対象ユーザが存在しないなど、例外が発生した場合には、その旨を連携サービス２０５へ返す。

連携サービス２０５は、Ｓ１５１２の戻りが、対象ユーザが存在しないという例外でないかを判定する（Ｓ１５１３）。対象ユーザが存在しないと判定された場合（Ｓ１５１３にてＹＥＳ）、Ｓ１５０５に進み、連携サービス２０５は、以前は存在したが自動削除されてしまったユーザアカウントを再作成する。それ以外の場合（Ｓ１５１３にてＮＯ）、Ｓ１５１３で対象ユーザは存在すると判定されているが、すでにＳ１５０９で該当ユーザの認証エラーとなっている。そのため、連携サービス２０５は、エラー処理として認可トークン取得要求の応答として、プリンタ管理サービス２０３へ“Ｆａｉｌｕｒｅ”を戻す（Ｓ１５１４）。

図１６に移り、記号Ｂの続きから説明する。連携サービス２０５は、Ｓ１５０８で戻された認可トークンがすでにトークンテーブル８００から削除済みか、または期限切れでないかを判定する（Ｓ１６０１）。削除済み、あるいは期限切れではない場合、すなわち認可トークンが有効であると判定された場合（Ｓ１６０１にてＮＯ）、Ｓ１６０４へ進む。削除済みあるいは期限切れであると判定された場合（Ｓ１６０１にてＹＥＳ）、Ｓ１６０２へ進む。

記号Ａから進む場合、新規作成したユーザアカウントに対し、連携サービス２０５はアクセス管理サービス２０４に認可トークン取得を要求する（Ｓ１６０２）。Ｓ１６０１から進む場合、削除済みあるいは期限切れのため、連携サービス２０５は、アクセス管理サービス２０４に認可トークンの再発行を要求する（Ｓ１６０２）。このとき、引数として、インボーカＩＤ、インボーカパスワード、一般ユーザＩＤ、一般ユーザパスワード、および有効期限を渡す。

アクセス管理サービス２０４は、認可トークンを発行または再発行して、トークンテーブル８００に記録し、応答としてトークンＩＤ８０１、発行日時８０３、および有効期限８０２を連携サービス２０５へ戻す（Ｓ１６０３）。最後に、連携サービス２０５はプリンタ管理サービス２０３に、認可トークン取得要求の応答を返す（Ｓ１６０４）。この際、発行また再発行された一般ユーザの認可トークンを戻す。プリンタ管理サービス２０３は、発行された認可トークンをＩＤ管理テーブル６００の認可トークン６０４のカラムに格納する。以降、プリンタ管理サービス２０３は、図１１に示した後続の処理を継続する。

図１３、１４において、使用されていないユーザアカウントの自動削除、およびトークンの自動削除の方法を示した。また、図１５〜１７に、自動削除されたユーザアカウントの要求時の自動再作成および認可トークンの自動発行の方法を示した。これらの両者を組み合わせることにより、上述したような第２の利用方法において、大量の無料ユーザアカウントが登録される場合に、ユーザアカウント総数を抑えて、アクセス管理サービス２０４の管理データサイズを節約できる。

また、第２の利用方法を利用する外部サービスの大量のユーザアカウントを１つのテナントに収容し、そのデータサイズを節約できるので、第１の利用方法で利用しているテナントへの影響を少なくすることができる。これらにより、第２の利用方法で大量のユーザアカウントを登録する際の、アクセス管理サービスのユーザアカウント・データベースの肥大化、運用コストの増大、といった課題を解決する効果が得られる。また、ユーザアカウントが自動削除後でも同一のユーザＩＤで再作成されるため、ユーザＩＤをキーとして記録されているログサービス２０７のログが、過去に遡って一貫性が保たれるという効果も得られる。

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

Claims (11)

1. ユーザアカウントおよび当該ユーザアカウントに対応するトークンを管理するアクセス管理サーバと、複数のサービス間の処理を連携させる連携サーバとを含むアクセス管理システムであって、
   前記アクセス管理サーバは、
   前記連携サーバの要求に従って、管理しているユーザアカウントに対応するトークンを発行する発行手段と、
   管理しているユーザアカウントのうち、予め定義された削除に関する条件を満たすユーザアカウントを削除するアカウント削除手段と、
   前記ユーザアカウントに対応して発行されたトークンのうち、期限切れのトークンを削除するトークン削除手段と
   を有し、
   前記連携サーバは、
   別のサーバから前記アクセス管理サーバに管理されたユーザアカウントに対応するトークンの取得を要求された際に、当該ユーザアカウントが前記アカウント削除手段にて削除されていない場合、前記ユーザアカウントに対応する発行済のトークンを取得し、当該ユーザアカウントが前記アカウント削除手段にてすでに削除されていた場合、当該ユーザアカウントを前記アクセス管理サーバに再び登録させ、再び登録させたユーザアカウントに対応して発行されたトークンを取得する取得手段と、
   前記取得手段にて取得された発行済のトークンが期限切れであった場合、トークンの再発行を前記発行手段に要求する要求手段と
   を有し、
   前記要求手段は、前記取得手段にて再び登録させたユーザアカウントに対応するトークンが、前記トークン削除手段にてすでに削除されていた場合、当該再び登録したユーザアカウントに対応するトークンの再発行を前記発行手段に要求することを特徴とするアクセス管理システム。
2. 前記アクセス管理サーバは、
   前記ユーザアカウントに当該ユーザアカウントが属するテナント情報を対応づけて管理し、当該テナント情報ごとに前記アカウント削除手段にて削除する条件を設定し、
   前記アクセス管理サーバが管理するユーザアカウントのうち、前記別のサーバが管理しているユーザアカウントと、前記別のサーバが管理していないユーザアカウントとは異なるテナント情報を対応づけて管理し、当該別のサーバが管理していないユーザアカウントは削除しないように制御することを特徴とする請求項１に記載のアクセス管理システム。
3. 前記予め定義された削除に関する条件として、
   前記アカウント削除手段による削除を実行しない、
   最後にログインしてから所定の期間が経過したユーザアカウントを削除する、
   予め定義されたアカウント数を超えた場合にログイン日時が古いものから削除する
   のうちの少なくとも１つが設定可能であり、
   前記アカウント削除手段は、当該設定可能な少なくとも１つの条件に対応して判定を行うことを特徴とする請求項１または２に記載のアクセス管理システム。
4. 前記取得手段は、前記アカウント削除手段にて削除されたユーザアカウントと同一のユーザアカウントを再び登録させ、当該ユーザアカウントにて行われた処理のログを対応付けて保持させることを特徴とする請求項１乃至３のいずれか一項に記載のアクセス管理システム。
5. 前記アカウント削除手段にて削除するタイミングは、所定の周期ごと、もしくは管理者の指示に起因して行われることを特徴とする請求項１乃至４のいずれか一項に記載のアクセス管理システム。
6. 前記連携サーバは、前記別のサーバが発行したトークンを用いて、前記別のサーバが提供するサービスを受けることを特徴とする請求項１乃至５のいずれか一項に記載のアクセス管理システム。
7. ユーザアカウントおよび当該ユーザアカウントに対応するトークンを管理するアクセス管理サーバと、複数のサービス間の処理を連携させる連携サーバとを含むアクセス管理システムにおけるアクセス管理サーバであって、
   前記連携サーバの要求に従って、管理しているユーザアカウントに対応するトークンを発行する発行手段と、
   管理しているユーザアカウントのうち、予め定義された削除に関する条件を満たすユーザアカウントを削除するアカウント削除手段と、
   前記ユーザアカウントに対応して発行されたトークンのうち、期限切れのトークンを削除するトークン削除手段と
   を有し、
   前記発行手段は、前記連携サーバの要求に従って、発行済みのトークンのうちの期限切れのトークンの再発行を行い、
   前記発行手段は、前記アカウント削除手段により削除されたユーザアカウントが前記連携サーバから要求に従って再び登録された際に、当該ユーザアカウントに対応するトークンが前記トークン削除手段によりすでに削除されていた場合、前記連携サーバからの要求に従って、当該ユーザアカウントに対応するトークンを再発行することを特徴とするアクセス管理サーバ。
8. ユーザアカウントおよび当該ユーザアカウントに対応するトークンを管理するアクセス管理サーバと、複数のサービス間の処理を連携させる連携サーバとを含むアクセス管理システムにおける連携サーバであって、
   別のサーバから前記アクセス管理サーバに管理されたユーザアカウントに対応するトークンの発行を要求された際に、当該ユーザアカウントが前記アクセス管理サーバ側で削除されていない場合、前記ユーザアカウントに対応する発行済みのトークンを取得し、当該ユーザアカウントが前記アクセス管理サーバ側ですでに削除されていた場合、当該ユーザアカウントを前記アクセス管理サーバに再び登録させ、再び登録させたユーザアカウントに対応して発行されたトークンを取得する取得手段と、
   前記取得手段にて取得された発行済のトークンが期限切れであった場合、トークンの再発行を前記アクセス管理サーバに要求する要求手段と
   を有し、
   前記要求手段は、前記取得手段にて再び登録させたユーザアカウントに対応するトークンが、前記アクセス管理サーバ側ですでに削除されていた場合、当該再び登録したユーザアカウントに対応するトークンの再発行を前記アクセス管理サーバに要求することを特徴とする連携サーバ。
9. ユーザアカウントおよび当該ユーザアカウントに対応するトークンを管理するアクセス管理サーバと、複数のサービス間の処理を連携させる連携サーバとを含むアクセス管理システムにおけるアクセス管理方法であって、
   前記アクセス管理サーバにおいて、
   発行手段が、前記連携サーバの要求に従って、管理しているユーザアカウントに対応するトークンを発行する発行工程と、
   アカウント削除手段が、管理しているユーザアカウントのうち、予め定義された削除に関する条件を満たすユーザアカウントを削除するアカウント削除工程と
   トークン削除手段が、前記ユーザアカウントに対応して発行されたトークンのうち、期限切れのトークンを削除するトークン削除工程と
   を有し、
   前記連携サーバにおいて、
   取得手段が、別のサーバから前記アクセス管理サーバに管理されたユーザアカウントに対応するトークンの取得を要求された際に、当該ユーザアカウントが前記アカウント削除工程にて削除されていない場合、前記ユーザアカウントに対応する発行済のトークンを取得し、当該ユーザアカウントが前記アカウント削除工程にてすでに削除されていた場合、当該ユーザアカウントを前記アクセス管理サーバに再び登録させ、再び登録させたユーザアカウントに対応して発行されたトークンを取得する取得工程と、
   要求手段が、前記取得工程にて取得された発行済のトークンが期限切れであった場合、トークンの再発行を前記発行手段に要求する要求工程と
   を有し、
   前記要求工程において、前記取得工程にて再び登録させたユーザアカウントに対応するトークンが、前記トークン削除工程にてすでに削除されていた場合、当該再び登録したユーザアカウントに対応するトークンの再発行を前記発行手段に要求することを特徴とするアクセス管理方法。
10. コンピュータを、
    複数のサービス間の処理を連携させる連携サーバの要求に従って、管理しているユーザアカウントに対応するトークンを発行する発行手段、
    管理しているユーザアカウントのうち、予め定義された削除に関する条件を満たすユーザアカウントを削除するアカウント削除手段
    前記ユーザアカウントに対応して発行されたトークンのうち、期限切れのトークンを削除するトークン削除手段
    として機能させ、
    前記発行手段は、前記連携サーバの要求に従って、発行済みのトークンのうちの期限切れのトークンの再発行を行い、
    前記発行手段は、前記アカウント削除手段により削除されたユーザアカウントが前記連携サーバから要求に従って再び登録された際に、当該ユーザアカウントに対応するトークンが前記トークン削除手段によりすでに削除されていた場合、前記連携サーバからの要求に従って、当該ユーザアカウントに対応するトークンを再発行することを特徴とするプログラム。
11. コンピュータを、
    別のサーバからアクセス管理サーバに管理されたユーザアカウントに対応するトークンの発行を要求された際に、当該ユーザアカウントが前記アクセス管理サーバ側にて削除されていない場合、前記ユーザアカウントに対応する発行済みのトークンを取得し、当該ユーザアカウントが前記アクセス管理サーバ側にてすでに削除されていた場合、当該ユーザアカウントを前記アクセス管理サーバに再び登録させ、再び登録させたユーザアカウントに対応して発行されたトークンを取得する取得手段
    前記取得手段にて取得された発行済のトークンが期限切れであった場合、トークンの再発行を前記アクセス管理サーバに要求する要求手段
    として機能させ、
    前記要求手段は、前記取得手段にて再び登録させたユーザアカウントに対応するトークンが、前記アクセス管理サーバ側ですでに削除されていた場合、当該再び登録したユーザアカウントに対応するトークンの再発行を前記アクセス管理サーバに要求することを特徴とするプログラム。

Images