JP2014203267A - システムおよびその制御方法、アクセス管理サービスシステムおよびその制御方法、並びにプログラム - Google Patents

Abstract

【課題】クラウドサービス同士の連携において、外部サービスに対してユーザーの権限を委譲する技術がある。ここで、ユーザーによって認可されていたとしても、特定の外部サービス以外からはユーザーの情報にアクセスさせてはいけない場合がある。
【解決手段】リソースサービスシステムが提供するサービスの利用を管理するアクセス管理サービスシステムであって、前記サービスを利用する権限を有するユーザーからの指示に起因して前記クライアントシステムから当該サービスに対する利用の認可要求を受け付けた場合、前記ユーザーが所属するグループと前記クライアントシステムが所属するグループとが一致するか否かを判定する判定手段と、前記判定手段によりグループが一致すると判定された場合、前記ユーザーの権限を前記クライアントシステムに委譲することを許可するか否かを指示するための画面を前記ユーザーに提示する提示手段とを有する。
【選択図】 図１

Description

本願発明は、システムおよびその制御方法、アクセス管理サービスシステムおよびその制御方法、並びにプログラムに関する。

近年、クラウドが一般化するに伴い、複数のサービス（文書作成サービスなど）を連携させて付加価値を創造する機会が増加している。一方、サービスが連携することにより、いくつかの課題が生まれる。

例えば、サービス間の連携により、ユーザーが望んだ以上の情報がサービス間で交換されるため、ユーザーデータや個人情報の漏えいリスクがある。例えば、様々なサービス間でサービス連携が実現される際に、ユーザーが望む結果を提供するサービス以外のサービスがユーザーデータ、個人情報等を取得することは望ましくない。一方で、サービスの提供者からすると、サービス連携の仕組みは容易に実装できるものが好ましい。

このような状況において、ＯＡｕｔｈと呼ばれる、認可の連携を実現させるための標準プロトコルが策定されている（例えば、非特許文献１参照）。ＯＡｕｔｈによれば、例えばあるサービスＡが管理するユーザーのデータに、そのユーザーから認められた外部サービスＢがアクセスすることができる。このときサービスＡは、外部サービスＢからアクセスされる範囲を明らかにした上で、外部サービスＢによるアクセスに対してユーザーの明示的な認可を得ることになっている。ユーザーが明示的に認可を行うことを“認可操作”と称する。

ユーザーが認可操作を行うと、外部サービスＢはサービスＡからアクセスを認められたことを証明するトークン(以下、“認可トークン”と称する)を受け取り、以降のアクセスはその認可トークンを用いて実現できる。これにより、ユーザーのサービスＡの権限を、外部サービスＢに委譲する事ができる。そして、認可トークンを用いると外部サービスＢは、ユーザーの認証情報なしに、認可を行ったユーザーの権限でサービスＡにアクセスできる。これに伴い、ユーザーから認可を受け認可トークンを取得した外部サービスＢは、その認可トークンを厳重かつ適正に管理する責務を負う。

さらにＯＡｕｔｈによれば、権限を委譲する側の確認に加え、権限が委譲される側の確認も行う事ができる。例えば、ユーザーが外部サービスＢに対してサービスＡへのアクセスを認可する際に、ユーザーがサービスＡの利用権限を持つかの確認と、外部サービスＢがサービスＡの利用権限を持つかの確認を行う事ができる。

また権限が委譲される側の確認について、ユーザーが認可操作をする際に、権限を委譲する外部サービスを明示的に指定する方法がある（例えば、参考文献１）。この方法により外部サービスを制限しながら、認可によるサービス連携が行える。

特表２００６−２５４４６４号公報

Ｄ．Ｈａｒｄｔ、"Ｔｈｅ ＯＡｕｔｈ ２．０ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ"、[online]、２０１２年７月３１日、[平成２５年３月２５日検索]、インターネット＜URL: http://tools.ietf.org/html/draft-ietf-oauth-v2-31＞

認可によるサービス連携において、ユーザーに認可されていたとしても、特定の外部サービス以外からはアクセスさせたくない場合がある。例えば、Ａ社の社内システムである外部サービスＸとクラウドサービスＹとを連携させる場合がある。Ａ社のユーザーＡがクラウドサービスＹを利用する権限を持つ場合、外部サービスＸに対してクラウドサービスの利用権限を委譲すると、外部サービスＸはクラウドサービスＹ上のＡ社の情報にアクセスできるようになる。

ここで、クラウドサービスＹは、同一のサービス上で複数の会社の情報をテナントという単位で管理するモデルであるとする。その場合、クラウドサービスＹには、Ａ社とは別テナントとしてＢ社が存在し、かつクラウドサービスＹの利用権限を持つＢ社のユーザーＢが存在する場合がある。このユーザーＢが外部サービスＸに対してクラウドサービスＹの利用権限を委譲すると、外部サービスＸはクラウドサービスＹ上のＢ社の情報にアクセスできるようになる。この場合、Ａ社の社内システムである外部サービスＸが、Ｂ社の情報にアクセスできてしまうため、セキュリティ上問題となると考えられる。このように、例えユーザーから認可されていても、外部サービスによってはアクセスを許可してはいけない場合が考えられる。

しかしながら、現状のＯＡｕｔｈでは、ユーザーＢと外部サービスＸのそれぞれがクラウドサービスＹの利用権限を持っている場合には、ユーザーＢから外部サービスＸに対してクラウドサービスＹの利用権限が委譲出来てしまう。そのため、外部サービスＸがＢ社の情報にアクセスできないようにするためには、クラウドサービスＹにおいて、外部サービスＸがアクセスできる情報の範囲を管理する必要がある。

しかし、この方法では認可操作自体は防げないため、無駄な権限委譲の処理が行えてしまうという課題を持つ。つまり、上記の方法では認可操作自体は防げないため、ユーザーＢが認可操作を行い、外部サービスＸに対してクラウドサービスＹの利用権限を委譲することにより、認可トークンを発行できる。しかし、外部サービスＸがこの認可トークンを利用してクラウドサービスＹにアクセスしようとすると、クラウドサービスＹでの判定により、権限がないとしてアクセスが拒否される。このように、利用できない権限の委譲が行えてしまい、利用できない認可トークンを無駄に発行出来てしまう。また、ユーザーが外部サービスに対して、外部サービスがアクセスできない情報へのアクセス権を委譲できることは好ましくない。

また、上記の方法はクラウドサービス側の負担が大きいという課題も持つ。例えば、クラウドサービスが全テナントそれぞれに対して、アクセスできる外部サービスを管理する必要がある。その上、外部サービスからアクセス要求があるたびに、クラウドサービスがアクセス可否判定を行う必要もある。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、サービスを提供するリソースサービスシステムと、前記サービスの利用を管理するアクセス管理サービスシステムとを含むシステムであって、前記アクセス管理サービスシステムは、ユーザーの情報およびクライアントシステムの情報を記憶部に保持する保持手段と、前記サービスを利用する権限を有するユーザーからの指示に起因して前記クライアントシステムから当該サービスに対する利用の認可要求を受け付けた場合、前記記憶部にて保持する情報に基づいて、前記ユーザーが所属するグループと前記クライアントシステムが所属するグループとが一致するか否かを判定する判定手段と、前記判定手段によりグループが一致すると判定された場合、前記ユーザーの権限を前記クライアントシステムに委譲することを許可するか否かを指示するための画面を前記ユーザーに提示する提示手段とを有し、前記リソースサービスシステムは、前記画面を介してユーザーの権限の委譲を許可することが指示されたことに応じて発行されるアクセス制御情報を前記クライアントシステムから受信した場合、前記アクセス制御情報の正当性が確認されたことに応じてサービスを提供する提供手段とを有する。

