JP6041537B2 - システムおよび制御方法およびプログラム - Google Patents

Description

本発明はマルチテナント対応したサービス間でシングルサインオンを実現するための、シングルサインオンマッピングの設定方法に関する。

従来、異なるドメイン下に存在する複数のサーバー間でユーザー認証を連携させる技術として、Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（以下ＳＡＭＬ）によるシングルサインオン （以下ＳＳＯ） の仕組みが知られている。ＳＡＭＬを実現するシステムは、認証機能を提供するサーバー群（Ｉｄｅｎｔｉｔｙ Ｐｒｏｖｉｄｅｒ、以下 ＩｄＰ）を含む。またＳＡＭＬを実現するシステムは、ＩｄＰの認証結果を信頼して機能を提供する少なくとも一つ以上のサーバーで構成されるサーバー群（Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ、以下 ＳＰ）も含む。ＳＡＭＬによるＳＳＯを利用するユーザーは、前述のＩｄＰとＳＰのそれぞれのドメインにおけるユーザーＩＤ等の認証情報を登録している。

例えばユーザーは、ＩｄＰにて管理されているユーザーＩＤ、およびパスワードと言ったユーザー認証情報を基にＩＤプロバイダで認証される。

ユーザーがＳＰの機能提供を受ける場合、ＩｄＰにアクセスし認証を受ける必要がある。例えば、ユーザーはＩｄＰにて管理されているユーザーＩＤ、およびパスワードを使ってＩｄＰで認証される。そしてＩｄＰは、認証したユーザーに対し、認証したことの証明であるＳＡＭＬアサーションをＳＰ向けに発行する。ＳＰは、このＳＡＭＬアサーションが信頼しているＩｄＰで発行されたものかを検証する事でユーザーを認証する。このとき、ユーザーはＳＰで管理されている認証情報を入力することなく、ＳＰと連携するサーバー群が提供するサービスを受けることができる。

上述のように、ＳＡＭＬのＳＳＯは、ＩｄＰとＳＰの信頼関係によって成り立っている。そのため、ＳＳＯを実現する前に、事前にＩＤプロバイダとサービスプロバイダ間で信頼関係を結んでいる必要がある。この信頼関係は、ＳＡＭＬにおける複数の機能の内どの機能によってＳＳＯを行うのかを記述したメタデータと、アサーションがＩＤプロバイダから発行された事を証明するための電子証明書の交換によって成立する。メタデータの具体的な内容、およびこの信頼関係の結び方に関する技術は標準技術であるＳＡＭＬ Ｖ２．０において定義されている。メタデータ、および電子証明書のようにアサーションの検証を行うために必要な情報を事前情報と称する。サービスプロバイダは、アサーションが要件を満たすか否かを検証する際、事前情報を利用して検証を行う。また、事前情報は、一般的にＩＤプロバイダにより発行されるデータである。

なおユーザーがＳＰにＳＳＯでアクセスする際は、前述のように自身のＳＰ用のＩＤをＳＰに渡していない。具体的には、ユーザーがまずＳＰにアクセスすることで、そのアクセスはＩｄＰへリダイレクトされる。そして、ＩｄＰにログインすることで発行されるＳＡＭＬアサーションを使ってＳＰにアクセスする。ここで、ＳＡＭＬアサーションに含まれるＩｄＰ用のＩＤあるいはＩｄＰ用のＩＤ相当の情報を使ってＳＰにアクセスする際のＳＰ用のＩＤを特定する。このＳＡＭＬアサーションに含まれるＩｄＰ用のＩＤあるいはＩｄＰ用のＩＤ相当の情報からＳＰ用のＩＤを特定するためには、ＩｄＰ用のＩＤあるいはＩｄＰ用のＩＤ相当の情報と、ＳＰ用のＩＤの対応関係を示すマッピングテーブルが必要となる。なお、このマッピングテーブルを作ることをシングルサインオンマッピング（以下、ＳＳＯマッピング）と呼ぶ。ＳＳＯ を実現するためには、適切なマッピングテーブルをＳＳＯマッピングにより生成しておく必要がある。

また、ＳＳＯの技術として特許文献１には、ＳＰのＩＤをあらかじめ作成してユーザーに割り当てないまま保管しておく。そして、ＩｄＰにＩＤとパスワードを渡して認証に成功すると、前述のＳＰのアカウントをＩｄＰのＩＤに割り当てるＳＳＯマッピングサーバーが記載されている。この方式では、ＩｄＰでユーザーの正当性が確認できた場合にＳＳＯマッピングを実現している。

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

しかしながら従来の方法には以下の問題があった。すなわち、従来は一度ＳＳＯマッピングが行われた後にユーザーＩＤが削除され、かつ、同じユーザーＩＤが登録された場合を考慮していなかった。

上記課題を解決するために、本願発明は、複数のユーザー情報を管理するシステムであって、ユーザー情報を他システムから受信する受信手段と、受信された前記ユーザー情報と前記複数のユーザー情報においてユニークな識別情報とを対応づけたテーブルを生成し、生成された前記テーブルを前記他システムへ送信する送信手段と、生成された前記テーブルをＳＳＯマッピング設定する設定手段と、を有し、前記他システムにおいて、前記送信手段により送信された前記テーブルを基に前記他システムのユーザー情報と前記ユニークな識別情報とを対応づけたテーブルが生成され前記テーブルがＳＳＯマッピング設定され、前記システムおよび前記他システムのＳＳＯマッピング設定に従い、前記システムおよび前記他システム間のシングルサインオンが実現されることを特徴とする。

本発明によれば、一度ＳＳＯマッピングが行われた後にユーザーＩＤが削除され、かつ、同じユーザーＩＤが登録された場合にも適切なアクセスを実現可能とする

ネットワーク構成を示す図である。 本発明の実施の形態に係るＰＣの構成図である。 ＳＳＯマッピング設定を利用した一般的なＳＳＯのログインフローである。 本発明の実施の形態に係るモジュール構成図である。 本発明の実施の形態に係るテナント別ユーザーリストデータ例である。 本発明の実施の形態に係る第１および第２のＩＤリストとＳＳＯマッピング設定情報の例である。 本発明の実施の形態に係るＳＳＯマッピングの設定フローである。 本発明の実施の形態に係るＳＳＯマッピングの設定状況を示した図である。 本発明の実施の形態に係るＳＳＯマッピング設定用の画面例である。 ＩｄＰの自動登録を実現するための対応関係を示した図である。 ＩｄＰの自動登録を実現するためのフローである。

本発明の目的は、認証を連携させたいサービス間で、適切なＩＤ同士でＳＳＯマッピング設定を行うことである。なお、本願におけるシングルサインオンは、他システムでユーザー認証が成功することでシステムでのユーザー認証を行うことなくシステムの機能が提供可能となることを指す。

