JP5955106B2

JP5955106B2 - マッピングサーバーとシングルサインオンシステム、マッピング機能提供方法

Info

Publication number: JP5955106B2
Application number: JP2012126544A
Authority: JP
Inventors: 存田村
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2012-06-01
Filing date: 2012-06-01
Publication date: 2016-07-20
Anticipated expiration: 2032-06-01
Also published as: JP2013250894A

Description

本発明は、たとえばマルチテナント対応したサーバー群の間等でシングルサインオンを実現するための、マッピングサーバーとシングルサインオンシステム、マッピング機能提供方法に関する。

特に、サーバー群から構成されるＩＤＰを複数登録可能なシステムにおいて、各々のＩＤＰに適当なマッピングサーバーとシングルサインオンシステム、マッピング機能提供方法に関する。

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

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

なお、ユーザーがＳＰにＳＳＯを利用しアクセスする際は、上述のように自身のＳＰ用のユーザーＩＤをＳＰに渡していない。そのため、ユーザーはＳＳＯを利用するのに先立って、ＩＤＰで認証を受けるＩＤＰ用のユーザーＩＤと、ＳＰにアクセスする際のＳＰ用のユーザーＩＤとの対応関係を上述のシステムに保持しておく必要がある。この対応関係を登録する処理をシングルサインオンマッピング（以下、ＳＳＯマッピングという）と呼ぶ。

このように、ＳＡＭＬのＳＳＯは、ＩＤＰとＳＰの信頼関係によって成り立っている。つまりは、ＳＳＯを実現する前に、事前にＩＤＰとＳＰとの間で信頼関係を結んでいる必要がある。この信頼関係は、ＳＡＭＬプロトコルで規定されたどの方式でＳＳＯを行うのかを記述したメタデータと、アサーションがＩＤＰから発行された事を証明するための電子証明書の交換によって成立する。

前述の通り、ＳＡＭＬは、ユーザーがＩＤＰによって認証されたこと、またそのＩＤＰがＳＰから見て信頼できるものであることを検証することで、安全にＳＳＯを提供する。より具体的には、ＳＰは、ＩＤＰで発行されたアサーションの署名を事前に設定した電子証明書を用いて検証する事でＳＳＯを実現する。ただし、ＳＡＭＬの仕組み自体は安全であっても、ＳＡＭＬの設定、例えばＳＳＯマッピングが間違っていた場合、ＩＤＰで認証を受けたユーザーは、意図しないユーザーにマッピングされてＳＰにアクセスしてしまう。そのユーザーは、ＳＰにおける別のユーザーとして承認されたことになる。このことからも、ＳＡＭＬの仕組みを安全に利用するためにはＳＳＯの設定も安全に設定してある必要がある。

次に、ＩＤＰとＳＰとの関係を考える。ＳＰから見た場合、ＩＤＰは、エンティティＩＤ（ＥｎｔｉｔｙＩＤ）と呼ばれるＩＤで識別される。このエンティティＩＤは事前に交換したメタデータに記載されている。ここでＩＤＰによっては、認証機能を提供するサーバー群として単一のエンティティＩＤしか持たないものと、複数のエンティティＩＤを持てるものとがある。エンティティＩＤが単一か複数かは、ＩＤＰの構成によって異なる。

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

一方アプリケーションサービスプロバイダーなど第三者にサービスを提供するケースでは、第三者からのアクセスを特定のＵＲＬに限定することで利便性や安全性を向上させることがある。このような場合は、ＵＲＬが単一になり、エンティティＩＤが単一になる。
上記のようにエンティティＩＤが単一か複数かは、ＩＤＰの構成によって異なる。

ここで１つのＳＰに対し、複数のＩＤＰでＳＳＯを可能とする場合を考える。その実現のためには、いずれのＩＤＰともＳＳＯできるようにするため、あらかじめＳＰにＩＤＰを登録しておく必要がある。

そこで従来、ＳＳＯ対象のサーバー群を複数登録できるようにする方式があった（特許文献１等参照）。この方式によれば、ＳＳＯ対象のサーバー群を複数登録できる。またＳＳＯ対象のサーバー群の登録を解除する際は、そのサーバー群に対応する画像を表示させることで、意図しないサーバー群の登録を解除することを防いでいる。

特許第４１８６５２１号

しかしながら従来の方法には以下の問題があった。すなわち、ＳＳＯするためには事前にＳＳＯマッピングの設定が必要であるが、ＳＳＯ対象のサーバー群であるＩＤＰまたはＳＰが複数登録されている場合は、それぞれのＩＤＰまたはＳＰに対して適当な手段でＳＳＯマッピングする必要がある。たとえば複数のユーザー企業が同一のＳＰを利用するケースを考えると、ＳＰ上で管理される各企業の情報は互いに独立して分離されている必要がある。このような分離の単位を、以下でテナントと呼ぶ。ここでひとつのＳＰに複数ＩＤＰを登録する場合を考える。このときＩＤＰのあるユーザーに対し、ＳＰの異なるテナントのユーザーをＳＳＯマッピングできてしまうことは情報漏えいの危険がありセキュリティ上好ましくない。また逆に、１つのＳＰのテナントに対し、異なるＩＤＰのユーザーをＳＳＯマッピングできてしまうことも、同様に好ましくない。いずれも当該ユーザーの本来の権限を越えた他のユーザーの権限でＳＰにアクセスし得るためである。よって誤ったＳＳＯマッピングを防ぎ、セキュリティを担保することが必要である。ここでＩＤＰの特性により、セキュリティを担保するためのＳＳＯマッピングの方式が異なるため、登録されたＩＤＰに対して適当な方式でＳＳＯマッピングする必要がある。

さらに、ＳＳＯマッピングを実施する際には、そのＳＳＯマッピング行為の妥当性を確認するために、ＩＤＰのＡＰＩを呼ぶ場合がある。このとき、ＩＤＰのＡＰＩを呼び出すには、ＩＤＰの認証や認可が必要になる。そのため、認証や認可を受ける前処理が必要となる。この前処理には、ＩＤＰごとのポリシーによって、ＩＤとパスワードとによる認証が求められる場合や、ＯＡｕｔｈと呼ばれる認可の仕組みを利用する必要がある場合もある。このように、ＩＤＰごとに適当な方式で前処理する必要がある。

また、同一のＩＤＰで複数の前処理が利用可能な場合がある。そのようなケースでは、ユーザーの選択に従い、ＳＳＯマッピング時にどの前処理方式を利用するか判断できる必要がある。

本発明は上記従来例に鑑みてなされたもので、情報漏えい等、セキュリティ上の危険を抑制したＳＳＯマッピングを実現できるマッピングサーバーとシングルサインオンシステム、マッピング機能提供方法を提供することを目的とする。

上記目的を達成するために本発明は以下の構成を備える。