本願発明により、サービス連携において、無駄な権限委譲が防げる。また、サービス連携を行う際に、クラウドサービス側の負担を増やすことなく、適切な情報の範囲で認可連携を行う事ができる。

システム全体図。 サーバーのハードウェアの構成例の図。 外部サービスシステムのソフトウェアの構成例の図。 アクセス管理サービスシステムのソフトウェアの構成例の図。 リソースサービスシステムのソフトウェアの構成例の図。 外部サービスシステムが保持するデータ構造を示したテーブルの例を示す図。 アクセス管理サービスシステムが保持するアカウントテーブルの例を示す図。 アクセス管理サービスシステムが保持する認可トークンのデータ構造を示したテーブルの図。 アクセス管理サービスシステムが保持するクライアント証明書のデータ管理テーブルの図。 認可トークン発行のフローチャート。 認可画面の一例を示した図。 シングルテナントクライアント発行処理のフローチャート。 マルチテナントクライアント発行処理のフローチャート。 マルチテナントクライアント作成のためのクライアント証明書登録のフローチャート。 クライアント発行画面の一例を示した図。 クライアント発行処理のフローチャート。

以下、本発明を実施するための形態について図面を用いて説明する。

＜実施形態１＞
インターネット上で、様々なサービス提供者が様々なオンラインサービスを提供している。単一のサービス提供者が運営している単体のオンラインサービスもあれば、複数のサービス提供者が運営している複数のオンラインサービスを組み合わせて、１つのソリューションを実現するという手法も存在する。後者は、「マッシュアップ」と呼ばれ、表向きはあたかも１つのＷｅｂサイトあるいはＷｅｂサービスとして見える。しかしながら、実際にはバックエンドでは、複数のオンラインサービスが連携・連動して、必要な機能を組み合わせてソリューションを実現する。なお、ここで言うオンラインサービスとは、Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどが提供する機能群のことである。Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどは、サーバーコンピューターで実行されるソフトウェアである。

また、本明細書内で述べる認可トークン、リフレッシュトークン、認可コード等の用語は、ＯＡｕｔｈにて定義されているものであり、これに準ずるものとする。

［システム構成］
図１は、各種オンラインサービスが存在するネットワーク構成を示している。インターネット１００は、インターネットなどの外部から接続可能なパブリックなネットワークである。イントラネット１０１は、ＬＡＮ(Local Area Network)などの外部から接続不可能なプライベートなネットワークである。

情報機器端末１０２は、インターネット１００を介してオンラインサービスを利用する際に使用されるパーソナルコンピューターやモバイル端末などの情報処理装置である。ＯＡｕｔｈにおいては、情報機器端末１０２を操作するユーザーを“オーナー”、情報機器端末１０２が備えるＷｅｂブラウザを“ユーザーエージェント”と呼ぶ。

外部サービスシステム１０３は、後述するリソースサービスシステム１０５をオンラインでマッシュアップしたオンラインサービスシステムである。外部サービスシステム１０３は、ＯＡｕｔｈにおいては“クライアント”と呼ばれるため、本実施形態では外部サービスシステム１０３をクライアント（または、クライアントシステム）と称することもある。

アクセス管理サービスシステム１０４は、ユーザーの認証情報及び認可情報を管理する認可サービスシステムである。ＯＡｕｔｈにおいては“認可サーバー”と呼ばれる。

リソースサービスシステム１０５は、印刷サービスや帳票サービスといったリソースサービスを提供しているオンラインサービスシステムである。ＯＡｕｔｈにおいては“リソースサーバー”と呼ばれる。リソースサービスシステム１０５は、インターネット１００を介した情報機器端末１０２あるいは外部サービスシステム１０３からのリクエストに応じて、リソースサービスを提供する。なおリソースサービスシステムに設置されるリソースサービスは１つでもよく、複数でもよい。

なお、情報機器端末１０２、外部サービスシステム１０３、アクセス管理サービスシステム１０４、およびリソースサービスシステム１０５はそれぞれ個別のＬＡＮ上に構成されていてもよいし、同一のＬＡＮ上に構成されていてもよい。また、アクセス管理サービスシステム１０４とリソースサービスシステム１０５は物理的に同一の装置上に構成されていてもよい。

認可サーバー、およびリソースサーバーは１台ではなく複数台で構成されるサーバー群であっても良い。認可サーバーシステムと称した場合、認可サービスモジュールを備えた１台のサーバー、または複数台のサーバー群を指す。また、リソースサーバーシステムについても同様で、リソースサービスを備えた１台のサーバー、または複数台のサーバーを指す。

［ハードウェア構成］
図２は、図１に示した各種サービスが配置されているサーバーのハードウェア構成の例である。ユーザーインターフェース２０１は、ディスプレイ、キーボード、マウスなどの情報の入出力を行うためのハードウェアである。これらのハードウェアを備えないコンピューターは、リモートデスクトップなどにより、他のコンピューターから接続・操作することも可能である。

ネットワークインターフェース２０２は、ＬＡＮなどのネットワークに接続して、他のコンピューターやネットワーク機器との通信を行うハードウェアである。ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などから読み込んだプログラムを実行し、各種サービスを実現する。ＲＯＭ２０４は、組込済みプログラムおよびデータが記録されている記憶装置である。ＲＡＭ２０５は、一時メモリ領域である。二次記憶装置２０６は、ＨＤＤに代表されるような外部記憶装置である。各部は入出力インターフェース２０７を介して接続されている。

［ソフトウェア構成］
図３は、外部サービスシステム１０３のソフトウェア構成の例を示したブロック図である。

リクエスト処理部３０１は、外部サービスシステム１０３がインターネット１００を経由して受信した機能リクエストを処理する。機能制御部３０２は、リクエスト処理部３０１からの要求を受け、要求に応じて必要な処理を行い、応答データを呼び出し元に返す。機能連携データ３０３は、外部サービスシステム１０３が連携しているシステムに対するリクエストを生成するためのデータを管理する。認可コード管理部３０４は、認可コードのデータを管理する。トークン管理部３０５は、認可情報のデータを管理する。

図４は、アクセス管理サービスシステム１０４のソフトウェア構成の例を示したブロック図である。

アクセス管理リクエスト処理部４０１は、アクセス管理サービスシステム１０４がインターネット１００及びイントラネット１０１を経由して受信した認証および認可リクエストを処理する。また、アクセス管理リクエスト処理部４０１は、アクセス制御部４０２から返される応答データを呼び出し元に返す。アクセス制御部４０２は、認証データ管理部４０３及び認可データ管理部４０４から取得するデータに基づき、認証および認可リクエストに対して応答データを生成し、アクセス管理リクエスト処理部４０１に応答データを返す。認証データ管理部４０３は、ユーザーアカウントのデータを管理する。認可データ管理部４０４は、認可情報のデータを管理する。