まず、図８（Ａ）−（Ｂ）を使って現状の実施形態、現状の課題を説明し、図８（Ｃ）−（Ｄ）を使って現状の課題が解決されることを、具体例を挙げて説明する。

図８（Ａ）は、現状のＳＳＯマッピング設定状況を示した図である。

ＳＳＯマッピング対象サービスであるサービスＢ４００（ＩｄＰ）には、テナントＡとテナントＣがあり、テナントＡにはユーザーＩＤとしてＩｄＰ Ｕｓｅｒ１−３が含まれる。またテナントＣにはユーザーＩＤとしてＩｄＰ Ｕｓｅｒ４が含まれている。

ＳＳＯマッピングサービスであるサービスＡ３００（ＳＰ）には、テナントＢとテナントＤがあり、テナントＢにはユーザーＩＤとしてＳＰ Ｕｓｅｒ１−３が含まれている。またテナントＤにはユーザーＩＤが含まれていない。

ここで本願の処理を用いることなく、図８（Ａ）の状況から、ＳＳＯマッピングサービスＡ３００のテナントＩＤ ＢのＳＰ Ｕｓｅｒ１を削除し、テナントＩＤ Ｄに同名のユーザーＳＰ Ｕｓｅｒ１を作成した状況を図８（Ｂ）に示す。

図８（Ｂ）の状況では、ＩｄＰ Ｕｓｅｒ１がテナントＩＤ ＤへとＳＳＯできる状況となっている。つまり、図８（Ａ）では、ＩｄＰ Ｕｓｅｒ１はテナントＩＤ Ｂを使うことが規定されていたにも関わらず、当初の規定とは異なるテナントへＳＳＯでアクセスが実行されてしまう問題が発生する。

つづいて、 図８（Ｃ）−（Ｄ）を用いて、上述した課題がＡＵＩＤを用いることで解消されることを説明する。

図８（Ｃ）は、本発明の実施例の形態に係るＳＳＯマッピングの設定状況を示した図である。

ＳＳＯマッピング対象サービスであるサービスＢ４００（ＩｄＰ）には、テナントＡとテナントＣがあり、テナントＡにはユーザーＩＤとしてＩｄＰ Ｕｓｅｒ１−Ｕｓｅｒ３が含まれている。またテナントＣにはユーザーＩＤとしてＩｄＰ Ｕｓｅｒ４が含まれている。

ＳＳＯマッピングサービスであるサービスＡ３００（ＳＰ）には、テナントＢとテナントＤがあり、テナントＢにはユーザーＩＤとしてＳＰ Ｕｓｅｒ１−３が含まれている。またテナントＤにはユーザーＩＤが含まれていない。

ここで図７のフローを実施することで、ＩｄＰ Ｕｓｅｒ１とＳＰ Ｕｓｅｒ１の間でＳＳＯマッピング設定が実行される。またＩｄＰ Ｕｓｅｒ２とＳＰ Ｕｓｅｒ２の間でも、ＩｄＰ Ｕｓｅｒ３とＳＰ Ｕｓｅｒ３の間でもＳＳＯマッピング設定が実行される。これらのマッピングは、第４のＩＤテーブルと第５のＩＤテーブルが、それぞれＡＵＩＤマッピングテーブル８０１、およびＡＵＩＤマッピングテーブル８０２に設定されていることから、適切なＳＳＯマッピング設定が行われたこととなる。

図８（Ｄ）は、図８（Ｃ）の状況が変化した場合の、本発明の実施例に係るＳＳＯマッピングの設定状況を示した図である。

図８（Ｃ）の状況から、ＳＳＯマッピングサービスＡ３００のテナントＩＤ ＢのＳＰ Ｕｓｅｒ１を削除し、テナントＩＤ Ｄに同名のユーザーＳＰ Ｕｓｅｒ１を作成する。つまり、図８（Ｂ）と同じ操作が行われたことを示している。

本実施例の場合、ユーザーＩＤ削除に伴いマッピング状態も削除されるので、ＳＳＯマッピングサービスＡ３００のＡＵＩＤマッピングテーブル８０１から、ＳＰ Ｕｓｅｒ１とＡＵＩＤ１は削除される。このため、例え同名のユーザーＳＰ Ｕｓｅｒ１がテナントＩＤ Ｄに再作成されたとしても、ＳＳＯマッピング８０６のような関係は存在し得ない。つまり、図８（Ａ）−（Ｂ）において説明した課題の発生を防ぐことができる。従って、図７で示したようなフローでＳＳＯマッピングを設定した場合、ＳＳＯマッピングサービスＡ３００がユーザーＩＤを削除する。そして、同名のユーザーＩＤを別テナントへ再作成するような、ＳＳＯマッピング対象サービスＢ側が意識しない操作を実行しても、意図しないＳＳＯがされることを防止できる。

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

本実施の形態に係る権限委譲システムは、図１に示すような構成のネットワーク上に実現される。

１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１０１）である。

２００はユーザーが操作するクライアントＰＣであり、３００および４００はユーザー認証するとサービス（機能）を提供するサービスＡおよびサービスＢである。なお、サービスＡやサービスＢにより提供されるサービス（機能）は、例えば印刷機能や、帳票機能がある。帳票機能とは、ＳＰがテンプレートを保持しておき、ＩｄＰから受信したコンテンツデータとＳＰが保持するテンプレートを使ってオーバーレイ処理を実行して、帳票を作成する機能である。

またクライアントＰＣ２００、サービスＡ３００、サービスＢ４００はそれぞれＷＡＮネットワーク１００およびＬＡＮ１０１を介して接続されている。なおクライアントＰＣ２００およびそれぞれのサービスはそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また同一のＰＣ上に構成されていてもよい。サービスＡ３００、サービスＢ４００は、夫々、サーバー群Ａ３００、サーバー群Ｂ４００で動作する。サーバー群Ａおよびサーバー群Ｂは、認証サーバーとサービスを提供するサーバーで構成される。サーバー群ＡおよびＢは、例えば認証サーバーとサービスを提供するサーバーで構成される。認証サーバーおよびサービスを提供するサーバーは、１台で構成されても良いし複数台で構成されても良い。なお、本願では、サーバー群ＡをＳＰと称し、サーバー群ＢをＩｄＰと称して説明するが、逆であっても良い。 サービスＢ４００は、まずユーザーのログインを受け付ける。次にサービスＢ４００はユーザーからＳＳＯマッピング設定要求を受け付けると、第１のＩＤテーブルを生成する。なお、ＳＳＯマッピング設定要求は、後述の図９においてユーザーにより設定ボタンが押されることで発行される。