認証サーバーがユーザーを認証したことを示すユーザー認証情報を、他のサーバーにおける前記ユーザーのユーザーＩＤと関連付けて当該サーバーへのアクセスを許すシングルサインオンシステムにおいて、ユーザーＩＤを関連付けたマッピング情報を提供するマッピングサーバーであって、
前記ユーザーＩＤの関連付けを行うマッピング機能を、各認証サーバーに関連付けて登録したマッピング機能情報と、
前記マッピング機能を実行する前に行うべき前処理を、前記認証サーバーごとに関連付けて登録した前処理機能情報と、
前記マッピング機能情報を参照して、前記マッピング機能に関連付けられた認証サーバーの選択を受け付ける受け付け手段と、
前記選択された認証サーバーに関連付けられたマッピング機能に応じた処理を実行して前記マッピング情報を構成する実行手段と
を有し、
前記実行手段は、前記前処理機能情報を参照して、前記選択された認証サーバーに関連付けられた前処理機能が前記認証サーバーにより実行される場合には、当該前処理機能を実行し、さらに前記選択された認証サーバーに関連付けられたマッピング機能に応じた処理を実行して前記マッピング情報を構成する。

あるいは、他の側面によれば、本発明は、マッピングサーバーと、認証サーバーと、そのほかのサーバーとを含むシングルサインオンシステムにある。

本発明によれば、ユーザーが利用可能なＩＤＰを一覧表示させるとともに、それぞれのＩＤＰに対して適切なＳＳＯマッピング機能を対応づけることができる。そのため、ＩＤＰの特性にあわせて、セキュリティを担保するため適切なＳＳＯマッピング機能を提供することができる。

ネットワーク構成を示す図である。本発明の実施の形態に係るＰＣの構成図である。本実施の形態に係るモジュール構成図である。、本実施の形態に係るデータ例である。、本実施の形態に係るＳＳＯマッピングのためのフローである。本実施の第２の形態に係るモジュール構成図である。、、本実施の第２の形態に係るデータ例である。、本実施の第２の形態に係るＳＳＯマッピングのための前半のフローである。、、本実施の第２の形態に係るＳＳＯマッピングのための後半のフローである。本実施の第２の形態に係るモジュール構成図である。本実施の第２の形態に係るデータ例である。本実施の第２の形態に係るＳＳＯマッピングのためのフローである。、本実施の形態に係る画面例である。、、本実施の第２の形態に係る画面例である。本実施の第３の形態に係る画面例である。

［第１実施形態］
本発明の目的は、認証を連携させたいサーバー群の間で、それぞれに適切なＳＳＯマッピング機能を提供することである。なお本実施形態及び第２乃至第４の実施形態でいうマッピング機能とは、サーバー（あるいはサービスともいう）間のユーザーＩＤを関連付けてＩＤの対応表（あるいはマッピング情報）を構成する機能である。以下、本発明を実施するための最良の形態について図面を用いて説明する。

＜システム構成＞
本実施の形態に係るシングルサインオンシステムは、図１に示すような構成のネットワーク上に実現される。ＷＡＮ１００は、広域ネットワークであり、本実施形態ではたとえばインターネットで、特にＨＴＴＰを用いたＷｏｒｌｄＷｉｄｅＷｅｂ（ＷＷＷ）システムである。ＬＡＮ１０１は各構成要素を接続するローカルエリアネットワークである。クライアントＰＣ２００はユーザーが操作するクライアントＰＣであり、マッピングサーバー３００は、エンティティＩＤごとにＩＤＰ用のユーザーＩＤとＳＰ用のユーザーＩＤとを関連付けたマッピング情報を有しており、ＳＳＯマッピングを実施するとともに、マッピング情報を管理するための機能を提供する。ＩＤＰ−Ａ４００、ＩＤＰ−Ｂ４１０およびＩＤＰ−Ｃ４２０はそれぞれユーザーを認証するアイデンティティプロバイダ。なおここでマッピングサーバーはサービスプロバイダ（ＳＰ）であることを想定しているが、マッピングサーバーがアイデンティティプロバイダ（ＩＤＰ）であり、４００、４１０および４２０がＳＰであってもよい。アイデンティティプロバイダは、認証サーバーと呼んでもよいし、サービスプロバイダは、単にサービス或いはサーバーと呼んでもよい。

またクライアントＰＣ２００、マッピングサーバー３００、ＩＤＰ−Ａ４００、ＩＤＰ−Ｂ４１０、ＩＤＰ−Ｃ４２０はそれぞれＷＡＮネットワーク１００およびＬＡＮ１０１を介して接続されている。なおクライアントＰＣ２００およびマッピングサーバー３００やそれぞれのＩＤＰは、それぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また同一のＰＣまたはサーバーコンピューター上に構成されていてもよい。例えばＩＤＰ−Ａ３００が構成されるサーバーコンピューター上に、不図示のＩＤＰであるＩＤＰ−Ａ−ＴＲＩＡＬが構成されていてもよい。マッピングサーバー３００、ＩＤＰ−Ａ４００、ＩＤＰ−Ｂ４１０、ＩＤＰ−Ｃ４２０はそれぞれ、後述のサーバーコンピューター上で動作する。

マッピングサーバー３００はまずユーザーのログインを受け付ける。次にユーザーが利用可能なＩＤＰの一覧を表示する。そしてマッピングサーバー３００はユーザーからのＳＳＯマッピング設定要求を受け付けると、そのＳＳＯマッピング設定要求に対応したＩＤＰに関して適当なＳＳＯマッピングを実施する。

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

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

尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はハードディスク（ＨＤ）２１１にインストールされたアプリケーションプログラムである。

＜マッピングサーバーのモジュール構成＞
図３は本実施の形態に係る、マッピングサーバー３００のモジュール構成図である。マッピングサーバー３００はマッピング機能管理モジュール３０１、マッピング機能提供モジュール３０２、利用ＩＤＰ管理モジュール３０３を有する。１つのマッピング機能提供モジュール３０２が複数のＩＤＰに対応したＳＳＯマッピング機能を提供してもよく、またＩＤＰごとに異なるＳＳＯマッピング機能提供モジュール３０２が存在してもよい。ユーザーがマッピングサーバー３００にアクセスすると、利用ＩＤＰ管理モジュール３０３が当該ユーザーの利用可能なＩＤＰを返す。またマッピング機能管理モジュール３０１は、利用ＩＤＰ管理モジュールが返したＩＤＰごとに、対応したマッピング機能提供モジュール３０２の機能を提供する画面のＵＲＬを返す。

＜マッピングサーバーにより管理されるデータ＞
図４Ａ、図４Ｂは本実施の形態に係る、データ例である。図４Ａは本実施の形態に係る、マッピング機能一覧のデータ例である。マッピング機能一覧３５０は、マッピング機能管理モジュール３０１が管理するデータである。ここでマッピング機能一覧３５０は、複数のマッピング機能情報を持つ。個々のマッピング機能情報は、ＩＤＰを特定するＩＤＰ識別子と、そのＩＤＰとのＳＳＯマッピングに関する設定をマッピングサーバー３００が管理するかどうかを示すマッピング管理場所情報を持つ。マッピング管理場所情報は、マッピングサーバー３００が管理することを示す「サーバー内」（ｉｎｔｅｒｎａｌ）とマッピングサーバー３００が管理しないことを示す「サーバー外」（ｅｘｔｅｒｎａｌ）のいずれかの値をとる。さらにマッピングサーバー３００がＳＳＯマッピング機能を提供する場合、個々のマッピング機能情報はＩＤＰに対応するマッピング機能提供モジュール３０２の機能を提供する画面（ＳＳＯマッピング画面）のＵＲＬを持つ。