図５は、リソースサービスシステム１０５のソフトウェア構成の例を示したブロック図である。

リクエスト処理部５０１は、インターネット１００を経由してリソースサービスへのリクエストを受け取る。例えばリソースサービスが帳票サービスの場合、リクエスト処理部５０１は、リクエストとして帳票データ生成リクエスト及び帳票データ取得リクエストを受信する。機能制御部５０２は、リクエスト処理部５０１が受信したリクエストに応じて必要な処理を行い、応答データを呼び出し元に返す。また、機能制御部５０２は、イントラネット１０１経由でアクセス管理サービスシステム１０４に対して認証リクエストを送信し、認証結果を受信する。また、機能制御部５０２は、アクセス管理サービスシステム１０４に対して認可確認リクエストを送信し、認可確認結果を受信する。処理部５０３は、機能制御部５０２からのリクエストを受信して、リクエストに応じた処理を行い、機能制御部５０２に返す。例えば帳票サービスの場合、処理部５０３は、帳票データ生成リクエストを受信して、帳票データを生成する。

［管理テーブルの構成例］
図６は、外部サービスシステム１０３が保持する認可情報および外部サービスシステムの管理情報のデータ構造の例をテーブル形式で示した図である。認可情報および認可に関連する情報は認可情報管理テーブル６００にて管理され、外部サービスシステムの管理情報は連携サービス情報テーブル６１０で管理される。

図６（ａ）に示す認可情報管理テーブル６００は、連携システムを示すクライアントＩＤ６０１、認可情報を示す認可トークンＩＤ６０２、更新認可情報を示すリフレッシュトークンＩＤ６０３、および、システム名を示す連携先システム名６０４を含む。クライアントＩＤ６０１には、図１の外部サービスシステム１０３を一意に識別するためのＩＤ（識別子）を保存する。認可トークンＩＤ６０２には、アクセス管理サービスシステム１０４が発行するアクセス制御情報である認可トークンを一意に識別するためのＩＤを保存する。リフレッシュトークンＩＤ６０３には、アクセス管理サービスシステム１０４が発行するリフレッシュトークンを一意に識別するためのＩＤを保存する。

図６（ｂ）に示す連携サービス情報テーブル６１０は、外部サービスシステム１０３を認証するためのクライアントＩＤ６１１、パスワード６１２、認可時に利用するエンドポイントＵＲＬ６１３、およびリダイレクトＵＲＬ６１４を含む。クライアントＩＤ６１１とパスワード６１２は、後述のアクセス管理サービスシステム１０４が発行した情報であり、後述のユーザーテーブル７００に同じ情報が記憶される。さらに、リダイレクトＵＲＬ６１４も、後述のクライアントテーブル７１０に同じ情報が記憶される。なお、エンドポイントＵＲＬ６１３は、アクセス管理サービスシステム１０４が公開する、ＯＡｕｔｈのためのエンドポイントのＵＲＬである。図６の各データ構造に格納されるデータの処理詳細については後述する。

図７は、アクセス管理サービスシステム１０４が保持するユーザー情報およびシステム情報のデータ構造の例をテーブル形式で示した図である。ユーザー情報はユーザーテーブル７００にて管理され、システム情報はクライアントテーブル７１０で管理される。

ここで管理されているユーザー情報は、アクセス管理サービスシステム１０４が管理しているユーザーおよび外部サービスシステムのアカウント情報である。なお、外部サービスシステムのアカウント情報は、後述のＯＡｕｔｈのシーケンスで、認可サーバーがクライアント認証するために利用する認証情報である。本実施形態においては、クライアントである外部サービスシステム１０３のアカウントが登録されている。

図７（ａ）に示すユーザーテーブル７００は、ユーザーＩＤ７０１、パスワード７０２、ユーザー種別７０３、およびテナントＩＤ７０４を含む。ユーザー種別７０３は、そのアカウントがユーザーであるか、クライアントであるかを示す。更に、ユーザー種別７０３がクライアントである場合は、アクセスできる情報が制限されていないか、制限されているかを示す。本実施形態では、アクセスできる情報が制限されていないクライアントを「マルチテナントクライアント」、アクセスできる情報が制限されているクライアントを「シングルテナントクライアント」と記載する。

マルチテナントクライアントは権限委譲されると、後述する所属グループに関係なく、権限委譲を行ったユーザーが所属するグループの情報にアクセス可能となる。具体的には、グループ「１０００００１ＡＡ」に所属しているマルチテナントクライアントが、グループ「１００１ＡＡ」に所属しているユーザーから権限委譲を受けると、マルチテナントクライアントは異なるグループ「１００１ＡＡ」のデータにアクセスできる。そのため、全てのユーザーから権限委譲を受けることができる。一方、シングルテナントクライアントは、後述する所属グループの定義に従い、自身が所属するグループの情報にしかアクセスできない。具体的には、グループ「１００１ＡＡ」に所属しているシングルテナントクライアントは、「１００１ＡＡ」内のデータにしかアクセスできない。そのため、同じグループ「１００１ＡＡ」のユーザーからの権限委譲しか受け付けない。

テナントＩＤ７０４は、そのアカウントが所属するグループを一意に識別するための情報を示す。グループとは、アクセス管理サービスシステム１０４が管理しているアカウントがアクセス可能な範囲を定義しているものであり、例えば企業単位などで分けるものである。そして同一グループ内であれば、アカウントの権限に従って他のアカウントの情報や自グループの情報へのアクセスを許可する。具体的には、グループ「１００１ＡＡ」に所属している管理者権限を持つユーザーは、グループ「１００１ＡＡ」内の他のユーザーアカウント情報の参照や、グループ「１００１ＡＡ」の情報の参照が行える。しかし、管理者権限を持っていても、グループ「１００１ＡＡ」のユーザーは、他グループ「１００２ＡＡ」のアカウント情報や、グループ「１００２ＡＡ」の情報の参照はできない。

図７（ｂ）に示すクライアントテーブル７１０は、クライアントＩＤ７１１、クライアント名７１２、およびリダイレクトＵＲＬ７１３を含む。クライアントＩＤ７１１は、ユーザーテーブル７００のユーザーＩＤ７０１と関連付いており、互いに参照可能となっている。クライアント名７１２およびリダイレクトＵＲＬ７１３は、後述のＯＡｕｔｈのシーケンスで、認可トークンを発行する際に利用される値である。図７の各データ構造に格納されるデータの処理詳細については後述する。

図８は、アクセス管理サービスシステム１０４が保持する認可情報のデータ構造の例をテーブル形式で示した図である。認可情報テーブル８００は、認可トークンＩＤ８０１、トークン種別８０２、有効期限８０３、スコープ８０４、リフレッシュトークンＩＤ８０５、リフレッシュ期限８０６、クライアントＩＤ８０７、およびユーザーＩＤ８０８を含む。図８のデータ構造に格納されるデータの処理詳細については後述する。