第１のＩＤテーブルは、ＳＳＯマッピング対象となるサービスＡ３００のユーザーＩＤと、サービスＡ３００のユーザーＩＤの各々に対応するサービスＢ４００のユーザーＩＤのタプル（ｔｕｐｌｅ）のリストから構成される。なお、サービスＢ４００（ＩｄＰ）を利用するユーザーがサービスＡ３００（ＳＰ）のサービスを使うことを要求した段階で、サービスＢ４００（ＩｄＰ）は、サービスＡ３００のユーザーＩＤを取得できる。これは、一例であり、第１のＩＤテーブルを作る前にＳＰのユーザーＩＤが取得できていれば良い。

なお、第１のＩＤテーブルの一例は、後述の図５のＢ−２である。さらにサービスＢ４００は、ＳＳＯマッピング設定要求として第２のＩＤリストを生成する。第２のＩＤリストは、第１のＩＤテーブルのうち、ＳＳＯマッピング設定要求対象となるサービスＡ３００のユーザーＩＤリストから構成される。なお、第２のＩＤリストの一例は、後述の図５のＢ−３である。サービスＢ４００は、第２のＩＤリストと、サービスＡ３００のＳＳＯマッピング実行者情報と、サービスＡ３００におけるサービスＢ４００のエンティティ情報など、ＳＳＯマッピングに必要な情報をサービスＡ３００に送信する。なお、サービスＡ３００のＳＳＯマッピング実行者情報は、後述する図９のＳＰのユーザーＩＤで指定された情報である。

ここでエンティティ情報とは、ＳＡＭＬプロトコルで定義されるもので、ＳＰから見た場合、ＩｄＰは、エンティティＩＤと呼ばれるＩＤで識別される。このエンティティＩＤは事前に交換したメタデータに記載されている。ここでＩｄＰによっては、認証機能を提供するサーバー群として単一のエンティティＩＤしか持たないシステムと、複数のエンティティＩＤを持てるシステムとがある。 サービスＢ４００は、ＩｄＰとして単一のエンティティＩＤを持ち、エンティティＩＤの取得手段からエンティティ情報としてエンティティＩＤを取得可能とする。もちろんサービスＢが複数のエンティティＩＤを持っていても良い。

一方、サービスＡ３００は、サービスＢ４００からのＳＳＯマッピング設定要求対象となるサービスＡ３００のユーザーＩＤリストである第２のＩＤリストを受け取る。この際、サービスＡ３００は、第２のＩＤリストと共にサービスＡ３００のＳＳＯマッピング実行者情報と、サービスＡ３００におけるサービスＢ４００のエンティティ情報も受け取る。サービスＡ３００は、受け取った情報のうち、サービスＢ４００のエンティティ情報から登録エンティティであることを確認し、サービスＡ３００のＳＳＯマッピング実行者情報からＳＳＯマッピング実行者を判定し、ＳＳＯマッピング実行者の取得可能な第３のユーザーＩＤリストを取得する。サービスＡ３００は、取得した第２のＩＤリストの各々のユーザーが、第３のユーザーＩＤリストに含まれることを確認する。サービスＡ３００は、第２のＩＤリストの各々のユーザーに対応するＡＵＩＤ（Ａｃｃｏｕｎｔ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）リストを動的に生成する。ＡＵＩＤは、ユニークな汎用一意識別子（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ、ＵＵＩＤ）である。サービスＡ３００は、第４のＩＤテーブルを生成する。第４のＩＤテーブルは、第２のＩＤリストと、第２のＩＤリストの各々のユーザーＩＤに対応するＡＵＩＤのタプルのリストから構成される。サービスＡ３００は、サービスＢ４００のＳＳＯマッピング設定要求への応答として、第４のＩＤテーブルを返送する。サービスＡ３００は、第４のＩＤテーブルを用いてＳＳＯマッピングを行う。

サービスＢ４００は、サービスＡ３００から送信された第４のＩＤテーブルを受信する。サービスＢ４００は、受信した第４のＩＤテーブルと、保存していた第１のＩＤテーブルを比較し、第５のＩＤテーブルを生成する。第５のＩＤテーブルは、ＳＳＯマッピング設定要求でサービスＡ３００に送信した第２のＩＤリストの各々のＩＤと対応するＡＵＩＤのタプルのリストから構成される。サービスＡ３００は、第５のＩＤテーブルを用いてＳＳＯマッピングを行う。

サービスＡ３００、サービスＢ４００はそれぞれ、後述のサーバーコンピューター上で動作する。

ここで、ＩｄＰとＳＰの関係について記載する。

たとえばＳＡＭＬはＨＴＴＰで実現されるため、エンドポイントはＵＲＬで定義される。エンドポイントは、ＩｄＰのアドレスを指す。またアサーションを署名するためにＥｎｔｉｔｙ ＩＤごとに異なる電子証明書が必要となるが、電子証明書はホスト名に紐づけて発行される。結果として、ＩｄＰが複数のＥｎｔｉｔｙ ＩＤを持つためにはＥｎｔｉｔｙ ＩＤごとに異なるホスト名も持つ。なお、それらのホスト名は、ホスト名解決が可能であり、ホスト名解決の結果、ＩＰアドレスと対応づいている必要がある。ＩｄＰがユーザーの求めに応じ動的にＥｎｔｉｔｙ ＩＤを追加するのであれば、ＩｄＰがＤＮＳサーバーを備え、Ｅｎｔｉｔｙ ＩＤの追加に対応して新しいホスト名とＩＰアドレスをＤＮＳサーバーに登録するなどの作業が必要になる。よってＩｄＰが複数のＥｎｔｉｔｙ ＩＤを持つには比較的規模の大きなＩｄＰでないと対応が難しい。

一方アプリケーションサービスプロバイダーなど第三者にサービスを提供するケースでは、第三者からのアクセスを特定のＵＲＬに限定することで利便性を向上させることがある。このような場合は、ＵＲＬが単一になり、Ｅｎｔｉｔｙ ＩＤが単一になる。

上記のようにＥｎｔｉｔｙ ＩＤが単一か複数かは、ＩｄＰの構成によって異なる。本実施例の場合、ＩｄＰが単一のエンティティＩＤしか持たないものを考える。

図２は本実施の形態に係るクライアントＰＣ２００の構成を示す図である。またサービスＡ３００、サービスＢ４００を提供するサーバーコンピューターの構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のクライアントＰＣ２００およびサーバーコンピューターには一般的な情報処理装置のハードウェア構成を適用できる。

図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク（ＨＤ）２１１やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＮＣ２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。

尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はハードディスク（ＨＤ）２１１にインストールされたアプリケーションプログラムである。例えば、本願のフローチャートの各ステップは、ＣＰＵがフローチャートに関連するプログラムを読み出して実行することにより実現される。

図３はＳＳＯマッピング設定を利用した一般的なＳＳＯのログインフローである。以下に、サービスＢ４００がＩｄＰとして、サービスＡ３００がＳＰとして動作する例を示す。なおサービスＡ３００がＩｄＰ、サービスＢ４００がＳＰであってもよい。

サービスＢ４００がＩｄＰの場合、ユーザーは、サービスＢ４００でユーザー認証を受ければ、サービスＡ３００が提供するサービスを受けることが可能となる。