図４ＡではＩＤＰ−Ａ４００、ＩＤＰ−Ａ−ＴＲＩＡＬ、ＩＤＰ−Ｂ４１０の３つのＩＤＰが登録されている様子を示す。これらのＩＤＰの内、ＩＤＰ−Ａ４００およびＩＤＰ−Ａ−ＴＲＩＡＬは、マッピングサーバー３００がＳＳＯマッピングを管理していることを示すとともに、対応するＳＳＯマッピング画面のＵＲＬも持つ。またＩＤＰ−Ｂ４１０はＳＳＯマッピング管理場所がマッピングサーバー３００の外部であることを示すとともに、対応するマッピング画面を持たないことを示す。

図４Ｂは本実施の形態に係る、利用ＩＤＰ一覧のデータ例である。利用ＩＤＰ一覧３５１は、利用ＩＤＰ管理モジュール３０３が管理するデータである。ここで利用ＩＤＰ一覧３５１は複数の利用ＩＤＰ情報を持つ。個々の利用ＩＤＰ情報は、マッピングサーバー３００にアクセスしたユーザーを識別するための利用者識別子と、そのユーザーが利用可能なＩＤＰのＩＤＰ識別子を持つ。なお利用者識別子はユーザーそのものの識別子でもよく、ユーザーが所属するテナントの識別子であってもよいが、ここでは利用者識別子はテナント識別子であるとする。ここではテナントＴ００１に所属するユーザーであれば、ＩＤＰ−Ａ４００、ＩＤＰ−Ａ−ＴＲＩＡＬ、ＩＤＰ−Ｂ４１０の３つのＩＤＰが利用可能であることを示す。

＜ＩＤＰ一覧表示処理＞
図５Ａ、図５Ｂはそれぞれ、本実施の形態に係る、ＳＳＯマッピングのための機能の一覧表示および各ＳＳＯマッピング機能への振り分けフローである。

図５Ａは本実施の形態に係る、ＳＳＯマッピングのための機能の一覧表示のフローである。ユーザーがマッピングサーバー３００にアクセスすると、そのユーザーが利用可能なＩＤＰが、それぞれ対応したＳＳＯマッピング機能の提供画面への遷移ボタンとともに一覧表示される。

ステップＳ１００１でマッピングサーバー３００は、利用ＩＤＰ管理モジュール３０３から、利用ＩＤＰ一覧３５１のうち、ログインしているユーザーの利用者識別子に対応する利用ＩＤＰ一覧を取得する。ここでユーザーの利用者識別子が、ユーザーが所属するテナントの識別子であるＴ００１であれば、取得できる利用ＩＤＰ一覧はＩＤＰ−Ａ４００、ＩＤＰ−Ａ−ＴＲＩＡＬ、ＩＤＰ−Ｂ４１０の３つのＩＤＰを含むことが図４Ｂの例からわかる。利用ＩＤＰ一覧３５１に含まれるＩＤＰの数が増減すると、それに応じて、後述のフローで処理されるＩＤＰの数が増減する。

ステップＳ１００２でマッピングサーバー３００は、ステップＳ１００１で取得した利用ＩＤＰ一覧（これを対象ＩＤＰと呼ぶ）の内、未処理の利用ＩＤＰ情報があるか判断する。未処理のＩＤＰがあればステップＳ１００３へ遷移する。また未処理のＩＤＰがなければフローを終了する。

ステップＳ１００３でマッピングサーバー３００は、ステップＳ１００１で取得した対象ＩＤＰの内、未処理のＩＤＰを取り出す、あるいは未処理のＩＤＰに着目する。なお、ステップＳ１００１で取得した対象ＩＤＰのうち、ステップＳ１００３で着目したＩＤＰを着目ＩＤＰと呼ぶことがある。

ステップＳ１００４でマッピングサーバー３００は、ステップＳ１００３で取り出した対象ＩＤＰに対応するマッピング機能情報（図４Ａ参照）を、マッピング機能管理モジュール３０１から取り出す。これを着目マッピング機能情報と呼ぶことがある。

ステップＳ１００５でマッピングサーバー３００は、ステップＳ１００４で取り出した着目マッピング機能情報を参照し、マッピングサーバー３００がＳＳＯマッピングを管理しているか、すなわちＳＳＯマッピング管理場所情報がサーバー内であるか判断する。判断の結果、マッピングサーバー３００がＳＳＯマッピングを管理するのであればステップＳ１００６に遷移する。マッピングサーバー３００がＳＳＯマッピングを管理しないのであれば、着目しているＩＤＰに関する処理を終了し、ステップＳ１００２に遷移する。たとえばステップＳ１００４で取り出した着目マッピング機能情報がＩＤＰ−Ａ４００に関するものであった場合、図４Ａに示す通りＩＤＰ−Ａ４００はマッピングサーバー３００がＳＳＯマッピングを管理するため、ステップＳ１００６に遷移する。

ステップＳ１００６でマッピングサーバー３００は、ステップＳ１００４で取り出した着目マッピング機能情報から、ＳＳＯマッピング機能を提供する画面のＵＲＬ（図４ＡのＳＳＯマッピング画面ＵＲＬ）を取り出す。

ステップＳ１００７でマッピングサーバー３００は、ステップＳ１００６で取り出したＳＳＯマッピング画面ＵＲＬを、ステップＳ１００３で取り出した着目ＩＤＰの識別子とともに、画面表示させる。以上でそのＩＤＰに関する処理を終了し、ステップＳ１００２に遷移する。

図５Ａのフローが完了した際に画面に表示されるのは、例えば図１３Ａに示されるようなＩＤＰ一覧表示画面５００である。図１３Ａに示す通り、ログイン中のユーザーが利用可能なＩＤＰ一覧５００がユーザーインターフェースに表示され、そこにはＩＤＰ識別子に関連付けて、そのＩＤＰに対応するＳＳＯマッピング画面へのリンク（ＵＲＬ）が埋め込まれたオブジェクト、たとえば遷移ボタン１３０１が表示される。このボタンをユーザーが押下すると、図５Ｂの処理が開始される。

＜マッピング機能提供処理＞
図５Ｂは本実施の形態に係る、各ＳＳＯマッピング機能への振り分けフローである。図５Ａで表示された、それぞれのＩＤＰに対応したＳＳＯマッピング機能を提供するＵＲＬへの遷移ボタン１３０１をユーザーが押下すると、本フローが開始される。

ステップＳ１１０１でマッピングサーバー３００は、ＩＤＰに対応したＳＳＯマッピング機能を提供するＵＲＬへの遷移ボタンの押下を受け付ける。あるいは遷移ボタンが押下されるとＳ１１０２から処理が開始される。