図９は、アクセス管理サービスシステム１０４が保持するクライアント証明書管理情報のデータ構造の例をテーブル形式で示した図である。証明書管理テーブル９００は、クライアント証明書のシリアル番号９０１、Ｓｕｂｊｅｃｔ９０２、およびＤＮ９０３を含む。図９のデータ構造に格納されるデータの処理詳細については後述する。

［処理フロー］
図１０は、アクセス管理サービスシステム１０４が情報機器端末１０２を操作するユーザーからの要求を受け、外部サービスシステム１０３に対して、リソースサービスシステム１０５の利用を許可する認可トークンを発行するフローを示す。本例ではリソースサービスを帳票サービスとし、ユーザーが帳票生成を指示したものとして説明を行う。また、外部サービスシステム１０３は、アクセス管理サービスシステム１０４上のユーザーテーブル７００（図７（ａ））において、ユーザーＩＤ「ｓｙｓ００００００２」として管理されているものとする。

なお、外部サービスシステム１０３と帳票サービスシステム（リソースサービスシステム１０５）は、それぞれ別のサービス提供者が運営しているオンラインサービスシステムであるとする。また、帳票サービスシステムは、アクセス管理サービスシステム１０４によって、別のサービスからのアクセスが制御されている。

また、本フローにおける各処理は、処理主体におけるＣＰＵが二次記憶装置等の記憶部に格納された本実施形態に係るプログラムをＲＡＭに読み出して実行することにより実現される。

Ｓ１００１において、情報機器端末１０２Ａは、ユーザーＡからの帳票生成要求を受け、外部サービスシステム１０３に対して帳票生成指示を行う。

Ｓ１００２において、外部サービスシステム１０３は、情報機器端末１０２Ａから帳票生成指示を受け付ける。その後、外部サービスシステム１０３は、認可情報管理テーブル６００（図６（ａ））を参照し、帳票サービスシステムに対する認可トークンを所持しているかの確認を行う。

帳票サービスシステムに対する認可トークンを所持している場合（Ｓ１００２にてＹＥＳ）、認可トークン発行フローを終了する。帳票サービスシステムに対する認可トークンを所持していない場合（Ｓ１００２にてＮＯ）、外部サービスシステム１０３はＳ１００３において、ユーザーからの帳票生成指示に起因したアクセス管理サービスシステム１０４に対する認可要求を行う。この認可要求には、連携サービス情報テーブル６１０のクライアントＩＤ６０１、リダイレクトＵＲＬ６１４の情報が含まれる。この時、ＯＡｕｔｈでは、認可を受けたい権限範囲を示すスコープを認可要求に含むよう構成する事もできる。本実施形態では、スコープとしてスコープAがリクエストされたとして説明する。

Ｓ１００４において、アクセス管理サービスシステム１０４は、外部サービスシステム１０３からの認可要求を受けると、ユーザーＡに対して認証処理を促す認証画面（不図示）を生成し、情報機器端末１０２Ａが備えるＷｅｂブラウザ（不図示）に表示させる。

Ｓ１００５において、情報機器端末１０２Ａは、情報機器端末１０２上のＷｅｂブラウザ（不図示）に表示した認証画面を介して、ユーザーＡからユーザーＩＤとパスワードを受け付ける。その後、情報機器端末１０２Ａは、アクセス管理サービスシステム１０４に、受け付けたユーザーＩＤとパスワードを認証要求として送る。

Ｓ１００６において、アクセス管理サービスシステム１０４は、情報機器端末１０２Ａから認証要求を受け、ユーザーＩＤおよびパスワードを検証する。具体的には、認証要求に含まれるユーザーＩＤとパスワードとの組み合わせが認証データ管理部４０３に格納されたユーザーテーブル７００（図７（ａ））に登録されているか否かを確認する。ユーザーＩＤとパスワードとの組合せがユーザーテーブル７００に登録されている場合には（Ｓ１００６にてＹＥＳ）、アクセス管理サービスシステム１０４は、情報機器端末１０２を操作するユーザーＡを帳票サービスシステムのユーザーであると判断する。その後、Ｓ１００９に進み、処理を継続する。

ユーザーＩＤとパスワードとの組合せがユーザーテーブル７００に登録されていない場合（Ｓ１００６にてＮＯ）、アクセス管理サービスシステム１０４は、情報機器端末１０２Ａを操作するユーザーＡを帳票サービスシステムのユーザーではないと判断する。その後、アクセス管理サービスシステム１０４は、外部サービスシステム１０３に対し、Ｓ１００４の応答として認証エラーを返す。

Ｓ１００７において、外部サービスシステム１０３は、アクセス管理サービスシステム１０４から認証エラーを受け取ると、認証エラー画面（不図示）を生成し、情報機器端末１０２Ａに送る。その後、Ｓ１００８において、情報機器端末１０２Ａは、情報機器端末１０２Ａが備えるＷｅｂブラウザ（不図示）にエラー画面を表示し、処理を終了する。

Ｓ１００９において、アクセス管理サービスシステム１０４は、認可要求元である外部サービスシステム１０３のユーザー種別を判定する。このとき、アクセス管理サービスシステム１０４は、外部サービスシステム１０３のユーザーＩＤを用いて、ユーザーテーブル７００からユーザー種別を取得する。そして、アクセス管理サービスシステム１０４は、要求元である外部サービスシステムがアクセスできる情報を制限されているクライアントであるか否かを判定する。アクセスできる情報が制限されていないユーザー種別であった場合は（Ｓ１００９にてＹＥＳ）、Ｓ１０１１に進む。また、アクセスできる情報が制限されているユーザー種別であった場合は（Ｓ１００９にてＮＯ）、Ｓ１０１０に進む。

具体的には、要求を行った外部サービスのユーザーＩＤが「ｓｙｓ００００００１」である場合、ユーザーテーブル７００においてユーザー種別は「マルチテナントクライアント」となる。この場合、アクセス管理サービスシステム１０４は、要求を行った外部サービスシステムを、アクセスできる情報が制限されていないクライアントと判断する（Ｓ１００９にてＹＥＳ）。一方で、要求を行った外部サービスのユーザーＩＤが「ｓｙｓ００００００２」である場合、ユーザーテーブル７００においてユーザー種別は「シングルテナントクライアント」となる。この場合、アクセス管理サービスシステム１０４は、要求を行った外部サービスを、アクセスできる情報が制限されているクライアントと判断する（Ｓ１００９にてＮＯ）。

ここで示す例では、外部サービスシステム１０３のユーザーＩＤは「ｓｙｓ００００００２」であるため、アクセス管理サービスシステム１０４は、外部サービスシステム１０３をアクセスできる情報が制限されているクライアントであると判断する。

Ｓ１０１０において、アクセス管理サービスシステム１０４は、認可要求を行ったユーザーと外部サービスシステム１０３のそれぞれの所属グループを確認する。このとき、アクセス管理サービスシステム１０４は、ユーザーテーブル７００からユーザーと外部サービスのテナントＩＤを取得する。そして、アクセス管理サービスシステム１０４は、取得したテナントＩＤを比較し、一致するか否かを判定する。クライアントがユーザーと同じグループに所属している場合（Ｓ１０１０にてＹＥＳ）、アクセス管理サービスシステム１０４は、ユーザーがアクセスできる情報と同じ情報にクライアントがアクセスしてよいと判断し、Ｓ１０１０に進む。一方、クライアントとユーザーが異なるグループに所属している場合（Ｓ１０１０にてＮＯ）、アクセス管理サービスシステム１０４は、ユーザーがアクセスできる情報にはクライアントがアクセスしてはいけないと判断し、エラーとしてＳ１００７に進む。