以下の例では、ユーザーがまずサービスＢ４００でユーザー認証を受け、そののちにＳＳＯによってサービスＡ３００のサービスを受ける場合のフローを説明する。なおユーザーがサービスＡ３００にアクセスしたあとサービスＢ４００にリダイレクトされ、サービスＢ４００でユーザー認証を受けたあとでサービスＡ３００のサービスを受けるフローであってもよい。

図３（Ａ）はＳＳＯのログインフローの、ＩｄＰ側におけるフローである。なおここではサービスＢ４００がＩｄＰとしている。

ステップＳ１でサービスＢ４００は、サービスＡ３００のサービスを受けることを望むユーザーからのユーザー認証要求を受け付ける。ここでサービスＢ４００はユーザーからサービスＢで認証を受けるためのサービスＢのＩＤとパスワードを受け付ける。

ステップＳ２でサービスＢ４００は、ステップＳ１でユーザーから受け付けたサービスＢのＩＤとパスワードの組み合わせが正しいか確認する（ユーザー認証を実行する）。サービスＢ４００は、適切なＩＤとパスワードの組み合わせを保持しており、Ｓ１にて受信した組み合わせが適切な組み合わせとして保存されているか否かによりＳ１の処理が実現される。組み合わせが正しければステップＳ３に遷移する。また組み合わせが正しくなければフローを終了する。

ステップＳ３でサービスＢ４００は、ユーザー認証を実行し、ユーザーからのアクセスをサービスＡ３００にリダイレクトする。またその際、リダイレクトされたアクセスと共にサービスＢ４００がユーザー認証したユーザーのＩＤ（またはサービスＢがユーザー認証したＩＤ相当の情報）が送信される。サービスＢ４００によるリダイレクトが済むとフローを終了する。なお、Ｓ２でＩＤとパスワードのペアが正しいと判断されてから、ＩｄＰ側のＵＩを使ってユーザーがＳＰのサービスを使用することを選択することでＳ３の処理が実行される。

図３（Ｂ）は一般的なＳＳＯのログインフローのＳＰ側でのフローである。なおここではサービスＡ３００がＳＰとしている。

ステップＳ４でサービスＡ３００は、サービスＢ４００からリダイレクトされたユーザーのアクセスを受け付ける。

ステップＳ５でサービスＡ３００は、サービスＢでユーザー認証を受けたユーザーのＩＤを取り出す。

ステップＳ６でサービスＡ３００は、ステップＳ５で取り出したユーザーのＩＤに関するＳＳＯマッピングにより生成されたマッピングテーブルを取り出す。

ステップＳ７でサービスＡ３００は、ステップＳ６でＳＳＯマッピング設定が見つかったか判断する。見つかっていればステップＳ８に遷移し、見つかっていなければフローを終了する。

ステップＳ８でサービスＡ３００は、ステップＳ６で見つかったＳＳＯマッピング設定で示されるサービスＡのＩＤを使ってユーザー認証を実行する。そしてステップＳ４で受け付けたアクセスを許可し、サービスを提供し、フローを終了する。

前述のように、ＳＳＯマッピングが設定されていると、ユーザーは、サービスＢ４００のみに対してサービスＢ４００のＩＤとパスワードを渡すことで、サービスＡ３００が提供するサービスを受けることができる。

図４は本発明の実施の形態に係るモジュール構成図である。なおここではサービスＡ３００がＳＳＯマッピングサービスであり、サービスＢ４００がＳＳＯマッピング対象サービスであるとしているが、サービスの対応関係は前述の関係に限定されるものではない。なお、上述の通り、図４に記載の各モジュールはＨＤＤに保存されており、メモリにロードされてＣＰＵにより実行されることで実現する。

図４（Ａ）は本発明の実施の形態に係るＳＳＯマッピングサービス３００のモジュール構成図である。なお、ＳＰがＳＳＯマッピングサービス３００のモジュールを備える。ＳＳＯマッピングサービス３００は第１の認証モジュール３０１、第２のＩＤリスト取得モジュール３０２、第３のＩＤリスト生成モジュール３０３、ＡＵＩＤリスト生成モジュール３０４、第４のＩＤテーブル生成モジュール３０５、ＳＳＯマッピング設定モジュール３０６、ＩｄＰ登録、選択モジュール３０７から構成される。ＳＳＯマッピング設定モジュール３０６は、ＳＳＯを実現するために必要なマッピングテーブルを生成するためのＳＳＯマッピング用ＩＤテーブル生成要求に対応して第４のＩＤテーブル３０７を返すＡＰＩを持つ。ＳＳＯマッピング設定モジュール３０６は、ＳＳＯマッピング対象サービス４００から第２のＩＤリストを受け付ける。そして、第３のＩＤリスト生成モジュール３０３を用いて第１の認証モジュール３０１でユーザー認証されたユーザーの権限で取得可能なＩＤのリストとして第３のＩＤリストが生成される。第３のＩＤリストのうち第２のＩＤリストに含まれるＳＳＯマッピング対象ユーザーＩＤリストが生成される。ＳＳＯマッピング対象ユーザーＩＤリストの各々のＩＤに対して動的に生成したＡＵＩＤを対応付けた第４のＩＤテーブルであるＳＳＯマッピング設定ファイル５００が生成され、ＳＳＯマッピングサービスは、ＳＳＯマッピング設定を行って第４のＩＤテーブルを返す。ＩｄＰ登録、選択モジュール３０７は、ＳＳＯマッピング対象サービス４００を、ＳＡＭＬプロトコルのＩｄＰとして登録する。さらに、ＩｄＰ登録、選択モジュール３０７は、ＳＳＯマッピング設定要求において、ＳＰ側ユーザーとして複数ＩｄＰを使用するユーザーに対して、現在有効なＩｄＰを選択させる機能を提供する。

図４（Ｂ）は本発明の実施の形態に係るＳＳＯマッピング対象サービス４００のモジュール構成図である。なお、ＩｄＰがＳＳＯマッピング対象サービスのモジュールを備える。ＳＳＯマッピング対象サービス４００は第２の認証モジュール４０１、ＳＳＯ設定情報受付モジュール４０２、第１のＩＤテーブル生成モジュール４０３、第２のＩＤリスト生成モジュール４０４、第４のＩＤテーブル取得モジュール４０５、第５のＩＤテーブル生成モジュール４０６、ＳＳＯマッピング設定モジュール４０７から構成される。ＳＳＯマッピング設定モジュール４０７は、ＳＳＯマッピングのためのＳＳＯマッピング用ＩＤテーブル生成要求を出す。ＳＳＯマッピング設定モジュール４０７は、ＳＳＯマッピングサービス３００からＳＳＯマッピングのためのＳＳＯマッピング用ＩＤテーブルを取得すると、第５のＩＤテーブルを生成してＳＳＯマッピング設定を行う。