ステップＳ１１０２でマッピングサーバー３００は、遷移ボタンに紐付けられたＳＳＯマッピング画面ＵＲＬへ、ユーザーをリダイレクトさせる。

ステップＳ１１０３でマッピング機能提供モジュール３０２は、それぞれのＩＤＰに対応したＵＲＬで特定されるＳＳＯマッピング画面を通してＵＲＬごとに固有のＳＳＯマッピング機能を提供し、フローを終了する。ここで、リダイレクト先のＵＲＬで表示される画面は、例えば図１３Ｂに示されるようなマッピング機能提供画面５０１である。設定ファイルをユーザーが指定して設定ボタンを押下すると、設定ファイルが、マッピングサーバーが保持および管理するマッピング情報として設定される。ただし、設定前に、ＵＲＬごと、すなわちＩＤＰごとのＳＳＯマッピング機能により、設定ファイルのマッピングに不都合なものがないかチェックする。ここでこのチェック機能の例をいくつか簡単に説明する。たとえばひとつのマッピング機能では、マッピングサーバー３００が、ＩＤＰとＳＰのそれぞれから、それらが有するユーザーＩＤのリストをテナントごとに取得する。そして入力された設定ファイルに定義されたＩＤＰ用のユーザーＩＤとＳＰ用のユーザーＩＤとの関連付けと照合して、不都合な関連付けがされていないか判定する。不都合な関連付けとは、たとえば、課題の欄で説明したような、ＩＤＰまたはＳＰの相異なる複数のテナントの、他方のひとつのテナントへの関連付けである。この場合には、設定ファイルに定義されたＩＤＰ用のユーザーＩＤとＳＰ用のユーザーＩＤそれぞれの属するテナントを、取得したテナントごとのユーザーＩＤのリストを参照して特定する。そしてＩＤＰまたはＳＰの複数のテナントと関連付けられたＳＰまたはＩＤＰのひとつのテナントがあれば、その設定ファイルは不都合な可能性があるものと判断される。判断の結果は別の画面でクライアントに送信される。不都合な設定を許すか否かは、たとえばサービスプロバイダによる設定に従う。マッピング情報がＩＤＰのエンティティＩＤを単位として管理されている場合、たとえばテナントごとにエンティティＩＤを付与しているＩＤＰに対してはこのようなマッピング機能が適用されるのが望ましい。これに対して、複数のテナントに対して同一のエンティティＩＤを付与するＩＤＰについては、マッピングサーバーにおいても、複数のテナントをまとめてひとつのマッピング情報で管理するため、マッピング情報で複数のテナントどうしが関連付けられる。したがって上述した方法では不都合な関連付けを判定することが困難である。

そこでこのようなＩＤＰについては、上述したチェックに加えて、さらに以下のような判定を行う。すなわち、たとえばＩＤＰあるテナントからユーザーＩＤを削除し、それと同一のユーザーＩＤを他のテナントに追加した場合を考える。上述したようにひとつのテナントがひとつのエンティティＩＤで管理されている場合、マッピングサーバーでは、エンティティＩＤすなわちテナントごとにマッピング情報を管理するために、意図しないマッピングが行われることはない。追加されたユーザーＩＤは、削除されたユーザーＩＤの属するテナントとは異なるテナントのユーザーとしてマッピング情報においても管理されるためである。ところが複数のテナントを一つのエンティティＩＤで管理するＩＤＰの場合、上述のようなユーザーＩＤのテナント間の移動があると、移動後のテナントが、マッピング情報に残っているユーザーＩＤ間の関連付けよって関連付けられてしまうことがあり得る。そこで複数のテナントを一つのエンティティＩＤで管理するＩＤＰについては、ＩＤＰ用のユーザーＩＤとＳＰ用のユーザーＩＤとを直接関連付けず、中間的なＩＤを介して関連付ける。上記のようなテナント間のユーザーＩＤの移動があっても、異動後のユーザーＩＤにはあらたな中間的なＩＤを割り当てることで、不都合な関連付けを防止できる。このように、設定ファイルに定義されたユーザーＩＤの関連付けを、中間的なＩＤを介した関連付けに変換して、マッピング情報として設定する。以上のようにＩＤＰに応じて、マッピング情報の設定は異なるマッピング機能で実現される。ＩＤＰとマッピング機能との関連付けはあらかじめ定められ、図４Ａに示したようなＳＳＯマッピング機能一覧に定義される。このマッピング機能一覧は、マッピングサーバーにあらかじめ登録され、参照される。そのためにたとえば図３のマッピング機能管理モジュールは、クライアントのブラウザからアクセスに応じて、マッピング機能一覧３５０を保守できるように構成してもよい。ＳＳＯマッピング画面およびそのＵＲＬと、そのＳＳＯマッピング画面で指定された設定ファイルをマッピング情報として登録するマッピング機能を実現するプログラムなどは、別途用意しておく必要がある。

図１３Ａ、図１３Ｂは本実施の形態に係る、画面例である。図１３ＡはＩＤＰ一覧表示画面の例を示す。ここでＩＤＰ一覧表示画面５００には、ＩＤＰ−Ａ４００、ＩＤＰ−Ａ−ＴＲＩＡＬ、ＩＤＰ−Ｂ４１０の３つのＩＤＰが表示されている。またそれらのＩＤＰの内で、ＩＤＰ−Ａ４００、ＩＤＰ−Ａ−ＴＲＩＡＬに関しては、マッピング機能を提供するＵＲＬへの遷移ボタン１３０１も表示されている。

図１３Ｂはマッピング機能提供画面の例を示す。ここでマッピング機能提供画面５０１は、ユーザーから、ＳＳＯマッピングの設定に関する設定ファイルのアップロードを受け付ける。またアップロードされた設定ファイルに従いＳＳＯマッピングを実施する。

設定ファイルには、たとえばＳＳＯマッピングされるユーザーＩＤが関連付けて格納されている。たとえば設定ファイルは、当該ユーザーが当該ＩＤＰで認証を受けるためのＩＤＰ用ユーザーＩＤと、ＳＰで認証を受けるためのＳＰ用ユーザーＩＤとが、互いに関連付けられて格納されたファイルである。ここでＩＤＰごとにマッピング方式を変えたことで、本来関連付けるべきでないテナントどうしのマッピングは防止されている。本来関連付けるべきでないテナントとは、たとえば実体となるユーザや企業などが異なっているテナントである。

マッピング機能提供モジュール３０２は、ＩＤＰごとにあらかじめ定めたマッピング方式で、指定された設定ファイルに基づいてＳＳＯマッピングを実施する。たとえば、設定ファイルにおいて定義されているＩＤの対応付けに基づいて、所定の形式のマップファイルとして格納する。