ここで示す例では、外部サービスシステム１０３のユーザーＩＤは「ｓｙｓ００００００２」であり、テナントＩＤは「１００１ＡＡ」となる。ここで、Ｓ１００６でログインしたユーザーが「ｕｉｄ００００００１」の場合、ユーザーのテナントＩＤは「１００１ＡＡ」となる。この場合、クライアントとユーザーが同じグループ（テナント）に所属しており、アクセス管理サービスシステム１０４は、外部サービスシステム１０３はユーザーがアクセスを許可した情報にアクセスできると判断する。一方、ユーザーが「ｕｉｄ００００００２」である場合、ユーザーのテナントＩＤは「１００２ＡＡ」となる。この場合、クライアントとユーザーが別グループに所属しており、アクセス管理サービスシステム１０４は、ユーザーがアクセスを許可してもクライアントはそのデータにアクセスしてはいけない、と判断する。

Ｓ１０１１において、アクセス管理サービスシステム１０４は、クライアントテーブル７１０からクライアント情報を取得し、後述する認可画面１１００を生成し、情報機器端末１０２Ａが備えるＷｅｂブラウザ（不図示）に送信する。

Ｓ１０１２において、情報機器端末１０２Ａは、認可画面１１００をＷｅｂブラウザを介してユーザーに提示した後、ユーザーから認可画面１１００の認可ボタン１１０２の押下を受け付けると、アクセス管理サービスシステム１０４に対して認可承認を送信する。

Ｓ１０１３において、アクセス管理サービスシステム１０４は、受け取った認可承認を元に認可コードを生成し、認可情報テーブル８００（図８）に格納する。この際、アクセス管理サービスシステム１０４は、認可情報テーブル８００において、認可トークンＩＤ８０１に発行した認可コードのＩＤ、トークン種別８０２に「認可コード」、有効期限８０３、スコープ８０４に指定された「スコープＡ」を登録する。更に、アクセス管理サービスシステム１０４は、Ｓ１００３の認可要求時に外部サービスシステム１０３から受け取ったクライアントＩＤをクライアントＩＤ８０７、認証情報に紐付くユーザーＩＤをユーザーＩＤ８０８に登録する。その後、アクセス管理サービスシステム１０４は、認可応答として情報機器端末１０２Ａが備えるＷｅｂブラウザ（不図示）を外部サービスシステム１０３にリダイレクトさせる。この際、アクセス管理サービスシステム１０４は、生成した認可コードの情報を外部サービスシステム１０３に返す。

Ｓ１０１４において、外部サービスシステム１０３は受け取った認可コードの情報を認可情報管理テーブル６００に格納する。その後、外部サービスシステム１０３は、アクセス管理サービスシステム１０４に対して認可トークン要求を行う。この要求には、認可コードに対応する認可トークンＩＤ、連携サービス情報テーブル６１０に格納されているクライアントＩＤとパスワード、およびリダイレクトＵＲＬが含まれる。

Ｓ１０１５において、アクセス管理サービスシステム１０４は、認可トークン要求を受け、外部サービスシステム１０３の認証を行う。具体的には、アクセス管理サービスシステム１０４は、認可トークン要求に含まれるクライアントＩＤとパスワードの組合せが、認証データ管理部４０３に格納されたユーザーテーブル７００に登録されているかを確認する。クライアントＩＤとパスワードの組み合わせがユーザーテーブル７００に登録されていた場合には（Ｓ１０１５にてＹＥＳ）、アクセス管理サービスシステム１０４は、外部サービスシステム１０３を認証し、Ｓ１０１６に進み処理を継続する。クライアントＩＤおよびパスワードの組合せがクライアントテーブル７１０に登録されていない場合には（Ｓ１０１５にてＮＯ）、アクセス管理サービスシステム１０４は、外部サービスシステム１０３を認証せず、認証エラーと判断する。その場合、アクセス管理サービスシステム１０４は、認証エラーを外部サービスシステム１０３に送信して、Ｓ１０１７に進む。

Ｓ１０１６において、アクセス管理サービスシステム１０４は、認可トークン要求に含まれる認可コードの検証を行う。具体的には、アクセス管理サービスシステム１０４は、認可コードに対応する認可トークンＩＤが認可情報テーブル８００に登録されており、かつ有効期限内かを検証する。更に、アクセス管理サービスシステム１０４は、クライアントＩＤとリダイレクトＵＲＬの組合せが、クライアントテーブル７１０に登録されているかを確認する。

認可コードの検証に成功すると、アクセス管理サービスシステム１０４は帳票サービスの利用が許可されていると判断し（Ｓ１０１６にてＹＥＳ）、Ｓ１０１８に進み、アクセス管理サービスシステム１０４は、処理を継続する。認可コードの検証に失敗すると、アクセス管理サービスシステム１０４は、帳票サービスの利用が許可されていないと判断する（Ｓ１０１６にてＮＯ）。その場合、アクセス管理サービスシステム１０４は、認可エラーを外部サービスシステム１０３に送信し、Ｓ１０１７に進む。

Ｓ１０１７において、外部サービスシステム１０３は、アクセス管理サービスシステム１０４から認証エラー、あるいは認可エラーを受け取る。外部サービスシステム１０３は、受け取ったエラーに対応した認証エラー画面（不図示）あるいは認可エラー画面（不図示）を生成し、情報機器端末１０２に送る。Ｓ１００８において、情報機器端末１０２Ａは、外部サービスシステム１０３から受け取ったエラー画面を表示し、処理を終了する。

Ｓ１０１８において、アクセス管理サービスシステム１０４は、認可トークンを生成し、認可情報テーブル８００に登録する。その際、アクセス管理サービスシステム１０４は、認可トークンＩＤ８０１に発行したトークンのＩＤ、トークン種別８０２に「認可トークン」、有効期限８０３、スコープ８０４を登録する。そして、アクセス管理サービスシステム１０４は、認可コードから引き継ぐ情報として、クライアントＩＤ８０７、ユーザーＩＤ８０８を登録する。この際、アクセス管理サービスシステム１０４は、認可トークンをリフレッシュするためのリフレッシュトークンを発行してもよい。リフレッシュトークンを発行した場合、アクセス管理サービスシステム１０４は、リフレッシュトークンＩＤ８０５、リフレッシュ期限８０６を登録する。

その後、アクセス管理サービスシステム１０４は、生成した認可トークンとリフレッシュトークンをＳ１０１４の応答として外部サービスシステム１０３に返す。

Ｓ１０１９において、外部サービスシステム１０３は、アクセス管理サービスシステム１０４から受け取った認可トークンおよびリフレッシュトークンを、トークン管理部３０５で管理される認可情報管理テーブル６００に格納する。具体的には、外部サービスシステム１０３は、受け取った認可トークンに対応するＩＤを認可トークンＩＤ６０２に設定し、受け取ったリフレッシュトークンに対応するＩＤをリフレッシュトークンＩＤ６０３に設定する。