図５は本発明の実施の形態に係るＳＳＯマッピング対象となるユーザーリストデータの例である。図５（Ａ−１）の４５０はＳＳＯマッピングサービスが管理するテナント（グループ）別ユーザーリストデータの、図５（Ｂ−１）の３５０はＳＳＯマッピング対象サービスが管理するテナント別ユーザーリストデータの例である。ここではＳＳＯマッピング対象サービス４００にＴｅｎａｎｔＡおよびＴｅｎａｎｔＣの２つのテナントがある。そして、ＴｅｎａｎｔＡにはユーザーＩｄＰ Ｕｓｅｒ１−３が、テナントＴｅｎａｎｔＣにはユーザーＩｄＰ Ｕｓｅｒ４が所属している場合のデータ例を示している。またＳＳＯマッピングサービス３００にＴｅｎａｎｔＢの１つのテナントがあり、テナントＴｅｎａｎｔＢにはユーザーＳＰ Ｕｓｅｒ１−３が所属している場合のデータ例を示している。また図５（Ｂ−２）の５００は、図４（Ｂ）の第１のＩＤテーブル生成モジュール４０３により生成される第１のＩＤテーブルの例である。図５（Ｂ−３）の５５０は、図４（Ｂ）の第２のＩＤリスト生成モジュール４０４により生成される第２のＩＤリストの例である。さらに図５（Ａ−２）の６００は、図４（Ａ）の第３のＩＤリスト生成モジュール３０３により生成される第３のＩＤリストの例である。

図６は本発明の実施の形態に係る第４および第５のＩＤテーブルの例である。第５のＩＤテーブル６０２は、図４（Ｂ）で説明した第５のＩＤテーブル生成モジュール４０６により生成される第５のＩＤテーブルの例である。第４のＩＤテーブル６０１は、図４（Ａ）で説明した第４のＩＤテーブル生成モジュール３０５により生成される第４のＩＤテーブルの例である。

図７は本発明の実施形態に係るＳＳＯマッピング設定のフローチャートである。なお、ＳＳＯマッピング設定とは、図６のＡとＢを作ることを指す。図７（Ａ）はＩｄＰ側ＳＳＯのマッピング、すなわちＳＳＯマッピング対象サービス４００におけるフローチャートを、図７（Ｂ）はＳＰ側のＳＳＯマッピング、すなわちＳＳＯマッピングサービス３００におけるフローチャートをそれぞれ示している。

図７（Ａ）は、本発明の実施の形態に係るＳＳＯマッピング対象サービス４００におけるＳＳＯマッピングの設定フローを示すフローチャートである。本フローチャートは、ＳＳＯマッピング対象サービス４００が、ＳＳＯマッピングのマッピングテーブルを作成したいユーザーにアクセスされることによって始まる。

ステップＳ１００１において、第２の認証モジュール４０１は、ＳＳＯマッピング対象サービス４００にアクセスしたユーザーから、ＳＳＯマッピング対象サービス４００でユーザー認証を受けるための第１のＩＤと第１のパスワードを受け付ける。つまり、ＩｄＰへのＩＤとパスワードを受け付ける。

ステップＳ１００２で第２の認証モジュール４０１は、ステップＳ１００１で受け付けた第１のＩＤと第１のパスワードの組み合わせが正しいか判断する。組み合わせが正しければ、ステップＳ１００３に遷移する。また組み合わせが正しくなければユーザーのアクセスを拒否して本フローチャートを終了する。

ステップＳ１００３で第２の認証モジュール４０１は、ユーザーから受け付けた第１のＩＤとしてＳＳＯマッピングサービス４００へのログインを許可する。なおここでは、ユーザーのＩＤがＩｄＰ Ｕｓｅｒ１であった場合を考える。

ステップＳ１００４でＳＳＯ設定情報受付モジュール４０２は、ユーザーからＳＳＯマッピング設定情報を受け付ける。ＳＳＯマッピング設定情報は、ＳＰ側ユーザーＩＤ、ＳＰ側ユーザーＩＤに対応するパスワード、ＳＳＯマッピング情報ファイルで構成される。ＳＳＯマッピング情報ファイルとは、ユーザーが希望するＳＳＯマッピングの対象となるユーザーＩＤが記述された情報ファイルでＣＳＶ、ＪＳＯＮ、ＸＭＬ形式などで示される。なおＳＳＯマッピング設定情報をユーザーに入力させる画面は、例えば図９に示すような画面であり、設定ボタンが押されることでＳＳＯマッピング設定情報がアップロードされる。ここではＳＳＯマッピング設定情報５００として、ＩｄＰ Ｕｓｅｒ１とＳＰ Ｕｓｅｒ１、ＩｄＰ Ｕｓｅｒ２とＳＰ Ｕｓｅｒ２、ＩｄＰ Ｕｓｅｒ３とＳＰ Ｕｓｅｒ３のそれぞれの組み合わせにＳＳＯマッピング設定させる情報が記述されていた場合を考える。本実施例の場合、ＣＳＶファイルで以下のような情報であるとする。
ＩｄＰ Ｕｓｅｒ１，ＳＰ Ｕｓｅｒ１
ＩｄＰ Ｕｓｅｒ２，ＳＰ Ｕｓｅｒ２
ＩｄＰ Ｕｓｅｒ３，ＳＰ Ｕｓｅｒ３
この情報が記述されたＳＳＯマッピング設定情報が、図９を使ってアップロードされる。

ステップＳ１００５でＳＳＯ設定情報受付モジュール４０２は、ステップＳ１００４で受け付けたＳＳＯマッピング設定情報から、第１のＩＤテーブル生成モジュール４０２を利用して第１のＩＤテーブル５００を生成する。さらにＳＳＯ設定情報受付モジュール４０２は、第１のＩＤテーブル５００から、後述するサービス３００に対するＳＳＯ設定要求ＡＰＩの引数となるＳＳＯ設定要求ＩＤリスト５５０（第２のＩＤリスト）を生成する。さらにＳＳＯ設定情報受付モジュール４０２は、ＳＳＯマッピングサービスＢ４００のエンティティＩＤを取得する。なお、エンティティＩＤは、単に特定情報と呼ばれることもある。

ステップＳ１００６でＳＳＯ設定情報受付モジュール４０２は、ステップＳ１００５にて生成した第１のＩＤテーブル５００を一時保存する。ここで保持された第１のＩＤテーブル５００は、後述するＳＳＯマッピング設定モジュール４０７が、第５のＩＤテーブル６０２を生成するために使用する。

ステップＳ１００７でＳＳＯ設定情報受付モジュール４０２は、ステップＳ１００４、ステップＳ１００５で収集した情報を引数にして、ＳＳＯマッピング設定要求をサービスＡ３００に送信する。ＳＳＯマッピング設定要求と共に送信する情報は、ＳＰ実行者情報（ＳＰユーザーＩＤ、ＳＰパスワード）と、ＳＳＯ設定要求ＩＤリスト５５０と、サービスＢ４００のエンティティＩＤである。