ＳＳＯの手順自体は公知のものである。ここで簡単にＳＳＯの手順の一例を説明する。まずユーザーは、クライアントＰＣのブラウザなどを用いて、アイデンティティプロバイダを兼務する第１のサービスプロバイダにアクセス要求する。アイデンティティプロバイダはユーザーに対して認証要求する。ユーザーの認証はたとえばユーザーＩＤ（ここではアイデンティティプロバイダ用のユーザーＩＤ）とパスワードとを用いる。アイデンティティプロバイダはユーザー認証を行うと、認証したことの証明であるユーザー認証情報（ＳＡＭＬアサーション）を発行し、それを保持する。これは同時にユーザーが認証されて第１のサービスプロバイダへのアクセス要求が受け付けられることでもある。その後、当該ユーザーが第２のサービスプロバイダへのアクセスを要求すると、第２のサービスプロバイダはアイデンティティプロバイダに対して認証要求する。その認証要求に対してアイデンティティプロバイダは、アクセス要求したユーザーのユーザー認証情報すなわちＳＡＭＬアサーションを応答する。ＳＡＭＬアサーションには、当該ユーザーのアイデンティティプロバイダ用のユーザーＩＤと電子署名とが含まれている。電子署名を検証してこのＳＡＭＬアサーションが信頼しているアイデンティティプロバイダで発行されたものであるか判定し、検証が成功すれば当アイデンティティプロバイダ用ユーザーＩＤを読んで、対応するサービスプロバイダ用のユーザーＩＤへの変換をマッチングサーバーに要求する。応答されたユーザーＩＤの権限で、ユーザーは第２のサービスプロバイダへアクセスする。以上のようにしてＳＳＯを実現している。

本実施の形態によれば、マッピングサーバーは、ユーザーが利用可能なＩＤＰを一覧表示させるとともに、それぞれのＩＤＰに対して適切なＳＳＯマッピング機能を対応づけることができる。そのため、ＩＤＰの特性にあわせて、セキュリティを担保するため適切なＳＳＯマッピング機能を提供することができる。

［第２実施形態］
次に、本発明を実施するための第２の形態について図面を用いて説明する。なお第１の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。

図６は本実施の第２の形態に係る、マッピングサーバー３００のモジュール構成図である。マッピングサーバー３００はマッピング機能管理モジュール３０１、マッピング機能提供モジュール３０２、利用ＩＤＰ管理モジュール３０３から構成される。また前処理機能管理モジュール３１１、前処理機能提供モジュール３１２を持つ。１つの前処理機能提供モジュール３１２が複数のＩＤＰに対応した前処理機能を提供してもよく、またＩＤＰごとに異なる前処理機能提供モジュール３１２が存在してもよい。ユーザーがマッピングサーバー３００にアクセスすると、利用ＩＤＰ管理モジュール３０３がユーザーの利用可能なＩＤＰを返す。また前処理機能管理モジュール３１１は、利用ＩＤＰ管理モジュールが返したＩＤＰごとに、対応した前処理機能提供モジュール３１２の機能を提供するＵＲＬを返す。

図７は本実施の第２の形態に係る、データ例である。図７Ａは本実施の第２の形態に係る、マッピング機能管理モジュール３０１が管理するマッピング機能一覧のデータ例である。ここでマッピング機能一覧３６０は、ＩＤＰ−Ｃ４２０に関するマッピング機能情報が追加されている。

図７Ｂは本実施の第２の形態に係る、利用ＩＤＰ一覧管理モジュール３０３が管理する利用ＩＤＰ一覧のデータ例である。ここで利用ＩＤＰ一覧３６１は、テナントＴ００１に所属するユーザーが利用可能なＩＤＰとして、ＩＤＰ−Ｃ４２０が追加されている。

図７Ｃは本実施の第２の形態に係る、前処理機能一覧のデータ例である。前処理機能一覧３６２は、前処理機能管理モジュール３１１が管理するデータであり、複数の前処理機能情報を持つ。個々の前処理機能情報はＩＤＰを特定するＩＤＰ識別子と、そのＩＤＰとのＳＳＯマッピングに先立ち必要な前処理機能が提供される前処理ＵＲＬとを持つ。ここでは、ＩＤＰ−Ａ４００およびＩＤＰ−Ａ−ＴＲＩＡＬについてはマッピングサーバー３００内の画面が前処理機能を持つことを示す。これは例えば、ユーザーがマッピングサーバー３００の画面からＩＤＰ−Ａ４００のＩＤとパスワードを入力する場合が該当する。このときマッピングサーバー３００は、ユーザーの入力にもとづき、ＩＤＰ−Ａ４００が提供するＷｅｂＳｅｒｖｉｃｅなどのＡＰＩを呼び出して認証を受け、認証セッションを受け取る。またここでは、ＩＤＰ−Ｃ４２０に関してはＩＤＰ−Ｃ４２０の画面が前処理機能を持つことを示す。これは例えばＯＡｕｔｈのように、ＩＤＰ−Ｃ４２０が提供する認可画面に一旦ユーザーをリダイレクトさせ、マッピングサーバー３００は、ユーザーが操作するブラウザ経由で、ユーザーが認可した証拠を受け取る場合が該当する。いずれにしても、前処理ＵＲＬにより前処理機能を持つ装置を指定することができる。

＜ＩＤＰ一覧表示および前処理＞
図８は本実施の第２の形態に係る、前処理も含むＳＳＯマッピングのための機能の一覧表示および各ＳＳＯマッピング機能への振り分けフローである。

図８Ａは本実施の第２の形態に係る、前処理も含むＳＳＯマッピングのための機能の一覧表示のフローである。ユーザーがマッピングサーバー３００にアクセスすると、そのユーザーが利用可能なＩＤＰが、それぞれ対応した前処理機能の提供画面への遷移ボタンとともに一覧表示される。

ステップＳ１００１からステップＳ１００４までは、第１の実施の形態と共通のため、説明を省略する。ステップＳ１００４が完了すると、フローはステップＳ２００１に遷移する。

ステップＳ２００１でマッピングサーバー３００は、ステップＳ１００４で取り出したマッピング機能情報を確認し、マッピングサーバー３００がＳＳＯマッピングを管理しているか判断する。判断の結果、マッピングサーバー３００がＳＳＯマッピングを管理するのであればステップＳ２００２に遷移する。マッピングサーバー３００がＳＳＯマッピングを管理しないのであれば、そのＩＤＰに関する処理を終了し、ステップＳ１００２に遷移する。たとえばステップＳ１００４で取り出したマッピング機能情報がＩＤＰ−Ａ４００に関するものであった場合、ＩＤＰ−Ａ４００はマッピングサーバー３００がＳＳＯマッピングを管理するため、ステップＳ２００２に遷移する。

ステップＳ２００２でマッピングサーバー３００は、前処理機能管理モジュール３１１から、前処理機能を提供する画面のＵＲＬを取り出す。

ステップＳ２００３でマッピングサーバー３００は、ステップＳ２００２で取り出したＵＲＬを、ステップＳ１００３で取り出したＩＤＰの識別子とともに、画面表示させる。以上でそのＩＤＰに関する処理を終了し、ステップＳ１００２に遷移する。

図８Ａのフローが完了した際に画面に表示されるのは、例えば図１４Ａに示されるようなＩＤＰ一覧表示画面５１０である。