こうして発行した認可トークンおよびリフレッシュトークンを保存することで、認可トークン発行フローを終了する。

上記処理フローにより発行された認可トークンを利用して、外部サービスシステム１０３は、リソースサービスシステム１０５が提供する機能を利用できる。例えばリソースサービスが帳票サービスであった場合、外部サービスシステム１０３は発行された認可トークンを帳票サービスに渡し、帳票サービスを利用できる。以下に外部サービスシステム１０３が認可トークンを利用し、帳票サービスを利用する際の処理を説明する。

（認可トークンによるサービスの利用例）
帳票サービスは、アクセス管理サービスシステム１０４に、外部サービスシステム１０３から受け取った認可トークンと、帳票サービスの利用権限を含むスコープを渡し、認可トークンの検証を依頼する。

アクセス管理サービスシステム１０４は、受け取ったアクセストークンの検証を行う。具体的には、受け取ったアクセストークンが認可情報テーブル８００に登録されているかの確認を行う。登録されている場合は、アクセス管理サービスシステム１０４は、有効期限８０３を確認し、アクセストークンが有効期間内かを判定する。さらに、アクセス管理サービスシステム１０４は、スコープ８０４を確認し、アクセストークンが指定されたスコープを持っているかを確認する。アクセストークンが登録されており、有効期間内かつ指定されたスコープを持っていた場合、アクセス管理サービスシステム１０４は、帳票サービスに対しアクセストークン有効を返す。アクセストークンが登録されていなかった場合や、有効期間外であった場合、もしくは、指定されたスコープを持っていなかった場合には、アクセス管理サービスシステム１０４は、帳票サービスに対しアクセストークン無効を返す。

アクセストークンが有効であった場合、帳票サービスは、アクセス管理サービスシステム１０４に認可トークンを送り、認可を行ったユーザーの情報を取得する。アクセス管理サービスシステム１０４は、帳票サービスから受け取った認可トークンを元に、認可情報テーブル８００のユーザーＩＤ８０８を確認し、認可を行ったユーザーのユーザーＩＤを特定する。その上で、アクセス管理サービスシステム１０４は、認可を行ったユーザーの情報をユーザーテーブル７００から取得し、帳票サービスへとユーザー情報を返す。

ここでアクセス管理サービスシステム１０４は、認可されたクライアントのユーザー種別を確認してもよい。認可されたクライアントがシングルテナントクライアントである場合、アクセス管理サービスシステム１０４は、認可を行ったユーザーのテナントＩＤとクライアントのテナントＩＤを比較する。クライアントがシングルテナントクライアントであり、ユーザーとクライアントのテナントＩＤが異なっている場合、クライアントは別グループのユーザー情報にアクセスできないため、アクセス管理サービスシステム１０４は帳票サービスへエラーを返す。

帳票サービスは、認可を行ったユーザー情報を取得すると、自身が管理している情報の内、認可を行ったユーザーが所属するグループ内の帳票データを元に帳票を生成し、外部サービスシステム１０３に送信する。これにより、外部サービスシステム１０３は、認可トークンを利用し、当該認可トークンの正当性が確認されたことに応じて帳票サービスが提供する機能を利用する事ができる。

図１１は、図１０のＳ１０１１において、アクセス管理サービスシステム１０４が生成する認可画面１１００を示した図である。認可画面１１００は、情報表示部１１０１と認可ボタン１１０２、認可キャンセルボタン１１０３から構成される。

情報表示部１１０１は、認可されるサービスと、認可されたサービスが実行するサービスの情報をユーザーに対して示す。本実施形態においては、認可されるサービスとは外部サービスシステム１０３であり、認可されたサービスが実行するサービスとはリソースサービスシステム１０５を指す。

認可ボタン１１０２は、認可を承認する際にユーザーによって押下されるボタンである。認可キャンセルボタン１１０３は、ユーザーが認可を拒否する場合に押下されるボタンである。

（クライアント発行処理）
図１２Ａおよび図１２Ｂは、アクセス管理サービスシステム１０４が外部サービスシステム１０３を識別するためのクライアントの発行処理のフローを示した図である。本実施形態において、核クライアントは、図１０のフローが実行される前に作成されて発行されているものとする。

本実施形態によると、マルチテナントクライアントは、認可されれば全てのテナントに対して処理ができるため、強い権限（第１の権限）が付与されたテナントと言える。そのため、安全性確保のため、アクセス管理サービスシステム１０４が許可した外部サービスのみに、マルチテナントクライアントを発行できるようにする必要がある。

一方、シングルテナントクライアントは、アクセスできる情報が制限されているテナントである。シングルテナントクライアントは、シングルテナントクライアントが所属しているグループ（テナント）内のユーザーからの認可しか受け付けない、弱い権限（第２の権限）が付与されたクライアントである。そのため各グループにおいて、管理者などテナントクライアント作成権限を持つユーザーが、自由に作成できるようにしなくてはならない。

以下の処理フローにおいて、ユーザー（発行要求者）の認証情報、およびクライアント作成の権限情報については予め定義され、記憶部に保持されているものとする。

図１２Ａは、アクセス管理サービスシステム１０４における、シングルテナントクライアントの発行処理のフローチャートである。本処理フローは、アクセス管理サービスシステム１０４のＣＰＵ２０３が、二次記憶装置２０６に記憶された本実施形態に係るプログラムをＲＡＭ２０５に読み出して実行することで実現される。

Ｓ１２０１において、アクセス管理サービスシステム１０４は、ユーザーからシングルテナントクライアントの発行要求を受け付ける。Ｓ１２０２において、アクセス管理サービスシステム１０４は、ユーザーに認証情報の入力を要求する。そして、アクセス管理サービスシステム１０４は、入力された情報に基づいて、ユーザーの認証を行う。

ユーザーの認証に成功した後、Ｓ１２０３において、アクセス管理サービスシステム１０４は、ユーザーの権限を確認する。ユーザーがテナントクライアント作成権限を持つ場合（Ｓ１２０３にてＹＥＳ）、Ｓ１２０５に進む。ユーザーがテナントクライアント作成権限を持たない場合（Ｓ１２０３にてＮＯ）、Ｓ１２０４へと進み、アクセス管理サービスシステム１０４は、Ｓ１２０１の応答としてエラー画面を返す。そして、本処理フローを終了する。

Ｓ１２０５において、アクセス管理サービスシステム１０４は、認証したユーザーに対応する所属グループとしてテナントＩＤをユーザーテーブル７００から取得する。その後、Ｓ１２０６において、アクセス管理サービスシステム１０４は、取得したグループに所属するシングルテナントクライアントを、認証したユーザーの権限に基づいて作成し、ユーザーテーブル７００に登録する。ここで登録するシングルテナントクライアントは、ユーザー種別が「シングルテナントクライアント」となり、テナントＩＤがユーザーと同じテナントＩＤとなる。以上により、本処理フローを終了する。

図１２Ｂは、アクセス管理サービスシステム１０４における、マルチテナントクライアントの発行処理のフローチャートである。本処理フローは、アクセス管理サービスシステム１０４のＣＰＵ２０３が、二次記憶装置２０６に記憶された本実施形態に係るプログラムをＲＡＭ２０５に読み出して実行することで実現される。