ここでＳＳＯマッピング対象サービス４００は、ＳＳＯマッピング設定要求、すなわち第４のＩＤテーブル生成の要求に対するＳＳＯマッピングサービス３００の応答を待つ。

ステップＳ１００８でＳＳＯ設定情報受付モジュール４０２は、図７（Ｂ）で後述するＳＳＯマッピングサービス３００の処理結果により、第４のＩＤテーブル６０１を受信する。

ステップＳ１００９でＳＳＯ設定情報受付モジュール４０２は、受信した第４のＩＤテーブルの判定を行う。本判定は、Ｓ１００８にて受信された第４のＩＤテーブルに含まれるＳＰのユーザー、ＳＰ Ｕｓｅｒ１−３がステップＳ１００６にて保存した第１のＩＤテーブル５００に含まれるかどうかを判定する。もし判定の結果、ＩｄＰのユーザーが誤りであれば、処理を中止し、ステップＳ１０１１にてエラーメッセージを表示して（図示せず）、本フローチャートを終了する。もし判定の結果が正常であったなら、次のステップＳ１０１０に遷移する。例えば、第４のＩＤテーブルにＳＰ Ｕｓｅｒ１とＳＰ Ｕｓｅｒ４が含まれていた場合、ＳＰ Ｕｓｅｒ１については以降の処理へと進めるが、ＳＰ Ｕｓｅｒ４については第１のＩＤテーブル５００に含まれない。そのため、エラーとなる。

ステップＳ１０１０でＳＳＯ設定情報受付モジュール４０２は、第５のＩＤテーブル生成モジュール４０６を使用して、第５のＩＤテーブルを生成する。第５のＩＤテーブルの生成には、ステップＳ１００６にて保存した第１のＩＤテーブル５００と、ステップＳ１００８にて受信した第４のＩＤテーブル６０１を利用する。第５のＩＤテーブル生成モジュール４０６は、Ｓ１００８にて受信した第４のＩＤテーブル６０１とＳ１００６にて保存した第１のＩＤテーブル５００を使って第４のＩＤテーブル６０１を生成する。具体的には、第４のＩＤテーブル６０１のＳＰ Ｕｓｅｒ１、ＳＰ Ｕｓｅｒ２、ＳＰ Ｕｓｅｒ３に対応する第１のＩＤテーブル５００のＩｄＰ Ｕｓｅｒ１、ＩｄＰ Ｕｓｅｒ２、ＩｄＰ Ｕｓｅｒ３を抽出する。さらに、抽出したＩｄＰ Ｕｓｅｒ１、ＩｄＰ Ｕｓｅｒ２、ＩｄＰ Ｕｓｅｒ３に、第４のＩＤテーブル６０１のＡＵＩＤ１、ＡＵＩＤ２、ＡＵＩＤ３を対応付けする。以上の処理により、ＳＳＯ設定情報受付モジュール４０２は、第５のＩＤテーブル６０２を生成し、ＳＳＯマッピング設定を行う。

本ＳＳＯマッピング設定を終了し、本フローチャートを終了する。なお、本ＳＳＯマッピング設定は、ユーザーＩＤの削除、移動に伴いＡＵＩＤ上の設定も削除される。具体的には、ＡＵＩＤマッピングテーブル上にＩｄＰ Ｕｓｅｒ１とＡＵＩＤ１の設定が存在した場合、ＩｄＰ Ｕｓｅｒ１の削除に伴い、ＩｄＰ Ｕｓｅｒ１とＡＵＩＤ１の設定も、ＡＵＩＤマッピングテーブルから削除される。

その結果、例えば、一度ＳＳＯマッピングが行われた後にユーザーＩＤが削除され、かつ、再度同じユーザーＩＤが登録された場合であっても、削除前のユーザーＩＤと再登録されたユーザーＩＤには異なるＡＵＩＤが発行される。よって、適切なＳＳＯを実現できる。

なお、図７Ａの処理は１台のサーバーで処理される前提で説明したが、複数のサーバーで構成されるシステムを使って図７Ａの処理を実現しても構わない。複数のサーバーで構成されるシステムが図７Ａの処理を実現する場合、各サーバーが図４Ａの各モジュールを備えることとなる。

図７（Ｂ）は本発明の実施の形態に係る、ＳＳＯマッピングサービス３００における第４のＩＤテーブルの生成フローチャートである。本フローチャートは、ステップＳ１１０１にて、ＳＳＯマッピングサービス３００が、ＳＳＯマッピング対象サービス４００から第４のＩＤリストの生成要求を受けることで始まる。第４のＩＤテーブル生成要求には、ステップＳ１００７で述べたＳＰユーザーＩＤと、ＳＰパスワードと、ＳＳＯ設定要求ＩＤリスト（第２のＩＤリスト）５５０と、サービスＢ４００のエンティティＩＤが含まれる。

ステップＳ１１０２で、第１の認証モジュール３０１は、第４のＩＤリストの生成要求に含まれるＳＰユーザーＩＤとＳＰパスワードの組合せが正しいか判断する。組み合わせが正いと判断されればステップＳ２００３に遷移し、正しくないと判断されれば、第４のＩＤテーブルをＳＳＯマッピング対象サービス４００に返さずにステップＳ１１１４にてエラーを返却して本フローチャートを終了する。なお、このＳＰユーザーＩＤとＳＰパスワードを用いることでテナントＩＤが特定される。

ステップＳ１１０３で、第１の認証モジュールは、第４のＩＤリストの生成要求に含まれるエンティティＩＤの判定のためＳＳＯマッピング設定モジュール３０６を利用して既に登録されているエンティティＩＤのリストを取得する。本エンティティＩＤリストに登録されているエンティティＩＤは、ＳＳＯマッピングサービス３００にＳＳＯが許可されているものとする。つまり、エンティティＩＤのリストには、エンティティＩＤごとにＳＳＯを許可するか否かが設定されている。

ステップＳ１１０４で、第１の認証モジュールは、ステップＳ１１０３で取得したエンティティＩＤリストに第４のＩＤリストの生成要求に含まれるエンティティＩＤが含まれるかどうか判定する。もしエンティティＩＤが含まれていると判定されればステップＳ１１０５に遷移し、含まれないと判定されれば、第４のＩＤテーブルをＳＳＯマッピング対象サービス４００に返さずにステップＳ１１１４にてエラーを返却して本フローチャートを終了する。

ステップＳ１１０５でＩｄＰ登録、選択モジュール３０７は、第４のＩＤリストの生成要求に含まれるＳＰユーザーのＩｄＰ登録状態を確認する。具体的には、ＳＰは、テナントＩＤごとにＩｄＰが登録されたリストを備える。ＳＰは、Ｓ１１０５にてそのリストを参照し、今回の対象のテナントＩＤにＩｄＰが登録されているか否かを判定する。登録されている場合、Ｓ１１０５の処理はＹｅｓと判定され、登録されていない場合、Ｓ１１０５の処理はＮｏと判定される。