図８Ｂは本実施の第２の形態に係る、各前処理機能への振り分けフローである。図８Ａで表示された、それぞれのＩＤＰに対応した前処理機能を提供するＵＲＬへの遷移ボタンをユーザーが押下すると、本フローが開始される。

ステップＳ２１０１でマッピングサーバー３００は、ＩＤＰに対応した前処理機能を提供するＵＲＬへの遷移ボタンの押下を受け付ける。

ステップＳ２１０２でマッピングサーバー３００は、ステップＳ２１０１で押下されたボタンに紐付けられたＵＲＬが、マッピングサーバー側のＵＲＬか、ＩＤＰ側のＵＲＬか判断する。判断の結果、マッピングサーバー側のＵＲＬであれば、マッピングサーバー３００が前処理機能を提供するためにステップＳ２１０３に遷移する。またＩＤＰ側のＵＲＬであれば、ＩＤＰの前処理機能を利用するためにステップＳ２１５０に遷移する。

ステップＳ２１０３でマッピングサーバー３００は、マッピングサーバー側で前処理機能を提供するために、ステップＳ２１０１で押下されたボタンに紐付けられたＵＲＬにユーザーのアクセスをリダイレクトさせる。

ステップＳ２１０４でマッピングサーバー３００の前処理機能提供モジュール３１２は、前処理を実施し、ＩＤＰの認証セッションを受け取る。

ステップＳ２１０５でマッピングサーバー３００は、マッピング機能管理モジュール３０１から、ステップＳ２１０４で前処理を行ったＩＤＰに対応するマッピング機能情報を取り出す。

ステップＳ２１０６でマッピングサーバー３００は、ステップＳ２１０５で取り出したマッピング機能情報から、マッピング機能を提供するＵＲＬを取り出す。

ステップＳ２１０７でマッピングサーバー３００は、ステップＳ２１０６で取り出したＵＲＬに対して、ユーザーのアクセスをリダイレクトさせる。

ステップＳ２１０８でマッピングサーバー３００は、ステップＳ２１０７のリダイレクトを受け、ステップＳ２１０４の前処理で取得した認証セッションを用いて、ＩＤＰのＡＰＩを呼び出す。

ステップＳ２１０９でマッピングサーバー３００のマッピング機能提供モジュール３０２は、ステップＳ２１０８のＡＰＩ呼び出しに対して返された値を用いて、ＳＳＯマッピングを生成する。その際、図１３Ｂに示されるような画面を表示させ、ユーザーから、ＳＳＯマッピングの設定に関するファイルのアップロードを受け付けてもよい。ステップＳ２１０９でＳＳＯマッピングの生成が完了すると、フローを終了する。

ステップＳ２１５０でマッピングサーバー３００は、ＩＤＰの前処理機能を利用するために、ステップＳ２１０１で押下されたボタンに紐付けられたＵＲＬにユーザーのアクセスをリダイレクトさせてフローを終了する。

＜前処理手順の例＞
図９は本実施の第２の形態に係る、前処理の例およびＳＳＯマッピング機能のフローである。図９Ａは本実施の第２の形態に係る、マッピングサーバー３００におけるＩＤＰに対応した前処理の例である。このフローは図８ＢのステップＳ２１０４の詳細なフローである。この例で前処理機能提供モジュール３１２は、ユーザーに、ＩＤＰにログインするためのＩＤとパスワードの入力を求める。またユーザーに入力されたＩＤとパスワードを用いてＩＤＰの認証を受け、認証セッションを受け取る。

ステップＳ２２０１で前処理機能提供モジュール３１２は、図１４Ｂに示されるような第１の前処理機能提供画面５１１を表示させ、ＩＤＰにログインするためのＩＤとパスワードの入力を受け付ける。

ステップＳ２２０２で前処理機能提供モジュール３１２は、ステップＳ２２０１で受け付けたＩＤとパスワードを用いて、ＩＤＰにアクセスする。

ステップＳ２２０３で前処理機能提供モジュール３１２は、ＩＤＰの認証を受け、ステップＳ２２０２におけるＩＤＰへのアクセスの応答として認証セッションを受け取る。認証セッションを受け取ると本フローは終了する。

図９Ｂは本実施の第２の形態に係る、ＩＤＰ側の前処理の例である。このフローは、ＩＤＰが、図８ＢのステップＳ２１５０でリダイレクトされたユーザーのアクセスを受けることで開始される。この例では、リダイレクトを受けるＩＤＰはＩＤＰ−Ｃ４２０であるとする。またＩＤＰ−Ｃ４２０では、ＯＡｕｔｈの認可の仕組みが利用可能であるとする。

ステップＳ２３０１でＩＤＰ−Ｃ４２０は、マッピングサーバー３００からリダイレクトされたユーザーのアクセスを受け付ける。

ステップＳ２３０２でＩＤＰ−Ｃ４２０は、ステップＳ２３０１で受け付けたアクセスの認証を行う。ここで例えば、ＩＤＰ−Ｃ４２０は、ユーザーに対してＩＤとパスワードの入力を求めてもよい。

ステップＳ２３０３でＩＤＰ−Ｃ４２０は、ステップＳ２３０２の認証が成功したか判断する。認証に成功していたらステップＳ２３０４に遷移する。また認証に失敗していたらステップＳ２３５０に遷移する。

ステップＳ２３０４でＩＤＰ−Ｃ４２０は、マッピングサーバー３００によるＳＳＯマッピングの実施を許可するかを問う画面を表示させ、ユーザーの許可を求める。ここで表示される画面は、例えば図１４Ｃに示されるような第２の前処理機能提供画面５１２であってもよい。

ステップＳ２３０５でＩＤＰ−Ｃ４２０は、ステップＳ２３０４でユーザーの許可を得られたか判断する。ユーザーの許可が得られていた場合にはステップＳ２３０６に遷移する。またユーザーの許可が得られていなかった場合にはステップＳ２３５０に遷移する。

ステップＳ２３０６でＩＤＰ−Ｃ４２０は、認可トークンを生成し、ユーザーのアクセスをマッピングサーバー３００にリダイレクトさせる。このときリダイレクトは認可トークンを含み、認可トークンはユーザーが操作するクライアントを介してマッピングサーバー３００に返される。なおここでリダイレクト先のＵＲＬは、マッピングサーバー３００がマッピング機能を提供するＵＲＬであるとする。ユーザーのアクセスをマッピングサーバー３００にリダイレクトさせると本フローは終了する。

ステップＳ２３５０でＩＤＰ−Ｃ４２０は、ユーザーからのアクセスをマッピングサーバー３００にリダイレクトさせる。またこのとき、リダイレクトはユーザーが操作するクライアントを介して行われ、リダイレクトには前処理が失敗したことを示す情報が含まれる。ユーザーのアクセスをマッピングサーバー３００にリダイレクトさせると本フローは終了する。

図９Ｃは本実施の第２の形態に係る、ＩＤＰ側の前処理後のマッピングサーバー３００における処理のフローの例である。このフローはマッピングサーバー３００が、図９ＢのステップＳ２３０６でリダイレクトされたユーザーのアクセスを受けることで開始される。