Ｓ１２１１において、アクセス管理サービスシステム１０４は、ユーザーからマルチテナントクライアントの発行要求を受け付ける。Ｓ１２１２において、アクセス管理サービスシステム１０４は、ユーザーにクライアント証明書の要求を行う。ここで要求するクライアント証明書は、アクセス管理サービスシステム１０４が発行し、信頼できる外部サービスシステムに対して本システム外で配布したものであるとする。なお、配布方法については、特に限定するものではない。また、Ｓ１２１２の前に、Ｓ１２０２と同様にユーザーにアクセス管理サービスシステム１０４への認証情報の入力を要求してもよい。

ユーザーからクライアント証明書を受け付けた後、Ｓ１２１３において、アクセス管理サービスシステム１０４は、クライアント証明書の正当性の検証を行う。クライアント証明書の検証は予め登録されていたクライアント証明書と比較することにより検証を行う。なお、クライアント証明書の登録方法については、図１３を用いて後述する。クライアント証明書の検証により有効であると判断した場合（Ｓ１２１３にてＹＥＳ）、Ｓ１２１５に進む。クライアント証明書の検証により無効であると判断した場合（Ｓ１２１３にてＮＯ）、Ｓ１２１４へと進み、アクセス管理サービスシステム１０４は、Ｓ１２１１の応答としてエラー画面をユーザーへ返し、処理を終了する。

Ｓ１２１５において、アクセス管理サービスシステム１０４は、証明書管理テーブル９００から作成するマルチテナントクライアントの情報を取得する。本実施形態において、マルチテナントクライアントは、認可を受ければ複数のグループの情報にアクセスできるクライアントであるため、特別なグループに所属するクライアントとして作成する。ＤＮ９０３には、そのクライアント証明書を持つ外部サービスシステムをマルチテナントクライアントとして登録するグループの情報が含まれている。予め作成されるクライアント証明書とグループの対応関係の作成については、図１３を用いて後述する。アクセス管理サービスシステム１０４は、検証されたクライアント証明書のＤＮ９０３を取得し、マルチテナントクライアントを作成するグループを特定する。

Ｓ１２０６において、アクセス管理サービスシステム１０４は、ＤＮ９０３の情報を元に、マルチテナントクライアント作成権限を持つユーザーの認証を行う。その後、アクセス管理サービスシステム１０４は、認証したユーザーの権限で、特定したグループにマルチテナントクライアントを作成し、ユーザーテーブル７００に登録する。ここで登録するマルチテナントクライアントは、ユーザー種別が「マルチテナントクライアント」となり、テナントＩＤがＤＮ９０３から特定したテナントＩＤとなる。以上により、本処理フローを終了する。

（クライアント証明書の登録）
図１３は、マルチテナントクライアントの作成を許可するためのクライアント証明書を、アクセス管理サービスシステム１０４へと登録するフローを示した図である。本処理フローは、アクセス管理サービスシステム１０４のＣＰＵ２０３が、二次記憶装置２０６に記憶された本実施形態に係るプログラムをＲＡＭ２０５に読み出して実行することで実現される。

Ｓ１３０１において、アクセス管理サービスシステム１０４は、クライアント証明書の登録要求を受ける。その際、アクセス管理サービスシステム１０４は、システム外で作成されたクライアント証明書を受け取る。

Ｓ１３０２において、アクセス管理サービスシステム１０４は、マルチテナントクライアントを登録するためのアカウントと、マルチテナントクライアント用の特別グループを新規に作成する。作成したアカウントはユーザーテーブル７００に登録される。

Ｓ１３０３において、アクセス管理サービスシステム１０４は、クライアント証明書を証明書管理テーブル９００に登録する。ここで、シリアル番号９０１とｓｕｂｊｅｃｔ９０２には、受け付けたクライアント証明書に対応付けられた値が登録される。また、ＤＮ９０３には、Ｓ１３０２で作成したアカウントとクライアントの情報に対応付けられた値が登録される。以上により、本処理フローを終了する。

本実施形態により、認可処理の際に認可確認画面をユーザーに表示する前に、アクセス管理サービスシステム１０４が権限委譲先の外部サービスのアクセス可能範囲を判定することで、不正な権限委譲と、無駄な権限委譲を防ぐ事ができる。これにより、特定のデータにしかアクセスできない外部サービスを管理することができる。更には、外部サービス側でのアクセスの管理が不要となり、負担を抑えることができる。

また、アクセスできる情報が制限されていない権限の強いテナントは自由には発行出来ず、許可されたサービスのみが発行できるように制限される。一方、アクセスできる情報が制限されている権限の弱いサービスは、各サービスで作成権限を持つアカウントであれば自由に発行できる。したがって、システムにおける利便性を維持しつつ、セキュリティの維持も可能となる。

＜実施形態２＞
次に、アクセス管理サービスシステム１０４に外部サービスを登録する際の第２の実施形態について図面を用いて説明する。

（クライアント登録画面）
図１４は、アクセス管理サービスシステム１０４が生成するクライアント登録画面１４００を示した図である。クライアント登録画面１４００は、入力部としてサービス名入力部１４０１、リダイレクトＵＲＬ入力部１４０２を備える。また、クライアント登録画面１４００は、クライアント選択部１４０３、１４０４、登録ボタン１４０５、および登録キャンセルボタン１４０６を備える。

サービス名入力部１４０１は、クライアントテーブル７１０のクライアント名７１２に登録するクライアント名を入力するフォームである。リダイレクトＵＲＬ入力部１４０２は、クライアントテーブル７１０のリダイレクトＵＲＬ７１３に登録するＵＲＬを入力するフォームである。

クライアント選択部１４０３、１４０４は、いずれか１つが選択できるラジオボタンであり、用途に合わせたアクセス範囲を選択する。ここで選択されたアクセス範囲に対応してシステム内ではクライアントが作成される。クライアント選択部１４０３が選択された場合には、シングルテナントクライアントが作成され、クライアント選択部１４０４が選択された場合には、マルチテナントクライアントが作成されることとなる。なお、これら選択部はボタン形式ではなく、ドロップダウンによる選択形式などでもよい。

登録ボタン１４０５は、クライアント登録を要求する際にユーザーによって押下されるボタンである。登録キャンセルボタン１４０６は、ユーザーが登録を拒否する場合に押下されるボタンである。

（処理フロー）
図１５は、アクセス管理サービスシステム１０４に外部サービスシステム１０３を登録する際の処理フローを示した図である。なお、図１２Ａ、Ｂと同じ処理については、同じ参照番号を付与しているものとする。本処理フローは、アクセス管理サービスシステム１０４のＣＰＵ２０３が、二次記憶装置２０６に記憶された本実施形態に係るプログラムをＲＡＭ２０５に読み出して実行することで実現される。

Ｓ１５０１において、アクセス管理サービスシステム１０４は、クライアント登録画面１４００へのアクセスを受け付ける。Ｓ１５０２において、アクセス管理サービスシステム１０４は、ユーザーに認証情報の入力を要求する。ユーザーの認証に成功した後、Ｓ１５０３において、アクセス管理サービスシステム１０４は、クライアント登録画面１４００を表示し、ユーザーに対し登録する外部サービスの情報の入力を要求する。