ステップＳ１１０６で、第３のＩＤリスト生成モジュールは、第１の認証モジュール３０１でユーザー認証されたユーザーの権限（つまり、ＳＰ実行者情報）で取得可能なＩＤのリストを示す第３のＩＤリストを生成する。例えば、本願の図５のＡ−２が第３のＩＤリストに相当し、今回のＳＰ実行者情報によりＳＰ Ｕｓｅｒ１−３の情報が取得されたことを示す。さらに詳細に説明する。第３のＩＤリスト生成モジュールは、ＳＰ実行者情報の権限（例えば、管理者か否か）を確認し、ＳＰ実行者情報が属するテナントＩＤを特定する。そして、特定されたテナントＩＤに属するＩＤリストから今回のＳＰ実行者情報の権限で取得可能なＩＤを取得することで第３のＩＤリストが生成される。

ステップＳ１１０７で、ＳＳＯマッピング設定モジュール３０６は、第２のＩＤリスト取得モジュール３０２を利用して、第４のＩＤテーブルの生成要求に含まれるＳＳＯ設定要求ＩＤリスト（第２のＩＤリスト）５５０を取得する。なお、第２のＩＤリストは、単にユーザー情報と呼ばれることもある。

さらにＳＳＯマッピング設定モジュール３０６は、ステップＳ１１０６で生成した第３のＩＤリストと第２のＩＤリストを比較し、両者が一致していればステップＳ１１０８に遷移する。もしリストが不一致であれば、ステップＳ１１１１に遷移する。

ステップＳ１１１１でＳＳＯマッピング設定モジュール３０６は、ステップＳ１１０７で取得した第２のＩＤリストのユーザーが第３のＩＤリストに含まれるかどうか確認する。もし第２のＩＤリストのユーザーが第３のＩＤリストに含まれる場合、ステップＳ１１１２に遷移する。もし第２のＩＤリストのユーザーが第３のＩＤリストに含まれない場合、ステップＳ１１１４にてエラーを返却して本フローチャートを終了する。

ステップＳ１１１２でＳＳＯマッピング設定モジュール３０６は、ステップＳ１１１１で確認した第２のＩＤリストに含まれるユーザーのうち、第３のＩＤリストに含まれるユーザーを選出する。そして、ＳＳＯマッピング設定モジュール３０６は、第２のＩＤリストとして再生成し、ステップＳ１１０８に遷移する。

ステップＳ１１０８でＳＳＯマッピング設定モジュール３０６は、第２のＩＤリストに対するＳＳＯマッピング処理を行う。本ＳＳＯマッピング処理は、第４のＩＤテーブル生成モジュール３０５が、第２のＩＤリストに含まれる各ユーザーＩＤに対してＡＵＩＤを設定する処理である。

ステップＳ１１０９でＳＳＯマッピング設定モジュール３０６は、生成したＡＵＩＤを対応付けた第４のＩＤテーブルであるＳＳＯマッピング設定情報６０１を生成してＩｄＳへ送信する。

以上の処理により第４のＩＤテーブル（図６のＡ）と第５のＩＤテーブル（図６のＢ）が生成されたため、ＳＳＯマッピング設定が終了する。

本ＳＳＯマッピング設定は、ユーザーＩＤの削除、移動に伴いＡＵＩＤ上の設定も削除される。具体的には、ＡＵＩＤマッピングテーブル上にＳＰ Ｕｓｅｒ１とＡＵＩＤ１の設定が存在した場合、ＳＰ Ｕｓｅｒ１の削除に伴い、ＳＰ Ｕｓｅｒ１とＡＵＩＤ１の設定も、ＡＵＩＤマッピングテーブルから削除される。

なお、本願では、ＳＳＯマッピング設定がＳＰに要求される前に、ＳＰがＳＰユーザーＩＤを作成した段階で各ＳＰユーザーＩＤにＡＵＩＤを設定しておいても良い。

ＳＳＯマッピング設定がＳＰに要求される前に各ＳＰユーザーＩＤにＡＵＩＤが設定されていた場合、ＳＰは、ＳＰユーザーＩＤにＡＵＩＤが設定されたテーブルを保持する。

そしてＳＰがＳＳＯマッピング設定要求を受信した場合、ＳＳＯマッピング設定モジュール３０６は、第２のＩＤリストの各ＳＰユーザーＩＤに、事前に登録したテーブルを使ってＡＵＩＤを設定する。

なお、図７Ｂの処理は１台のサーバーで処理される前提で説明したが、複数のサーバーで構成されるシステムを使って図７Ｂの処理を実現しても構わない。複数のサーバーで構成されるシステムが図７Ｂの処理を実現する場合、各サーバーが図４Ａの各モジュールを備えることとなる。

本実施の形態によれば、ユーザーが既に持っているＳＰ用のＩＤに対してＳＳＯマッピングを設定することができる。また企業のテナント内で管理者が代理でＳＳＯマッピングを設定しようとした場合、各ユーザーのパスワードを知らなくても代理でＳＳＯマッピング設定を行える。さらにＳＳＯマッピングを設定後、ＳＳＯ対象サービスでユーザーを削除後、同名のユーザーを再作成しても、誤ってＳＳＯマッピングが設定されることもない。

図９は本発明の実施の形態に係るＳＳＯマッピング設定用の画面例である。図９はＳＰのユーザーＩＤおよびパスワード、ＳＳＯマッピング設定情報５００を受け付ける。なおここでＳＳＯマッピング対象サービスがＩｄＰであることを想定したため画面例にもＩｄＰと記載しているが、ＳＳＯマッピング対象サービスはＩｄＰであることに限定されない。またＳＳＯマッピング設定情報５００も、ファイル以外の形態で指定されてもよい。

なお、本願の図７Ｂでは、Ｓ１１０５においてＮｏと判断された場合、ＳＰはＩｄＰへエラーを返却していたが、自動的にＩｄＰを登録しても良い。以下に図１０の表、および図１１のフローチャートを使ってＳＰが自動的にＩｄＰを登録する方法について説明する。

図１０（Ａ）は、ＳＳＯマッピングサービス３００における、ＳＳＯマッピング対象のテナントＩＤとＩｄＰの対応を記憶する表である。本表は、ＳＳＯマッピングサービス側（ＳＰ側）に存在し、ＳＳＯマッピング設定要求のテナントＩＤと、ＳＳＯマッピング対象のＩｄＰのＩＤの対応付けを保存している。本対応は、ＳＳＯマッピング処理に先立って設定されている。図１０（Ａ）の場合、ＳＰ側に登録したテナントＡはＩｄＰ＿Ａに対応し、テナントＢにはＩｄＰが登録されていない。