ステップＳ２４０１でマッピングサーバー３００は、マッピング機能を提供するＵＲＬへのリダイレクトを、ＩＤＰから受け付ける。

ステップＳ２４０２でマッピングサーバー３００は、ステップＳ２４０１で受け付けたリダイレクトに含まれる認可トークンを取り出す。

ステップＳ２４０３でマッピングサーバー３００は、ステップＳ２４０２で取り出した認可トークンを用いて、ＩＤＰのＡＰＩを呼び出す。

ステップＳ２４０４でマッピングサーバー３００のマッピング機能提供モジュール３０２は、ステップＳ２４０３の応答としてＩＤＰのＡＰＩから返された値を用いて、ＳＳＯマッピングを生成する。その際、ＩＤＰに対応したマッピング機能情報からＳＳＯマッピング画面ＵＲＬを取り出し、そのＵＲＬで特定される図１３Ｂに示されるような画面を表示させ、ユーザーから、ＳＳＯマッピングの設定に関するファイルのアップロードを受け付けてもよい。ステップＳ２４０４でＳＳＯマッピングの生成が完了すると、フローを終了する。

＜第２実施形態の表示画面の例＞
図１４は本実施の第２の形態に係る、画面例である。図１４ＡはＩＤＰ一覧表示画面の例を示す。ここでＩＤＰ一覧表示画面５１０には、ＩＤＰ−Ａ４００、ＩＤＰ−Ａ−ＴＲＩＡＬ、ＩＤＰ−Ｂ４１０およびＩＤＰ−Ｃの４つのＩＤＰが表示されている。またそれらのＩＤＰの内で、ＩＤＰ−Ａ４００、ＩＤＰ−Ａ−ＴＲＩＡＬおよびＩＤＰ−Ｃに関しては、ＳＳＯマッピングの前処理機能を提供するＵＲＬへの遷移ボタンも表示されている。

図１４Ｂは前処理機能提供画面の１つ目の例を示す。ここで第１の前処理機能提供画面５１１は、ユーザーから、ＩＤＰにログインするためのＩＤおよびパスワードの入力を受け付ける。また入力されたＩＤおよびパスワードに従い、前処理機能提供モジュール３１２がＩＤＰの認証受け、認証セッションを受け取る。

図１４Ｃは前処理機能提供画面の２つ目の例を示す。ここで第２の前処理機能提供画面５１２はＯＡｕｔｈにおける認可の画面であり、ユーザーに対して、マッピングサーバー３００によるＳＳＯマッピングを許可するかを問う。ここでユーザーが「許可」ボタンを押下すると、ＯＡｕｔｈに従い、認可トークンが発行される。また発行された認可トークンはマッピングサーバー３００に渡される。

以上のように、ＩＤＰごとに、マッピング機能のみならず前処理についてもあらかじめ定めた処理を実行させることが可能となる。本実施の第２の形態によれば、ＩＤＰごとに適当な方式で前処理を実施した上で、ＳＳＯマッピングを実施する際にＩＤＰのＡＰＩを呼ぶことが可能となる。そのためＩＤＰごとのポリシーによって、ＩＤとパスワードによる認証が求められる場合や、ＯＡｕｔｈの認可の仕組みを利用する場合でも、適切な前処理が実施できる。

［第３の実施形態］
次に、本発明を実施するための第３の形態について図面を用いて説明する。なお第１の実施の形態および第２の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。

図１０は本実施の第３の形態に係る、マッピングサーバー３００のモジュール構成図である。マッピングサーバー３００はマッピング機能管理モジュール３０１、マッピング機能提供モジュール３０２、利用ＩＤＰ管理モジュール３０３から構成される。また前処理機能提供モジュール３１２、および第２の前処理機能管理モジュール３２１を持つ。第２の前処理管理モジュール３２１は第２の前処理機能一覧３７０を持ち、１つのＩＤＰに対して複数の前処理ＵＲＬを記憶することができる。またユーザーに対してそれら複数の前処理ＵＲＬを提示することで、ユーザーが望む前処理ＵＲＬを選択および利用できるようにする。

図１１は本実施の第３の形態に係る、第２の前処理機能一覧のデータ例である。第２の前処理機能一覧３７０は第２の前処理機能管理モジュール３２１が管理するデータである。ここで第２の前処理機能一覧３７０は複数の第２の前処理機能情報を持つ。また個々の第２の前処理機能情報は、ＩＤＰを特定するＩＤＰ識別子と、そのＩＤＰとのＳＳＯマッピングに先立ち必要な前処理機能が提供される前処理ＵＲＬと、さらに前処理の種別を表す前処理種別を持つ。

ここでは、ＩＤＰ−Ａ４００についてはマッピングサーバー３００内の画面が前処理機能を持つとともに、ＩＤＰ−Ａ４００の画面が前処理機能を持つことを示す。これは例えば、図１４Ｂに示されるようなＩＤとパスワードを入力する前処理機能と、図１４Ｃに示されるようなＯＡｕｔｈによる前処理機能とが提供され、ユーザーがいずれかを選択できる場合を示す。

図１２は本実施の第３の形態に係る、マッピング機能の一覧表示のフローである。ユーザーがマッピングサーバー３００にアクセスすると、そのユーザーが利用可能なＩＤＰが、それぞれ対応した前処理機能の提供画面への遷移ボタンとともに一覧表示される。

ステップＳ１００１からステップＳ１００４までは、第１の実施の形態と共通のため、説明を省略する。ステップＳ１００４が完了すると、フローはステップＳ３００１に遷移する。

ステップＳ３００１でマッピングサーバー３００は、ステップＳ１００４で取り出したマッピング機能情報を確認し、マッピングサーバー３００がＳＳＯマッピングを管理しているか判断する。判断の結果、マッピングサーバー３００がＳＳＯマッピングを管理するのであればステップＳ３００２に遷移する。マッピングサーバー３００がＳＳＯマッピングを管理しないのであれば、そのＩＤＰに関する処理を終了し、ステップＳ１００２に遷移する。たとえばステップＳ１００４で取り出したマッピング機能情報がＩＤＰ−Ａ４００に関するものであった場合、ＩＤＰ−Ａ４００はマッピングサーバー３００がＳＳＯマッピングを管理するため、ステップＳ３００２に遷移する。

ステップＳ３００２でマッピングサーバー３００は、第２の前処理機能管理モジュール３２１から、処理中のＩＤＰに対応するすべての第２の前処理機能情報を取り出す。たとえばここで処理中のＩＤＰがＩＤＰ−Ａ４００であったとすると、取り出される第２の前処理情報は、前処理種別が「ＩＤ／Ｐａｓｓｗｏｒｄ」のものと「ＯＡｕｔｈ」のものの２つである。

ステップＳ３００３でマッピングサーバー３００は、ステップＳ３００２で取り出したすべての第２の前処理機能情報から、それぞれの前処理機能を提供するＵＲＬと前処理種別を取り出す。