Ｓ１５０４において、アクセス管理サービスシステム１０４は、登録要求されたアクセス範囲（作成するクライアント）を判定する。アクセス範囲に対応してシングルテナントクライアント作成が要求された場合（Ｓ１５０４にてＮＯ）、Ｓ１２０３へと進み、以降は図１２Ａと同様のフローとなる。アクセス範囲に対応してマルチテナントクライアント作成が要求された場合（Ｓ１５０４にてＹＥＳ）、Ｓ１２１２へと進み、以降は図１２Ｂと同様のフローとなる。

実施形態２により、実施例１の効果に加え、ユーザーはマルチテナントクライアントとシングルテナントクライアントを意識せずに、用途に合わせたアクセス範囲を選択してクライアントを作成する事ができる。

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

Claims (10)

1. サービスを提供するリソースサービスシステムと、前記サービスの利用を管理するアクセス管理サービスシステムとを含むシステムであって、
   前記アクセス管理サービスシステムは、
   ユーザーの情報およびクライアントシステムの情報を記憶部に保持する保持手段と、
   前記サービスを利用する権限を有するユーザーからの指示に起因して前記クライアントシステムから当該サービスに対する利用の認可要求を受け付けた場合、前記記憶部にて保持する情報に基づいて、前記ユーザーが所属するグループと前記クライアントシステムが所属するグループとが一致するか否かを判定する判定手段と、
   前記判定手段によりグループが一致すると判定された場合、前記ユーザーの権限を前記クライアントシステムに委譲することを許可するか否かを指示するための画面を前記ユーザーに提示する提示手段と
   を有し、
   前記リソースサービスシステムは、前記画面を介してユーザーの権限の委譲を許可することが指示されたことに応じて発行されるアクセス制御情報を前記クライアントシステムから受信した場合、前記アクセス制御情報の正当性が確認されたことに応じてサービスを提供する提供手段と
   を有することを特徴とするシステム。
2. 前記アクセス管理サービスシステムは、前記提示手段が提示した画面を介して、ユーザーの権限の委譲を許可することが指示されたことに応じて前記アクセス制御情報を発行する発行手段を更に有することを特徴とする請求項１に記載のシステム。
3. 前記アクセス管理サービスシステムは、クライアントシステムに第１の権限または第２の権限のいずれかを付与して前記保持手段に登録させる登録手段を更に有し、
   前記第１の権限は、全てのリソースサービスシステムが提供するサービスを利用する権限を委譲されることが可能な権限であり、
   前記第２の権限は、予め定義されたリソースサービスシステムが提供するサービスを利用する権限を委譲されることが可能な権限である
   ことを特徴とする請求項１または２に記載のシステム。
4. 前記認可要求を行ったクライアントシステムが前記第１の権限を付与されているか否かを判定する手段を更に有し、
   前記クライアントシステムが前記第１の権限を付与されている場合、前記提示手段は、所属するグループが一致するか否かに関わらず前記画面を前記ユーザーに提示することを特徴とする請求項３に記載のシステム。
5. 前記登録手段は、前記第１の権限を付与するようにクライアントシステムの登録を要求された場合、前記アクセス管理サービスシステムが発行したクライアント証明書を要求し、当該クライアント証明書の正当性が確認できたことに応じて当該クライアントシステムの登録を行うことを特徴とする請求項３または４に記載のシステム。
6. 前記登録手段は、前記第２の権限を付与するようにクライアントシステムの登録を要求された場合、当該登録の要求を行ったユーザーの権限の情報を取得し、当該ユーザーが登録に対する権限を有する場合に当該クライアントシステムの登録を行うことを特徴とする請求項３乃至５のいずれか一項に記載のシステム。
7. サービスを提供するリソースサービスシステムと、前記サービスの利用を管理するアクセス管理サービスシステムとを含むシステムの制御方法であって、
   前記アクセス管理サービスシステムにおいて、
   ユーザーの情報およびクライアントシステムの情報を記憶部に保持する保持工程と、
   前記サービスを利用する権限を有するユーザーからの指示に起因して前記クライアントシステムから当該サービスに対する利用の認可要求を受け付けた場合、前記記憶部にて保持する情報に基づいて、前記ユーザーが所属するグループと前記クライアントシステムが所属するグループとが一致するか否かを判定する判定工程と、
   前記判定工程によりグループが一致すると判定された場合、前記ユーザーの権限を前記クライアントシステムに委譲することを許可するか否かを指示するための画面を前記ユーザーに提示する提示工程と
   を有し、
   前記リソースサービスシステムにおいて、前記画面を介してユーザーの権限の委譲を許可することが指示されたことに応じて発行されるアクセス制御情報を前記クライアントシステムから受信した場合、前記アクセス制御情報の正当性が確認されたことに応じてサービスを提供する提供工程と
   を有することを特徴とする制御方法。
8. リソースサービスシステムが提供するサービスの利用を管理するアクセス管理サービスシステムであって、
   ユーザーの情報およびクライアントシステムの情報を記憶部に保持する保持手段と、
   前記サービスを利用する権限を有するユーザーからの指示に起因して前記クライアントシステムから当該サービスに対する利用の認可要求を受け付けた場合、前記保持手段にて保持する情報に基づいて、前記ユーザーが所属するグループと前記クライアントシステムが所属するグループとが一致するか否かを判定する判定手段と、
   前記判定手段によりグループが一致すると判定された場合、前記ユーザーの権限を前記クライアントシステムに委譲することを許可するか否かを指示するための画面を前記ユーザーに提示する提示手段と
   を有することを特徴とするアクセス管理サービスシステム。
9. リソースサービスシステムが提供するサービスの利用を管理するアクセス管理サービスシステムの制御方法であって、
   ユーザーの情報およびクライアントシステムの情報を記憶部に保持する保持工程と、
   前記サービスを利用する権限を有するユーザーからの指示に起因して前記クライアントシステムから当該サービスに対する利用の認可要求を受け付けた場合、前記記憶部にて保持する情報に基づいて、前記ユーザーが所属するグループと前記クライアントシステムが所属するグループとが一致するか否かを判定する判定工程と、
   前記判定工程によりグループが一致すると判定された場合、前記ユーザーの権限を前記クライアントシステムに委譲することを許可するか否かを指示するための画面を前記ユーザーに提示する提示工程と
   を有することを特徴とする制御方法。
10. コンピューターを、
    ユーザーの情報およびクライアントシステムの情報を記憶部に保持する保持手段、
    リソースサービスシステムが提供するサービスを利用する権限を有するユーザーからの指示に起因して前記クライアントシステムから当該サービスに対する利用の認可要求を受け付けた場合、前記記憶部にて保持する情報に基づいて、前記ユーザーが所属するグループと前記クライアントシステムが所属するグループとが一致するか否かを判定する判定手段、
    前記判定手段によりグループが一致すると判定された場合、前記ユーザーの権限を前記クライアントシステムに委譲することを許可するか否かを指示するための画面を前記ユーザーに提示する提示手段
    として機能させるためのプログラム。

Images