図１０（Ｂ）は、ＳＳＯマッピングサービス３００における、自動登録可能なＩｄＰのリストを示す表である。本表は、ＳＳＯマッピングサービス側（ＳＰ側）に存在する。本リストは、ＳＳＯマッピング処理に先立って設定されている。図１０（Ｂ）の場合、ＩｄＰ＿Ａ とＩｄＰ＿Ｂが自動登録可能なＩｄＰであることを示す。

図１１は、ＩｄＰ自動登録処理を表すフローチャートである。図７ＢのステップＳ１１０５においてＮｏと判断された場合、第１の認証モジュールは、本フローチャートの処理を開始する。なお、図１１の処理を実現するためには、Ｓ１００７で上述した情報に加えてＩｄＰの識別情報も取得しておく必要がある。

ステップＳ１２０１にて第１の認証モジュールは、図１０（Ｂ）の自動登録可能なＩｄＰリストを参照する。

次にステップＳ１２０２において、第１の認証モジュールは、ＩｄＰの識別情報が図１０（Ｂ）に含まれているか判定する。もし含まれていない場合、第１の認証モジュールは、Ｓ１２０４にてエラーを返却する。

Ｓ１２０２において含まれると判定された場合、ステップＳ１２０３において、第１の認証モジュールは、自動登録可能と判定してＳ１００７で渡されたＩｄＰの識別情報をテナントＩＤに対して登録する。例えば、図１０（Ａ）の状況において、ＳＳＯマッピング対象のテナントＩＤがテナントＢであり、かつ、ＩｄＰの識別情報としてＩｄＰ＿ＢがＩｄＰから渡された場合、図１０（Ａ）のテナントＢに対応するＩｄＰとしてＩｄＰ＿Ｂが登録される。

［他の実施形態］
また、本発明は、以下の処理を実行することによっても実現される。

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

１００ ＷＡＮ
１０１ ＬＡＮ

Claims (11)

1. 複数のユーザー情報を管理するシステムであって、
   ユーザー情報を他システムから受信する受信手段と、
   受信された前記ユーザー情報と前記複数のユーザー情報においてユニークな識別情報とを対応づけたテーブルを生成し、生成された前記テーブルを前記他システムへ送信する送信手段と、
   生成された前記テーブルをＳＳＯマッピング設定する設定手段と、を有し、
   前記他システムにおいて、前記送信手段により送信された前記テーブルを基に前記他システムのユーザー情報と前記ユニークな識別情報とを対応づけたテーブルが生成され前記テーブルがＳＳＯマッピング設定され、
   前記システムおよび前記他システムのＳＳＯマッピング設定に従い、前記システムおよび前記他システム間のシングルサインオンが実現されることを特徴とするシステム。
2. 前記ユーザー情報は、前記他システムが受け付けたＳＳＯマッピング設定情報を基に生成されるＩＤテーブルのユーザー情報であって、前記他システムから前記システムへ送信されるユーザー情報であることを特徴とする請求項１に記載のシステム。
3. 前記受信手段が前記ユーザー情報と共に受信する前記他システムのエンティティＩＤに基づいて、前記他システムが登録エンティティであるか否かを判定する判定手段を更に有し、
   前記判定手段により登録エンティティであると判定された場合、前記送信手段は、前記テーブルを送信することを特徴とする請求項１または２に記載のシステム。
4. 前記受信手段が前記ユーザー情報と共に受信したユーザーＩＤおよびパスワードに基づき、前記ユーザーＩＤのユーザーが属するグループを特定する特定手段を更に備える請求項１乃至３のいずれか１項に記載のシステム。
5. 前記特定手段は、前記ユーザーＩＤの権限を特定し、
   前記送信手段は、前記特定されたグループに属するユーザー情報の中で前記権限により取得されるユーザー情報と、前記ユニークな識別情報とを対応付けた前記テーブルを送信することを特徴とする請求項４に記載のシステム。
6. 複数のユーザー情報を管理するシステムにおいて実行される制御方法であって、
   ユーザー情報を他システムから受信する受信ステップと、
   受信された前記ユーザー情報と、前記複数のユーザー情報においてユニークな識別情報とを対応づけたテーブルを生成し、生成された前記テーブルを前記他システムへ送信する送信ステップと、
   生成された前記テーブルをＳＳＯマッピング設定する設定ステップと、を含み、
   前記他システムにおいて、前記送信ステップにおいて送信された前記テーブルを基に前記他システムのユーザー情報と前記ユニークな識別情報とを対応づけたテーブルが生成され前記テーブルがＳＳＯマッピング設定され、
   前記システムはおよび前記他システムのＳＳＯマッピング設定に従い、前記システムおよび前記他システム間のシングルサインオンが実現されることを特徴とする制御方法。
7. 複数のユーザー情報を管理するシステムにおいて実行されるプログラムであって、
   ユーザー情報を他システムから受信する受信手段と、
   受信された前記ユーザー情報と、前記複数のユーザー情報においてユニークな識別情報とを対応づけたテーブルを生成し、生成された前記テーブルを前記他システムへ送信する送信手段と、
   生成された前記テーブルをＳＳＯマッピング設定する設定手段として機能させるプログラムであり、
   前記他システムにおいて、前記送信手段により送信された前記テーブルを基に前記他システムのユーザー情報と前記ユニークな識別情報とを対応づけたテーブルが生成され前記テーブルがＳＳＯマッピング設定され、
   前記システムはおよび前記他システムのＳＳＯマッピング設定に従い、前記システムおよび前記他システム間のシングルサインオンが実現されることを特徴とするプログラム。
8. 前記ユーザー情報は、前記他システムが受け付けたＳＳＯマッピング設定情報を基に生成されるＩＤテーブルのユーザー情報であって、前記他システムから前記システムへ送信されるユーザー情報であることを特徴とする請求項７に記載のプログラム。
9. 前記受信手段が前記ユーザー情報と共に受信する前記他システムのエンティティＩＤを特定するための特定情報に基づいて、前記他システムが登録エンティティであるか否かを判定する判定手段を更に有し、
   前記判定手段により登録エンティティであると判定された場合、前記送信手段は、前記テーブルを送信することを特徴とする請求項７または８に記載のプログラム。
10. 前記受信手段が前記ユーザー情報と共に受信したユーザーＩＤおよびパスワードに基づき、前記ユーザーＩＤのユーザーが属するグループを特定する特定手段を更に備える請求項７乃至９のいずれか１項に記載のプログラム。
11. 前記特定手段は、前記ユーザーＩＤの権限を特定し、
    前記送信手段は、前記特定されたグループに属するユーザー情報の中で前記権限により取得されるユーザー情報と、前記ユニークな識別情報とを対応付けた前記テーブルを送信することを特徴とする請求項１０に記載のプログラム。

Images