ステップＳ３００４でマッピングサーバー３００は、ステップＳ３００３で取り出した前処理機能を提供するＵＲＬのそれぞれに対し、対応する遷移ボタンを画面表示させる。またそれぞれのボタンは、対応するＩＤＰの識別子と、さらに前処理種別を表す文言とともに表示される。以上でそのＩＤＰに関する処理を終了し、ステップＳ１００２に遷移する。

図１２のフローが完了した際に画面に表示されるのは、例えば図１５に示されるようなＩＤＰ一覧表示画面５２０である。

図１５は本実施の第３の形態に係る、ＩＤＰ一覧表示画面の例を示す。ここでＩＤＰ一覧表示画面５２０には、ＩＤＰ−Ａ４００、ＩＤＰ−Ａ−ＴＲＩＡＬ、ＩＤＰ−Ｂ４１０およびＩＤＰ−Ｃの４つのＩＤＰが表示されている。またそれらのＩＤＰの内で、ＩＤＰ−Ａ４００に関しては、ＩＤとパスワードによる前処理機能の画面への遷移ボタンと、ＯＡｕｔｈによる前処理機能の画面への遷移ボタンの、２つの遷移ボタンが表示されている。

ＩＤＰ一覧表示画面５２０が表示されたときにユーザーは、ＩＤＰ−Ａに対するＳＳＯマッピングを実施する際に、ＩＤとパスワードによる前処理とＯＡｕｔｈによる前処理の、２つの前処理の内で、自らの望む前処理でＳＳＯマッピングを実施することができる。

本実施の第３の形態によれば、同一のＩＤＰで複数の前処理が利用可能な場合に、ユーザーの選択に従い、ＳＳＯマッピング時の前処理を実施することができるようになる。
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims

認証サーバーがユーザーを認証したことを示すユーザー認証情報を、他のサーバーにおける前記ユーザーのユーザーＩＤと関連付けて当該サーバーへのアクセスを許すシングルサインオンシステムにおいて、ユーザーＩＤを関連付けたマッピング情報を提供するマッピングサーバーであって、
前記ユーザーＩＤの関連付けを行うマッピング機能を、各認証サーバーに関連付けて登録したマッピング機能情報と、
前記マッピング機能を実行する前に行うべき前処理を、前記認証サーバーごとに関連付けて登録した前処理機能情報と、
前記マッピング機能情報を参照して、前記マッピング機能に関連付けられた認証サーバーの選択を受け付ける受け付け手段と、
前記選択された認証サーバーに関連付けられたマッピング機能に応じた処理を実行して前記マッピング情報を構成する実行手段と
を有し、
前記実行手段は、前記前処理機能情報を参照して、前記選択された認証サーバーに関連付けられた前処理機能が前記認証サーバーにより実行される場合には、当該前処理機能を実行し、さらに前記選択された認証サーバーに関連付けられたマッピング機能に応じた処理を実行して前記マッピング情報を構成することを特徴とするマッピングサーバー。
前記受け付け手段は、前記マッピング機能情報を参照して、前記認証サーバーの識別子と、認証サーバーごとに関連付けられたマッピング機能へのリンクを埋め込んだオブジェクトとを関連付けて、前記マッピングサーバーへアクセスしているクライアントにユーザーインターフェースとして表示させることを特徴とする請求項１に記載のマッピングサーバー。
前記実行手段は、前記選択された認証サーバーに関連付けられた前処理機能が前記認証サーバーにより実行される場合には、前記認証サーバーにより前処理を実行させ、該前処理の結果を取得して、前記選択された認証サーバーに関連付けられたマッピング機能に応じた処理を実行して前記マッピング情報を構成することを特徴とする請求項１または２に記載のマッピングサーバー。
前記前処理機能は、前記マッピングサーバーによるマッピングの実行に対するユーザーによる許可を、前記認証サーバーを介して受ける機能であり、前記前処理の結果は、認可トークンとして受け取ることを特徴とする請求項３に記載のマッピングサーバー。
前記マッピング情報はエンティティＩＤを持つエンティティ単位で管理され、前記ユーザーＩＤはユーザーが属するテナントごとに管理され、
前記実行手段は、選択された認証サーバーに応じて、ひとつのエンティティＩＤについて、関連付けられるユーザーＩＤが複数のテナントにわたっていないことチェックするマッピング機能と、互いに関連付けられるユーザーＩＤを、中間的なＩＤを介して関連付けたマッピング情報を生成するマッピング機能とを含むことを特徴とする請求項１乃至４のいずれか一項に記載のマッピングサーバー。
請求項１乃至５のいずれか一項に記載のマッピングサーバーと、前記認証サーバーと、そのほかのサーバーとを含むシングルサインオンシステム。
認証サーバーがユーザーを認証したことを示すユーザー認証情報を、他のサーバーにおける前記ユーザーのユーザーＩＤと関連付けて当該サーバーへのアクセスを許すシングルサインオンシステムにおいて、ユーザーＩＤを関連付けたマッピング情報を提供するマッピングサーバーとしてコンピュータを機能させるためのプログラムであって、
前記ユーザーＩＤの関連付けを行うマッピング機能を、各認証サーバーに関連付けて登録したマッピング機能情報を格納する手段と、
前記マッピング機能を実行する前に行うべき前処理を、前記認証サーバーごとに関連付けて登録した前処理機能情報を格納する手段と、
前記マッピング機能情報を参照して、前記マッピング機能に関連付けられた認証サーバーの選択を受け付ける受け付け手段と、
前記選択された認証サーバーに関連付けられたマッピング機能に応じた処理を実行して前記マッピング情報を構成する実行手段と
してコンピュータを機能させるためのプログラムであって、
前記実行手段は、前記前処理機能情報を参照して、前記選択された認証サーバーに関連付けられた前処理機能が前記認証サーバーにより実行される場合には、当該前処理機能を実行し、さらに前記選択された認証サーバーに関連付けられたマッピング機能に応じた処理を実行して前記マッピング情報を構成することを特徴とするプログラム。
認証サーバーがユーザーを認証したことを示すユーザー認証情報を、他のサーバーにおける前記ユーザーのユーザーＩＤと関連付けて当該サーバーへのアクセスを許すシングルサインオンシステムにおいて、ユーザーＩＤを関連付けたマッピング情報を提供するマッピングサーバーにより実行されるマッピング機能提供方法であって、
前記ユーザーＩＤの関連付けを行うマッピング機能を、各認証サーバーに関連付けて登録したマッピング機能情報を参照して、前記マッピング機能に関連付けられた認証サーバーの選択を受け付ける受け付け工程と、
前記選択された認証サーバーに関連付けられたマッピング機能に応じた処理を実行して前記マッピング情報を構成する実行工程と
を有し、
前記実行工程では、前記マッピング機能を実行する前に行うべき前処理を前記認証サーバーごとに関連付けて登録した前処理機能情報を参照して、前記選択された認証サーバーに関連付けられた前処理機能が前記認証サーバーにより実行される場合には、当該前処理機能を実行し、さらに前記選択された認証サーバーに関連付けられたマッピング機能に応じた処理を実行して前記マッピング情報を構成することを特徴とするマッピング機能提供方法。