JP6066586B2 - 情報処理システム、その制御方法、およびそのプログラム。 - Google Patents

情報処理システム、その制御方法、およびそのプログラム。 Download PDF

Info

Publication number
JP6066586B2
JP6066586B2 JP2012116625A JP2012116625A JP6066586B2 JP 6066586 B2 JP6066586 B2 JP 6066586B2 JP 2012116625 A JP2012116625 A JP 2012116625A JP 2012116625 A JP2012116625 A JP 2012116625A JP 6066586 B2 JP6066586 B2 JP 6066586B2
Authority
JP
Japan
Prior art keywords
information
processing system
information processing
user
provider
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2012116625A
Other languages
English (en)
Other versions
JP2013242776A (ja
Inventor
勇人 松ヶ下
勇人 松ヶ下
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP2012116625A priority Critical patent/JP6066586B2/ja
Priority to US13/898,166 priority patent/US9027107B2/en
Publication of JP2013242776A publication Critical patent/JP2013242776A/ja
Application granted granted Critical
Publication of JP6066586B2 publication Critical patent/JP6066586B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations

Description

本発明は、異なるドメイン間においてシングルサインオンを実現する情報処理システム、その制御方法、およびそのプログラムに関する。
従来、異なるドメイン下に存在する複数のサーバー間で認証を連携させる技術として、Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（以下ＳＡＭＬ）によるシングルサインオン （以下ＳＳＯ） の仕組みが知られている。
ＳＡＭＬのＳＳＯにおいては、ユーザーに対し認証情報の入力を要求し、入力された認証情報を基に認証を行うサーバーを含む情報処理システム（Ｉｄｅｎｔｉｔｙ Ｐｒｏｖｉｄｅｒ、以下 ＩＤプロバイダ）と、ＩＤプロバイダの認証結果を信頼し、認証情報を基にした認証を行うことなくサービスを提供するサーバーを含む情報処理システム（Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ、以下 サービスプロバイダ）からなる。ユーザーがサービスプロバイダのサービスを受ける場合、ＩＤプロバイダにアクセスし認証を受ける必要がある。例えばユーザーは、ＩＤプロバイダにて管理されているユーザーＩＤ、およびパスワードと言ったユーザー認証情報を基にＩＤプロバイダで認証される。
そしてＩＤプロバイダは、認証したことの証明であるアサーションをサービスプロバイダ向けに発行する。サービスプロバイダは、このアサーションが信頼しているＩＤプロバイダで発行されたものであるか否かを検証することでユーザーを認証する。検証の結果に応じて、ユーザーはサービスプロバイダで管理されている認証情報を入力することなくサービスプロバイダで認証を受けることが可能となり、サービスプロバイダのサービスを受けることができる。
上述のように、ＳＡＭＬのＳＳＯは、ＩＤプロバイダとサービスプロバイダの信頼関係によって成り立っている。そのため、ＳＳＯを実現する前に、事前にＩＤプロバイダとサービスプロバイダ間で信頼関係を結んでいる必要がある。この信頼関係は、ＳＡＭＬにおける複数の機能の内どの機能によってＳＳＯを行うのかを記述したメタデータと、アサーションがＩＤプロバイダから発行された事を証明するための電子証明書の交換によって成立する。メタデータの具体的な内容、およびこの信頼関係の結び方に関する技術は標準技術であるＳＡＭＬ Ｖ２．０において定義されている。メタデータ、および電子証明書のようにアサーションの検証を行うために必要な情報を事前情報と称する。サービスプロバイダは、アサーションが要件を満たすか否かを検証する際、事前情報を利用して検証を行う。また、事前情報は、一般的にＩＤプロバイダにより発行されるデータである。
ＳＡＭＬは、ユーザーがＩＤプロバイダによって認証されたことの検証の他に、そのＩＤプロバイダがサービスプロバイダから見て信頼できるＩＤプロバイダであるか否かも検証する。これにより、セキュアなＳＳＯが実現される。信頼できるＩＤプロバイダであるか否かの具体的な判断方法は、サービスプロバイダがＩＤプロバイダで発行されたアサーションの署名を事前に設定した電子証明書を用いて検証する事で実現する。
ユーザーの認証回数を省くメリットがあるＳＳＯであるが、課題も存在する。ＳＡＭＬの設定、例えばＩＤプロバイダにおけるユーザーとサービスプロバイダにおけるユーザーの関係を誤って紐付けてしまった場合、ＩＤプロバイダで認証を受けたユーザーは本来のユーザーとは別のユーザーとしてサービスプロバイダで認証されてしまう。結果ユーザーは、サービスプロバイダにおける別のユーザーとして認証されてサービスプロバイダの機能提供を受けてしまう事になる。認証されたユーザーは、サービスプロバイダが管理している本来のユーザーではない状態でサービスを受けることになり、サービス提供者にとっても、そのユーザーにとっても不利益となる。つまりＳＡＭＬの仕組みを安全に利用するためには、信頼関係を誤ることなく安全に結んでおく必要がある。
従来、このＩＤプロバイダ、サービスプロバイダ間での信頼関係の設定方法として特許文献１の方法が提案されている。特許文献１は、動的に配備されるデバイスと、サービス提供サーバーとの信頼関係をセキュアに構築するＳＳＯに関する技術である。信頼関係を構築する際に、サービス提供サーバーは、メタデータの署名を認証局で検証させることで、メタデータを動的に登録しながらもセキュアなＳＳＯを実現する。
特開２００９−１１８１１０
先行技術によって、ＳＳＯの信頼関係の動的な構築が可能となる。しかしながら、先行技術は、ＩＤプロバイダであるサービス提供サーバーのみに対する信頼関係の構築についての技術であるため、サービスプロバイダに対する信頼関係の構築については考慮されていない。特に、事前情報の管理方法が夫々異なる複数のＩＤプロバイダとサービスプロバイダがＳＳＯ連携することが今後想定されるため、適正なサービスプロバイダの構築が望まれる。
本願発明の目的は、事前情報の管理方法が夫々異なる複数のＩＤプロバイダとサービスプロバイダがＳＳＯ連携することを想定し、サービスプロバイダの適正な構築を行うことにある。
本願発明の目的を達成するサービスプロバイダ、即ち、情報処理システムは、ユーザーから入力されたユーザー認証情報を用いたユーザー認証処理を行う第１の情報処理システムと通信可能な第２の情報処理システムであって、前記ユーザー認証処理が成功したことに応じて前記第１の情報処理システムにより発行され送信される認可情報を、前記第１の情報処理システムにより発行されたことを証明するための電子証明書を少なくとも含む事前情報を用いて署名検証する検証手段と、前記検証の結果、送信された前記認可情報が前記第１の情報処理システムにより発行された認可情報であることが少なくとも確認された場合に、前記ユーザー認証処理を行うことなくサービスを提供する提供手段と、ユーザー認証処理を行う第１の情報処理システムを登録する指示を前記ユーザーから受け付けた際に、該第１の情報処理システムが前記事前情報をグループ毎に管理する情報処理システムであるか、または前記事前情報を複数のグループで共有させて管理する情報処理システムであるかを判断する判断手段と、前記判断手段により該第１の情報処理システムが前記事前情報をグループ毎に管理する情報処理システムであると判断された場合は、前記事前情報を受け付け可能な第１の方法で前記ユーザーのテナントＩＤと該第１の情報処理システムのエンティティＩＤと受け付けた前記事前情報とを関連付けて保存する登録処理を行い、前記判断手段により該第１の情報処理システムが前記事前情報を複数のグループで共有させて管理する情報処理システムであると判断された場合は、前記事前情報を受け付け不可能な第２の方法で前記ユーザーのテナントＩＤと該第１の情報処理システムのエンティティＩＤと予め保有する前記事前情報とを関連付けて保存する登録処理を行うことを特徴とする。
本願発明により、事前情報の管理方法が夫々異なる複数のＩＤプロバイダとのＳＳＯ連携を想定したサービスプロバイダが提供される。
システム構成図。 各装置のハードウェア構成図。 Ｗｅｂアプリケーションサーバーのソフトウェア構成図。 ログイン制御サーバーのソフトウェア構成図。 データベースサーバーのソフトウェア構成図。 データベースサーバーのテーブル構造。 シングルサインオンのシーケンス図。 ＩＤプロバイダ登録画面。 ＩＤプロバイダ登録処理のフローチャート。 ＩＤプロバイダ選択画面。 重複登録判断のフローチャート。
始めに、本願発明におけるサービスプロバイダについて説明する。
本願発明におけるサービスプロバイダは、マルチテナントに対応したサービスプロバイダであり、テナント毎でデータを管理する。よって、サービスプロバイダは事前情報もテナント毎に管理する。テナントとは特定のグループを指す用語であり、例えば、従来の専用サーバーを用いてサービスを受けていた企業や組織と言ったグループの単位を意味する。マルチテナント構成の情報処理システムは、例えば、１つのＨＤＤに複数テナントの情報を管理するため、論理的にデータを分断するパーティション機能を有している。結果、複数のテナントのデータが同じＨＤＤ内に共存する形となる。
次に、本願発明におけるＩＤプロバイダとサービスプロバイダの関係を説明する。
サービスプロバイダから見た場合、ＩＤプロバイダはＥｎｔｉｔｙ ＩＤと呼ばれるＩＤで識別される。このＥｎｔｉｔｙ ＩＤは事前に交換した上述のメタデータに記載されており、メタデータに記載されたＥｎｔｉｔｙ ＩＤを参照することでＩＤプロバイダを特定することができる。本願発明における夫々のＩＤプロバイダは、ＩＤプロバイダ内にある認証機能を提供するサーバーが次の様に構成が異なる。１つ目は、認証機能を提供するサーバーが単一のＥｎｔｉｔｙ ＩＤしか持たないサーバーであり、２つ目は、複数のＥｎｔｉｔｙ ＩＤを持てるサーバーである。Ｅｎｔｉｔｙ ＩＤが単一か複数かはＩＤプロバイダによって異なる。後者の場合、ＩＤプロバイダとサーバーが１対１で対応せず多数対１の関係になるため、ＩＤプロバイダはサーバーを特定する用語ではあるが、１台のサーバーを指す用語ではないことに注意して頂きたい。では、なぜこのようにＩＤプロバイダ毎にＥｎｔｉｔｙ ＩＤの持ち方に違いが発生するのかについて説明する。
例えばＳＡＭＬはＨＴＴＰで実現されるため、エンドポイントとなるＩＤプロバイダはＵＲＬで定義される。また、アサーションを署名するためにＥｎｔｉｔｙ ＩＤごとに異なる電子証明書が必要となるが、電子証明書はホスト名に紐づけて発行される。結果、ＩＤプロバイダが複数のＥｎｔｉｔｙ ＩＤを持つためにはＥｎｔｉｔｙ ＩＤごとに異なるホスト名を持ち、またそれらのホスト名のＩＰアドレスが解決できる必要がある。ＩＤプロバイダがユーザーの求めに応じ動的にＥｎｔｉｔｙ ＩＤを追加するのであれば、ＩＤプロバイダがＤＮＳサーバーを備え、Ｅｎｔｉｔｙ ＩＤの追加に対応して新しいホスト名とＩＰアドレスをＤＮＳサーバーに登録するなどの作業が必要になる。よってＩＤプロバイダが複数のＥｎｔｉｔｙ ＩＤを持つには比較的規模の大きなＩＤプロバイダでないと対応が難しい。しかし、例えば、Ｅｎｔｉｔｙ ＩＤをテナント毎に変えることが可能となるので、よりセキュアなＳＳＯを実現できる。
一方、ＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）など第三者にサービスを提供するケースでは、第三者からのアクセスを特定のＵＲＬに限定することで利便性や安全性を向上させることがある。このような場合は、ＵＲＬが単一になり、Ｅｎｔｉｔｙ ＩＤも単一になる。
次に、本願発明の具体的な課題の１つについて詳細に説明する。従来、サービスプロバイダであるサーバーが、複数の組織で利用されるマルチテナント構成である事は考慮されていない。結果、以下のような課題がある。サービスプロバイダをマルチテナント構成とした場合、テナント毎にＩＤプロバイダとの信頼関係を構築する必要がある。しかしながら、ＩＤプロバイダとしての認証機能を提供するサーバーが単一のＥｎｔｉｔｙ ＩＤしか持たない場合は、複数のテナントで一つのＥｎｔｉｔｙ ＩＤを共有する構成となる。そのため、ＩＤプロバイダとの信頼関係を動的に設定変更すると、他のテナントで設定していた信頼関係が無効になってしまうという課題が発生する。
また、その他の課題もある。ＩＤプロバイダとしての認証機能を提供するサーバーが複数のＥｎｔｉｔｙ ＩＤを持てるものであった場合は、セキュリティ要件が求められているため、テナント毎にＩＤプロバイダとの信頼関係を動的に構築する必要がある。ここで、既に特定のテナントでＩＤプロバイダと信頼関係を構築している場合は、新規に他のテナントと当該ＩＤプロバイダとの信頼関係を構築してしまうと、関係しない複数のテナント間で間接的に信頼関係が構築されてしまう。結果、意図しないＳＳＯが行われるリスクが発生する。
以上からお分かり頂ける通り、テナント毎にデータを管理するマルチテナント構成のサービスプロバイダが、事前情報の管理方法が異なる複数のＩＤプロバイダとＳＳＯ連携するためには、考慮しなくてはならない課題が幾つかあるということである。
次に、本願発明で用いられる用語の定義について説明する。
ユーザー認証とは、ユーザーから入力されたユーザー認証情報を用いた認証を指す。このユーザー認証の処理を行う情報処理システムは、未だ認証を受けていないユーザーからのアクセスに応じて認証画面を提供し、その認証画面を介して入力されたユーザー認証情報を受信し、受信したユーザー認証情報を基に正規なユーザーであるか否かを検証する。本願発明における、ＩＤプロバイダに相当する情報処理システム、およびサービスプロバイダに相当する情報処理システムは、何れもこのユーザー認証処理を行う機能を有する。しかしながら、サービスプロバイダは、ＩＤプロバイダの認証処理の結果を信頼するため、このユーザー認証処理を行うことなくサービスを提供する。これこそが、ＳＳＯ、特にＳＡＭＬのユーザーメリットである。
なお、情報処理システムとは、ユーザー認証処理を行う少なくとも１台のログイン制御サーバーと、ログイン制御サーバーによるユーザー認証処理が成功したことに応じてサービスを提供するサーバーとを含むシステムを指す。しかしながら、それらのサーバーを１台に集約した形態も想定されるため、情報処理システムと称する場合、必ずしも複数台のサーバーから構成されるとは限らない。また、情報処理システムは、ログイン制御サーバーのみから構成されていても良い。
認可情報とは、ＩＤプロバイダがユーザー認証処理を行い、ユーザー認証処理が成功したことに応じて発行するデータであり、ＳＡＭＬにおけるアサーションがこれに該当する。本願発明における認可情報はアサーションと同義であるが、認可情報の形態は必ずしもＳＡＭＬで定義されたアサーションのフォーマットに限るものではない。よって、認可情報と称する場合は、サービスプロバイダがＩＤプロバイダの認証結果を信頼するために用いるデータのことを指し、アサーションよりも広い概念で定義されたデータであることに留意されたい。
上述の通り、認可情報が要件を満たすか否かを検証するために利用するメタデータ、電子証明書を事前情報と称する。なお、本願発明を実施する上での事前情報は、メタデータ、電子証明書に限られるものではないため、認可情報の検証に用いる他の情報を含んでいても良い。また、本願発明の説明において事前情報と称した場合、メタデータ、または電子証明書の何れか１つを指す場合もある。即ち、事前情報とは、認可情報が要件を満たすか否かを検証する上で事前に登録が必要になる情報と言える。
本願発明におけるメタデータには、少なくともＩＤプロバイダを識別するためのＥｎｔｉｔｙＩＤが含まれている。サービスプロバイダは、認可情報の検証の際、メタデータに記載されたＥｎｔｉｔｙＩＤと認可情報のＥｎｔｉｔｙＩＤの比較により信頼できるＩＤプロバイダから発行された認可情報であるか否かを検証する。その他、メタデータには、ＩＤプロバイダにおけるユーザーと、サービスプロバイダにおけるユーザーとのマッピングを、ＩＤプロバイダで行うか、サービスプロバイダで行うかを定義した記述を用意しても良い。
本発明における電子証明書、または証明書には、ＩＤプロバイダに対応する公開鍵と、ハッシュが含まれている。認可情報に含まれる署名、または認可情報とともに別のデータとして送信される署名は、その公開鍵に対応する対称鍵により暗号化されたハッシュが含まれている。サービスプロバイダは、認可情報の検証の際、電子証明書と署名とを用いて正規なＩＤプロバイダから発行された認可情報であるか否かを検証する。即ち、この検証は、一般的な電子証明の技術を利用したものである。
サービスプロバイダは、認可情報に対し、これらの検証の内少なくとも１つ以上の検証を行う。検証の結果、認可情報が正規なＩＤプロバイダから発行されたことが検証された状態を、認可情報は要件を満たすと称する。以上、認可情報が要件を満たすか否かを検証するために利用するデータが事前情報であることの説明を行った。
以下、本発明を実施するための最良の形態について図面を用いて説明する。
図１は、本発明の実施形態のシステム構成を示すブロック図である。
図中１０は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１０）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。図中１１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１１）である。
図中１２はクライアントであり、ＷＡＮ１０を介して後述するＷｅｂアプリケーションサーバー１３、ＩＤプロバイダ１６に対してＷｅｂアクセスリクエストを発行する少なくとも一台以上のクライアントのコンピュータである。より具体的には、ＷＷＷシステムを利用するためのＷｅｂブラウザを備えたクライアントのコンピュータであり、ユーザーが操作する装置である。なお、クライアント１２は、不図示のファイアウォール装置により、ＷＡＮ１０に対するリクエスト以外の通信が遮断されている。各装置は、これらのネットワークリソースを用いて互いに通信可能である。
図中１３はＷＡＮ１０およびＬＡＮ１１を介して、クライアント１２からのＷｅｂアクセスリクエスト要求に応じて処理を実行し、クライアント１２に応答するＷｅｂアプリケーションサーバー１３である。なお、クライアント１２のＷｅｂブラウザを介して後述のＩＤプロバイダ１６であるサーバーと通信を行う。ＩＤプロバイダ１６は１台であっても、複数台から構成されていても良い。よって、ＩＤプロバイダ１６を情報処理システムと称する。
図中１４はＬＡＮ１１を介して、Ｗｅｂアプリケーションサーバー１３からの認証および、認証設定リクエストを受け付け、後述のデータベースサーバー１５と通信する事により、ユーザー認証を行うログイン制御サーバー１４である。
図中１５はＬＡＮ１１を介してログイン制御サーバー１４からのデータアクセス要求をうけつけるデータベースサーバー１５である。データベースサーバー１５は、一般的なＤＢＭＳ（Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）が構成されている。Ｗｅｂアプリケーションサーバー１３、ログイン制御サーバー１４、データベースサーバー１５から構成される情報処理システムが第２の情報処理システムに相当する。
図中１６Ａ、１６ＢはＷＡＮ１０を介してクライアント１２からログインリクエストを受け付けユーザー認証処理を行う、一つ以上のＩＤプロバイダ１６である。また、後述するＳＳＯのフローにおいて、２つのＩＤプロバイダは、クライアント１２のＷｅｂブラウザとＷｅｂアプリケーションサーバー１３を介してログイン制御サーバー１４からのＳＳＯリクエストを受け付ける。なお、本実施の形態におけるＩＤプロバイダ１６はＳＡＭＬのＩＤプロバイダ機能が構成されている。１６Ａ、または１６Ｂの何れか１つの情報処理システムが第１の情報処理システムに相当する。なお、本実施例においてはＩＤプロバイダが２つあることが前提で説明を行うが、それ以上の数のＩＤプロバイダと連携する場合であっても本願発明を実施することが可能である。
図２は、図１中のクライアント１２、Ｗｅｂアプリケーションサーバー１３、ログイン制御サーバー１４、データベースサーバー１５、およびＩＤプロバイダ１６のハードウェア構成を示すブロック図である。図中、２１は内部バスで接続される各デバイス（後述のＲＯＭ、ＲＡＭ他）を直接或いは間接的に制御し、本発明を実現するためのプログラムを実行するＣＰＵである。２２はＢＩＯＳが格納してあるＲＯＭである。２３はＣＰＵ２１のワーク領域として利用されたり、本発明を実現するためのソフトウェアモジュールをロードするための一時記憶として利用されたりするＲＡＭ（直接記憶装置）である。２４は基本ソフトウェアであるＯＳやソフトウェアモジュールが記憶されているＨＤＤ（ハードディスクドライブ）、もしくはＳＳＤ（ソリッドステートドライブ）などの間接記憶装置である。２５は入力装置であり不図示のキーボードやポインティングデバイスなどである。２６は出力装置でありディスプレイが接続される。２７はＷＡＮ１０ないしはＬＡＮ１１に接続するためのＩ／Ｆ（Ｉｎｔｅｒｆａｃｅ）であり、一つないしは複数備えている。
これらハードウェアでは、起動後ＣＰＵ２１によりＢＩＯＳが実行されＯＳがＨＤＤ２４からＲＡＭ２３に実行可能にロードされる。ＣＰＵ２１は、ＯＳの動作に従って後述する各種ソフトウェアモジュールをＨＤＤ２４からＲＡＭ２３にロードし、実行する。各種ソフトウェアモジュールは上記各デバイスの協調によりＣＰＵ２１によって実行され動作する。また、Ｉ／Ｆ２７はＬＡＮ１１に接続されており、ＯＳの動作に従ってＣＰＵ２１により制御され、各サーバーに格納されたソフトウェアモジュール間のリクエストの送受信を実現している。また、Ｉ／Ｆ２７はＬＡＮ１１を経由してＷＡＮ１０に接続されており、ＯＳの動作に従ってＣＰＵ２１により制御され、ＷＷＷシステムにおける通信を実現している。
また、図中１のＷｅｂアプリケーションサーバー１３、ログイン制御サーバー１４、データベースサーバー１５、およびＩＤプロバイダ１６は、一台、ないしは複数台の図２で示されたハードウェア構成のサーバーによって構成される。複数台のサーバーで構成する場合は、不図示のロードバランサー装置や、不図示のソフトウェアモジュールによって負荷分散構成、もしくは冗長化構成を採用する事ができる。
図３は、Ｗｅｂアプリケーションサーバー１３上で動作するソフトウェア構成図である。なお、これらを実現するための各ソフトウェアモジュールは図２で示したＨＤＤ２４に記憶されており、前述したようにＣＰＵ２１によってＲＡＭ２３にロードされ実行され、図３のソフトウェア構成が実現する。
Ｗｅｂサーバーアプリケーション３１は、クライアント１２からのＷｅｂアクセスリクエストを受け付けるＷｅｂインタフェースを備えたＷｅｂサーバーアプリケーションである。ログインアプリケーション３２は、Ｗｅｂサーバーアプリケーション３１上にフィルタリングアプリケーションとして構成され、認証設定アプリケーション３３やＷｅｂアプリケーション３４に対するＷｅｂアクセスリクエストをフィルタリングする。そして、ログイン制御サーバー１４に構成されるログイン制御ＡＰＩ４１と通信することによりユーザーの認証の検証を行う。認証設定アプリケーション３３やＷｅｂアプリケーション３４が受け付けたＷｅｂアクセスリクエストが未認証であった場合に、予め設定されている認証設定に従って認証検証を行うログイン先、即ち、ＩＤプロバイダを決定する。この認証設定には、本願発明の特徴の１つである、ユーザーからのＩＤプロバイダの登録の指示に従い設定されたＩＤプロバイダの設定も含まれる。
認証設定アプリケーション３３は、Ｗｅｂサーバーアプリケーション３１上にアプリケーションとして構成され、Ｗｅｂサーバーアプリケーション３１が受け付けたＷｅｂアクセスリクエストに対して認証設定画面を生成する。
Ｗｅｂアプリケーション３４は、Ｗｅｂサーバーアプリケーション３１上にアプリケーションとして構成され、Ｗｅｂサーバーアプリケーション３１が受け付けたＷｅｂアクセスリクエストに対してＷｅｂアクセス応答を返却する。
以後、上記ソフトウェアモジュールの協調により実行される一連のＷｅｂアプリケーションとしての処理をＷｅｂアプリケーションサーバー１３で実行される処理とする。なお、Ｗｅｂアプリケーションサーバー１３で実行されるＷｅｂアプリケーション処理の詳細については後述する。
図４は、ログイン制御サーバー１４上で動作するソフトウェア構成図である。なお、これらの構成を実現する各ソフトウェアモジュールは図２で示したＨＤＤ２４に記憶されており、前述したようにＣＰＵ２１によってＲＡＭ２３にロードされ実行されることで、図４のソフトウェア構成は実現する。
図中４１はＷｅｂアプリケーションサーバー１３に構成されるログインアプリケーション３２、認証設定アプリケーション３３からのＡＰＩ呼出の受付、およびＡＰＩ実行結果の応答を行うログイン制御ＡＰＩ４１である。なお、ＡＰＩとは、Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅの略である。
ログイン制御部４２は、ログイン制御ＡＰＩ４１からログイン制御リクエストを受け付けるアプリケーションモジュールである。ログイン制御部４２は、データベースサーバー１５のデータ取得や更新を行う。また、ログイン制御部４２は、メタデータ・証明書記憶部４３のデータ取得や更新を行う。ログイン制御部４２は、このような一連の制御を行う。
以後、上記ソフトウェアモジュールの協調により実行される一連のログイン制御処理をログイン制御サーバー１４で実行される処理とする。なお、ログイン制御サーバー１４で実行されるログイン制御処理の詳細は後述する。
図５はデータベースサーバー１５にて管理されているデータテーブルのデータ構造、および各データテーブルのデータサンプルを示す図である。
図中５０はユーザーテーブルである。ユーザーテーブル５０は、Ｗｅｂアプリケーションサーバー１３を利用するユーザー情報を格納するテーブルである。このテーブルには、ユーザーから入力されたユーザー認証情報を検証するためのユーザー情報が含まれる。ユーザーテーブル５０はユーザーを一意に識別するためのユーザーＩＤ５０１、ユーザーの秘匿情報であるパスワード５０２、ユーザーが所属するテナントを識別するためのテナントＩＤ５０３からなる。また、当該テーブルのユーザーＩＤ５０１はユーザーマップテーブル５４のユーザーＩＤ５４２と関連付けられる。また、パスワード５０２はセキュリティ要件に応じて、所定の暗号化アルゴリズムを用いて格納するか、もしくはハッシュアルゴリズムを用いて非可逆な情報として格納しても良い。
図中５１はテナントテーブルである。テナントテーブル５１は、Ｗｅｂアプリケーションサーバー１３を利用するユーザーが所属するテナントの情報を格納するテーブルである。テナントテーブル５１はテナントを一意に識別するためのテナントＩＤ５１１を主キーとして持つ。そして、テナントが選択しているＩＤプロバイダの種別を示す選択ＩＤプロバイダ種別５１２、テナントが選択しているＩＤプロバイダのＥｎｔｉｔｙ ＩＤである選択ＩＤプロバイダＥｎｔｉｔｙ ＩＤ５１３からなる。当該テーブルのテナントＩＤ５１１は、ユーザーテーブル５０のテナントＩＤ５１１、およびＩＤプロバイダ管理テーブル５３のテナントＩＤ５３１と関連づけられる。なお、外部のＩＤプロバイダでなく、ログインアプリケーション３２で認証検証を行う場合は、選択ＩＤプロバイダ種別５１２に、「ログインアプリケーション」が格納される。
図中５２はＩＤプロバイダマスターテーブルである。ＩＤプロバイダマスターテーブル５２は、Ｗｅｂアプリケーションサーバー１３を利用するユーザーが連携可能なＩＤプロバイダの情報を格納するテーブルである。ＩＤプロバイダマスターテーブル５２はＩＤプロバイダの種別を識別するためのＩＤプロバイダ種別５２１から構成され、このＩＤプロバイダ種別毎に、以下のデータから構成される。メタデータ／証明書のアップロード要否５２２、Ｅｎｔｉｔｙ ＩＤの共有可否５２３、Ｅｎｔｉｔｙ ＩＤが共有可能である場合に共有されるＥｎｔｉｔｙ ＩＤ５２４。当該テーブルのＩＤプロバイダ種別５２１は、テナントテーブル５１の選択ＩＤプロバイダ種別５１２、およびＩＤプロバイダ管理テーブル５３のＩＤプロバイダ種別５３３と関連付けられる。なお、ＩＤプロバイダ種別５２１が「ログインアプリケーション」であるＩＤプロバイダは、外部のＩＤプロバイダではなく、ログインアプリケーション３２で認証検証を行う事を示す。ＩＤプロバイダマスターテーブルは、サービスプロバイダの運用者がＩＤプロバイダの事前情報の管理方法等に併せて登録を行うことにより、データが追加されるテーブルである。
なお、Ｅｎｔｉｔｙ ＩＤの共有可否５２３が、ＩＤプロバイダにおける事前情報の管理方法に関わる。共有「可」であれば、そのＩＤプロバイダは、事前情報を複数のテナントで共有させて管理する情報処理システムであり、共有「否」であれば、そのＩＤプロバイダは、事前情報をテナント毎に管理する情報処理システムということになる。前者の場合、全てのテナントに対し共通の事前情報となるため、言わば情報処理システムに対する事前情報である。本願発明のマルチテナント構成のサービスプロバイダは、このようなＩＤプロバイダとＳＳＯ連携する場合、例外としてテナント間で事前情報を共有する。よって、望ましくは、サービスプロバイダの運用者が予め事前情報を登録しおいた方が良い。後述するＩＤプロバイダの登録時、サービスプロバイダは既に保持している事前情報でアサーションが検証されるようにＩＤプロバイダを登録する構成となり、ユーザーの手間を省くことができる他、誤登録も防ぐことができる。後者の場合、テナント毎に事前情報が異なるため、サービスプロバイダは各テナントの事前情報を保持する必要がある。結果、本願発明のサービスプロバイダは、マルチテナント構成でありながら、複数のグループ間、即ちテナント間で事前情報を共有できるように保持する。
図中５３はＩＤプロバイダ管理テーブルである。ＩＤプロバイダ管理テーブル５３は、Ｗｅｂアプリケーションサーバー１３を利用するユーザーのテナント毎に登録されているＩＤプロバイダの情報を格納するテーブルである。ＩＤプロバイダ管理テーブル５３はテナントＩＤ５３１、ＩＤプロバイダのＥｎｔｉｔｙ ＩＤ５３２、そのＩＤプロバイダの種別５３３、および、そのＩＤプロバイダの登録状態５３４から構成される。当該テーブルのＥｎｔｉｔｙ ＩＤ５３２はユーザーマップテーブル５４のＥｎｔｉｔｙ ＩＤ５４１と関連付けられる。ＩＤプロバイダ管理テーブル５３には、後述するＩＤプロバイダの登録が行われることによりデータが追加されていき、どのテナントがどのＩＤプロバイダを登録しているのかを判別する際に利用される。
図中５４はユーザーマップテーブルである。ユーザーマップテーブル５４はＩＤプロバイダ１６とＳＳＯする際に、ＩＤプロバイダ１６におけるユーザー識別子と、Ｗｅｂアプリケーションサーバー１３を利用するユーザーの識別子を対応付ける情報を格納するテーブルである。ユーザーマップテーブル５４は、ＩＤプロバイダを識別するためのＥｎｔｉｔｙ ＩＤ５４１を持つ。さらに、そのＥｎｔｉｔｙ ＩＤにおける、Ｗｅｂアプリケーションサーバー１３を利用するユーザーを識別するためのユーザーＩＤ５４２、ＩＤプロバイダ１６におけるユーザー識別子であるマッピングＩＤ５４３から構成される。各テーブルの情報の利用方法については後述する。
図６は、ＩＤプロバイダ１６にて生成されるＳＳＯを構成するための情報であるメタデータサンプルである。本実施の形態ではＳＡＭＬによるＳＳＯを構成するための情報のサンプルを記載している。メタデータ６０には、ＩＤプロバイダを一意に識別するためのＥｎｔｉｔｙ ＩＤや、メタデータが正当であることを検証するための署名が含まれている。署名は、メタデータと対となって設定される証明書によって検証可能な署名であり、署名方法としては、例えば、Ｘ．５０９規格によって定義される方式が考えられる。また、メタデータ６０には、ＳＡＭＬによるＳＳＯを行うためのプロトコル仕様を示すバインディング方法や、ＩＤプロバイダのユーザー識別子と、サービスプロバイダのユーザー識別子の対応づけを行うためのフォーマット方法が記載される。メタデータ６０に記載している各種情報はサンプル情報であり、ＳＡＭＬによって規定されるメタデータの記述内容を限定するものではない。
なお、このメタデータが記述されたファイルや、署名に用いた証明書のファイルをＩＤプロバイダ１６から取得し、それらをサービスプロバイダに設定する事でＳＡＭＬの信頼関係が構築される。ＩＤプロバイダ１６からメタデータや証明書を取得する方法としては、例えば、ＩＤプロバイダ１６がこれらファイルのダウンロードを行う画面（不図示）を作成し、クライアント１２からのアクセスによって提供する方法が考えられる。
以下、本発明の各サーバーにおける処理フローについてシーケンスおよびフローチャートを用いて説明する。
図７はクライアント１２のＷｅｂブラウザからＷｅｂアプリケーションサーバー１３のＷｅｂアプリケーション３４に対してＷｅｂアクセスリクエストを行った場合のＳＳＯシーケンスである。なお、以後、クライアント１２のＷｅｂブラウザでの制御をクライアント１２での制御として説明する。また、本ＳＳＯシーケンスはＳＡＭＬで定義されているＳＳＯプロトコルシーケンスの一例であり、ＳＡＭＬで定義されているＳＳＯプロトコルシーケンスの方式を制限するものではない。なお、ＳＳＯプロトコルシーケンスは、後述するＩＤプロバイダの登録および選択が既に行われているものとして説明する。
クライアント１２は、シーケンスＳ７．１にて、Ｗｅｂアプリケーションサーバー１３に対してＷｅｂアクセスリクエストを実行する。このＷｅｂアクセスリクエストのアクセス先は、Ｗｅｂアプリケーション３４を指しており、このリクエストには、後述する認証が既に終了している事を示すＣｏｏｋｉｅは含まれていないものとする。
シーケンスＳ７．２にて、ログインアプリケーション３２はリクエストをフィルタし、ログイン制御サーバー１４のログイン制御ＡＰＩ４１に対して認証確認をリクエストする。
ログイン制御サーバー１４は、ログイン制御ＡＰＩ４１で受け付けた認証確認リクエストをログイン制御部４２にて処理する。ログイン制御サーバー１４は、シーケンスＳ７．３ にて、認証確認リクエストに、後述する認証している事を示す情報が含まれていないため、クライアント１２をログインアプリケーション３２にリダイレクトさせる。
Ｗｅｂアプリケーションサーバー１３は、シーケンスＳ７．４ にて、ログインアプリケーション３２にてクライアント１２からのアクセスを受け付け、不図示のテナントＩＤ入力画面を応答する。クライアント１２は、シーケンスＳ７．５ にて、テナントＩＤ入力画面に入力されたテナントＩＤをログインアプリケーション３２へ通知する。
Ｗｅｂアプリケーションサーバー１３は、シーケンスＳ７．６にて、ログインアプリケーション３２で受け付けたテナントＩＤを用いて、ログイン制御ＡＰＩ４１に対してログイン先情報の取得を行う。ログイン制御サーバー１４は、ログイン制御ＡＰＩ４１で受け付けたログイン先情報の取得リクエストをログイン制御部４２にて処理を行う。シーケンスＳ７．７にて、ログイン制御サーバー１４は、データベースサーバー１５が管理しているテナントテーブル５１へ、受け付けたテナントＩＤを用いて選択ＩＤプロバイダ情報の取得を行う。
データベースサーバー１５は、シーケンスＳ７．８ にて、受け付けたテナントＩＤから選択ＩＤプロバイダ種別５１２、選択ＩＤプロバイダのＥｎｔｉｔｙ ＩＤ５１３を取り出し応答する。このとき、選択ＩＤプロバイダ５１２が「ログインアプリケーション」であった場合、ログイン制御サーバー１４は、ログインアプリケーション３２にて認証検証を行うよう応答する。そして、認証検証要求を受けたログインアプリケーション３２は、クライアント１２に対して不図示のユーザー認証画面を応答する。そして、ログインアプリケーション３２は、クライアント１２よりユーザーＩＤとパスワード入力を受け付け、それら情報を用いてログイン制御サーバー１４に認証検証リクエストを行う。認証検証リクエストを受けたログイン制御サーバー１４はデータベースサーバー１５を介して、ユーザーテーブル５０のユーザーＩＤ５０１、パスワード５０２と、取得したユーザー認証情報であるユーザーＩＤ、パスワードが一致するかを検証する。一致した場合は、シーケンスＳ７．１６の処理を実行するよう構成する事もできる。
説明をメインフローであるＳ７．９に戻す。ログイン制御サーバー１４は受信したＥｎｔｉｔｙ ＩＤをログイン制御部４２にて処理する。シーケンスＳ７．９にて、ログイン制御サーバー１４はＥｎｔｉｔｙ ＩＤを用いてメタデータ・証明書記憶部４３からＳＳＯを行うためのＩＤプロバイダ１６のエンドポイントを取得する。そして、シーケンスＳ７．１０ にて、ログイン制御サーバー１４はＩＤプロバイダ１６のエンドポイントに対してクライアント１２を介してＳＡＭＬのアサーションリクエストを行う。このＳＡＭＬのアサーションリクエストは、Ｗｅｂアプリケーションサーバー１３を介して行われる。ここで、アサーションリクエストは事前に設定された証明書によって署名する事ができるが、本実施の形態では署名なしのリクエストであるとして説明する。
ＩＤプロバイダ１６はアサーションリクエストを受け付け、シーケンスＳ７．１１にてクライアント１２にユーザー認証を求める。ユーザー認証の方式としてはＩＤプロバイダ１６で管理しているユーザー識別子と秘匿情報を用いた方法が考えられる。より具体的には、クライアント１２のＷｅｂブラウザにユーザー識別子、秘匿情報の入力を受け付ける画面を提示するフォーム認証か、もしくはベーシック認証などの方式が考えられる。
ＩＤプロバイダ１６は、ユーザー認証が成功するとアサーションを生成し、シーケンスＳ７．１２にてアサーションレスポンスを応答する。この際に生成されるアサーションには、ＩＤプロバイダ１６のＥｎｔｉｔｙ ＩＤ、証明書による署名、およびマッピングＩＤが含まれる。
ログイン制御サーバー１４は、受信したアサーションをログイン制御部４２にて処理する。ログイン制御サーバー１４は、シーケンスＳ７．１３にて、メタデータ・証明書記憶部４３から、Ｅｎｔｉｔｙ ＩＤを用いて証明書を取得する。次に、ログイン制御サーバー１４は、取得した証明書を用いて、ＩＤプロバイダ１６のアサーションレスポンスに含まれるアサーションの署名を検証する。この際、ログイン制御サーバー１４は、メタデータを用いてアサーションレスポンスに含まれるＥｎｔｉｔｙＩＤの正当性を検証する形態であっても良い。しかし、一般的にアサーションの検証と言った場合、署名による検証のみを指す。
そして、アサーションの署名が正しい場合には、ログイン制御サーバー１４は、シーケンスＳ７．１４にて、データベースサーバー１５のユーザーマップテーブル５４に対してＥｎｔｉｔｙ ＩＤ、マッピングＩＤを用いてユーザーＩＤ取得を行う。データベースサーバー１５は、シーケンスＳ７．１５ にて、Ｅｎｔｉｔｙ ＩＤ、およびマッピングＩＤにより特定されたユーザーＩＤを応答する。この際、マッピングＩＤの参照方法をメタデータに基づき決定しても良い。メタデータには、マッピングＩＤからユーザーＩＤを特定するのがＩＤプロバイダであるか、サービスプロバイダであるかについて記載されている。本実施例では、サービスプロバイダであるものとする。
ログイン制御サーバー１４は受信したユーザーＩＤをログイン制御部４２にて処理する。そして、ログイン制御サーバー１４はシーケンスＳ７．１６にて認証情報を生成する。ここで生成する認証情報とは、例えば、認証セッションをユニークに識別するためのセッションＩＤを含む、認証されている事を示す情報である。この認証情報はログイン制御サーバー１４のＲＡＭ２３にてセッションＩＤとユーザーＩＤとを紐づけて記憶される。そして、シーケンスＳ７．１７にてログイン制御サーバー１４は、シーケンスＳ７．１で受け付けたＷｅｂアクセスリクエスト先にＷｅｂアプリケーションサーバー１３を介してクライアント１２をリダイレクトさせる。その際、リダイレクトリクエストに生成した認証情報のセッションＩＤをＨＴＴＰプロトコルにおけるＣｏｏｋｉｅに設定する。
Ｗｅｂアプリケーションサーバー１３は、シーケンスＳ７．１８にて、ログインアプリケーション３２がリクエストをフィルタし、ログイン制御サーバー１４のログイン制御ＡＰＩ４１に対して認証確認をリクエストする。その際、クライアント１２のＷｅｂブラウザから送信されたＣｏｏｋｉｅに設定されている認証情報のセッションＩＤをログイン制御ＡＰＩ４１に渡す。
ログイン制御サーバー１４では、ログイン制御ＡＰＩ４１で受け付けた認証確認リクエストをログイン制御部４２にて処理を行う。より具体的には、受け付けた認証情報のセッションＩＤがログイン制御サーバー１４のＲＡＭ２３に認証情報として格納されているかを検証し、認証済みであるかを判断する。シーケンスＳ７．１９ にて、ログイン制御サーバー１４はログインアプリケーション３２に対して、検証結果と、認証済みであった場合は認証情報を通知する。ログインアプリケーション３２は、ＷｅｂアクセスリクエストをＷｅｂアプリケーション３４に通知する。この際、ログインアプリケーション３２は、ログイン制御サーバー１４を介し、認証情報に格納されているユーザーＩＤを用いて、データベースサーバー１５のユーザーテーブル５０内のユーザーＩＤ５０１、テナントＩＤ５０３の情報を取得し通知する。
Ｗｅｂアプリケーションサーバー１３は、ＷｅｂアクセスリクエストをＷｅｂアプリケーション３４にて処理する。Ｗｅｂアプリケーションサーバー１３は、シーケンスＳ７．２１にてクライアント１２にＷｅｂアクセス応答する。結果、クライアント１２は、サービスプロバイダの情報処理システムに対しユーザー認証情報を入力することなく、ＩＤプロバイダに対するユーザー認証情報の入力のみで、サービスプロバイダが提供するサービスを受けることが出来る。以上のシーケンスにより、ＳＡＭＬによるＳＳＯが実行される。
次に、本発明の特徴であるＩＤプロバイダの登録方法について図面を用いて説明する。より具体的には、各図面を用いて以下の説明を行う。図７のシーケンスＳ７．９、Ｓ７．１３にて利用したメタデータ・証明書記憶部４３のメタデータ、証明書の登録方法。および、図７のシーケンスＳ７．７、Ｓ７．８にて利用したテナントテーブル５１の選択ＩＤプロバイダのＥｎｔｉｔｙ ＩＤ情報の登録方法。なお、ユーザーテーブル５０、テナントテーブル５１のテナントＩＤ５１１、および、ユーザーマップテーブル５４の情報は事前に用意されているものとする。
図８は、Ｗｅｂアプリケーションサーバー１３における認証設定アプリケーション３３が生成するＩＤプロバイダ登録画面である。認証設定アプリケーション３３はクライアント１２のＷｅｂアクセスリクエストに応じて本画面を応答する。このＩＤプロバイダの登録によって登録されたＩＤプロバイダが、図１０を用いて後述するＩＤプロバイダの選択の対象となる。登録の際、ユーザーからのアクセスが未認証の場合は、ログインアプリケーション３２によるフィルタ処理にて図７で説明したユーザー認証処理が行われる。そして、認証設定アプリケーション３３は、ログインアプリケーション３２から認証したユーザー認証情報を受け取る。ユーザー認証情報とは、ユーザーテーブル５０のユーザーＩＤ５０１、テナントＩＤ５０３である。ユーザー認証情報を受け取った認証設定アプリケーション３３は、ＩＤプロバイダ登録画面を応答し、クライアント１２では、項目の選択状態によって８０Ａもしくは８０Ｂの画面が提示される。
図中８０１は登録するＩＤプロバイダを選択するためのＩＤプロバイダリストである。認証設定アプリケーション３３はログイン制御サーバー１４を介してデータベースサーバー１５のＩＤプロバイダマスターテーブル５２から情報を取得してＩＤプロバイダリスト８０１を生成する。その際、ＩＤプロバイダ種別５２１が「ログインアプリケーション」となっているものは除外する。
図中８０２は登録するメタデータのファイルを指定するためのファイル選択コントロールである。そして、図中８０３は登録する証明書のファイルを指定するためのファイル選択コントロールである。これらファイル選択コントロールは、ＩＤプロバイダリスト８０１にてＩＤプロバイダの選択状態が変化する毎に以下のように制御される。ＩＤプロバイダリスト８０１で選択されたＩＤプロバイダのＩＤプロバイダマスターテーブル５２におけるメタデータ／証明書のアップロード要否５２２が「要」であった場合は、８０Ａのようにコントロールは有効状態で表示される。ユーザーは、サービスプロバイダに保持させる事前情報を指定することが可能である。ＩＤプロバイダリスト８０１で選択されたＩＤプロバイダのＩＤプロバイダマスターテーブル５２におけるメタデータ／証明書のアップロード要否５２２が「否」であった場合は、８０Ｂのようにコントロールは無効状態で表示される。ユーザーは、サービスプロバイダに保持させる事前情報を指定することが不可能である。このように事前情報をアップロードさせないように画面を構成することで、先に述べたＩＤプロバイダとの信頼関係を動的に設定変更すると発生する課題を解決することが可能となる。
図中８０４はＩＤプロバイダの登録作業を行わずに終了するためのキャンセルボタンである。図中８０５はＩＤプロバイダの登録を実行するための登録ボタンである。登録ボタン８０５が押下された場合、認証設定アプリケーション３３は以下の処理を実行する。まず、ＩＤプロバイダリストで選択されているＩＤプロバイダ種別を取得する。これは、ＩＤプロバイダリスト生成時にデータベースサーバー１５のＩＤプロバイダマスターテーブル５２から取得した情報を用いる。次に、各ファイル選択コントロールが有効な場合は、メタデータ、証明書の各ファイルを取得する。そして、メタデータ、証明書の各ファイルについて以下の処理を行う。
まず、認証設定アプリケーション３３は、メタデータに記述されている署名を証明書を用いて検証する。検証の結果が不正であった場合、認証設定アプリケーション３３はクライアント１２に不図示のエラー画面を応答し、処理を終了する。検証の結果が正当であった場合は、メタデータからＥｎｔｉｔｙ ＩＤを抽出する。そして、認証設定アプリケーション３３は、ユーザー情報、ＩＤプロバイダ種別、メタデータ、証明書、および抽出したＥｎｔｉｔｙ ＩＤらの情報を用いて、ログイン制御サーバー１４に対してＩＤプロバイダ登録依頼を実行する。ログイン制御サーバー１４では、ログイン制御ＡＰＩ４１を介して受け付けたＩＤプロバイダ登録依頼を、ログイン制御部４２にて処理する。本処理フローについては後述する。
なお、上述したメタデータの署名検証については、認証設定アプリケーション３３にて行う方式で説明したが、後述するログイン制御サーバー１４におけるメタデータ・証明書の登録時に実施しても良い。また、認証設定アプリケーション３３がログイン制御サーバー１４にＩＤプロバイダ登録依頼する際に、メタデータ・証明書の各ファイルの実態をデータとして渡しても良い。もしくは、不図示のファイル格納領域にファイルを格納し、当該ファイルを特定するためのＩＤを渡すよう構成としても良い。この当該ファイルを特定するためのＩＤについては、例えば、ファイル名にＩＤを付与する方法が考えられる。
図９は、ログイン制御サーバー１４が、認証設定アプリケーション３３からのＩＤプロバイダの登録依頼を受け付けた場合のＩＤプロバイダ登録処理フローである。登録依頼は、ユーザーからのＩＤプロバイダを登録する指示により発行される依頼である。ＩＤプロバイダ登録処理フロー９０と、当該フロー中の共通処理フローであるマスター登録判断フロー９１、重複登録判断フロー９２とで構成される。
ログイン制御部４２における、ＩＤプロバイダ登録処理フロー９０について説明する。ステップ９００１にて、ログイン制御部４２は認証設定アプリケーション３３からＩＤプロバイダの登録依頼を受け付ける。ＩＤプロバイダの登録依頼には、ユーザー情報、ＩＤプロバイダ種別と、必要に応じてメタデータ、証明書、およびメタデータのＥｎｔｉｔｙ ＩＤらの情報を受け付ける。
ステップ９００２にて、ログイン制御部４２は受け付けたＩＤプロバイダ種別を用いて、データベースサーバー１５のＩＤプロバイダマスターテーブル５２からＩＤプロバイダの情報を取得する。
ステップ９００３にて、ログイン制御部４２は取得したＩＤプロバイダの情報のうち、Ｅｎｔｉｔｙ ＩＤの共有可否５２３を調べ、「可」であった場合はステップ９００４へ、「否」であった場合はステップ９００８へ処理を分岐する。換言すれば、この判断ステップは、ユーザーが登録を指定したＩＤプロバイダとなる情報処理システムが、事前情報をグループ毎に管理する情報処理システムであるか、または事前情報を複数のグループで共有させて管理する情報処理システムであるかの判断である。
ステップ９００４にて、ログイン制御部４２は取得したＩＤプロバイダの情報のうち、メタデータ／証明書アップロードの要否５２２を調べ、「要」であった場合はステップ９００５へ、「否」であった場合はステップ９００６へ処理を分岐する。
ステップ９００５にて、ログイン制御部４２は受け付けたＩＤプロバイダ登録依頼を登録エラーとして応答し、処理を終了する。ＩＤプロバイダが事前情報を複数のグループで共有させて管理しているにも関わらず、事前情報の受け付けが必要な情報処理システムは誤ったＳＳＯを実現する危険性が高いＩＤプロバイダであるため、実質そのようなＩＤプロバイダが運用させる可能性は極めて低い。よって、ＩＤプロバイダマスターテーブル５２の設定ミスであるとし、例外処理のエラーとして本願発明のサービスプロバイダに設けている。即ち、ＩＤプロバイダが事前情報を複数のグループで共有させて管理している場合は、事前情報は既に保持されていることが前提である。
ステップ９００６にて、ログイン制御部４２は、ステップ９００１で受信したＩＤプロバイダ種別を用いて後述するマスター登録判断処理を実行する。マスター登録判断処理の結果が正常応答で合った場合、ステップ９００７へ処理を継続する。
ステップ９００７にて、ログイン制御部４２はＩＤプロバイダ登録を実施する。より具体的には、ログイン制御部４２はデータベースサーバー１５のＩＤプロバイダ管理テーブル５３に対し、ユーザー情報に含まれるテナントＩＤ、ＩＤプロバイダマスターテーブル５２の共有Ｅｎｔｉｔｙ ＩＤ５２４、ＩＤプロバイダ種別、および、ＩＤプロバイダ状態を登録する。この際、ＩＤプロバイダ状態は「登録済」を格納する。ＩＤプロバイダ状態が「登録済」となると、ユーザーは後述する図１０のＩＤプロバイダ登録画面を介して、ＩＤプロバイダが登録することが可能になる。
ステップ９００８にて、ログイン制御部４２は取得したＩＤプロバイダの情報のうち、メタデータ／証明書アップロードの要否５２２を調べ、「要」であった場合はステップ９００９へ、「否」であった場合はステップ９０１４へ処理を分岐する。
ステップ９００９にて、ログイン制御部４２は、ステップ９００１で受信したＥｎｔｉｔｙ ＩＤを用いて後述する重複登録判断処理を実行する。重複登録判断処理の結果が正常応答で合った場合、ステップ９００７へ処理を継続する。
ステップ９０１０にて、ログイン制御部４２はＩＤプロバイダ登録予約を実施する。より具体的には、データベースサーバー１５のＩＤプロバイダ管理テーブル５３に対して、ユーザー情報に含まれるテナントＩＤ、Ｅｎｔｉｔｙ ＩＤ、ＩＤプロバイダ種別、および、ＩＤプロバイダ状態を登録する。この際、ＩＤプロバイダ状態は「登録予約」を格納する。メタデータ・証明書ファイルを直接受信する構成の場合は、不図示のメモリ領域に保存し、ＩＤプロバイダ状態５３４に対して、メタデータ・証明書を特定するための情報を付与して格納する。
ステップ９０１１にて、ログイン制御部４２はＩＤプロバイダの登録予約結果が失敗だった場合はステップ９０１２に、成功した場合はステップ９０１３に処理を分岐する。登録予約が失敗する理由としては、例えば、当該Ｅｎｔｉｔｙ ＩＤのＩＤプロバイダ登録予約が複数のユーザーから全く同時に実行された場合に、ステップ９００９の重複登録判断にて互いに正常応答となる可能性がある。これは、事前情報の検証に時間を要するためであり、未だ登録ユーザーの他のグループに対応する事前情報として保持されていないからである。その場合は、データベースサーバー１５のＩＤプロバイダ管理テーブル５３の各項目の組み合わせや、不図示の別項目に対してユニーク制約を設定する対応が考えられる。この対応により、データベーストランザクションにおけるコミットメントが後から実行される側にて失敗を応答するよう構成する事ができる。
ステップ９０１２にて、ログイン制御部４２は受け付けたＩＤプロバイダ登録依頼を登録エラーとして応答し、処理を終了する。
ステップ９０１３にて、ログイン制御部４２は登録予約したＩＤプロバイダの登録処理を行う。ここで、ログイン制御部４２における「登録予約」状態のＩＤプロバイダの登録処理について説明する。
ログイン制御部４２はメタデータに記述されているＳＡＭＬの各種プロトコル設定が、ログインアプリケーション３２、および、ログイン制御部４２にて解釈および実施可能かの判断をする必要がある。また、メタデータの記述そのものがＳＡＭＬの要件を満たしているのか、さらには証明書がセキュアであるのか、等の確認も必要である。これらを、メタデータ・証明書の検証と呼ぶ。このメタデータ・証明書の検証は、ある程度の時間を要する処理になる可能性が高い。よって、本実施例では、ログイン制御部４２は、ＩＤプロバイダ登録処理フロー９０とは別のプロセスとして、「登録予約」状態のＩＤプロバイダを対象とした定期的なＩＤプロバイダ登録処理を実施する構成とする。ただし、本構成は、メタデータ・証明書の登録処理に時間を要する場合の構成であって、例えば、メタデータの記述内容のサポート範囲や内容の検証方法によっては時間短縮可能であり、ステップ９０１３の処理として実施する構成も可能である。以下、別プロセスか、もしくはステップ９０１３の処理として実施する場合の登録処理について説明する。
ステップ９０１３、もしくは別プロセスにて、ログイン制御部４２は「登録予約」状態のＩＤプロバイダ登録を実施する。より具体的には、上述したメタデータ・証明書ファイルの検証を実施後、正当であれば、以下の処理を実行する。ログイン制御部４２は、Ｅｎｔｉｔｙ ＩＤを用いて、メタデータ・証明書記憶部４３に当該メタデータ・証明書を格納する。次に、ログイン制御部４２は、データベースサーバー１５のＩＤプロバイダ管理テーブル５３に対して、ＩＤプロバイダ状態を「登録済」に変更し、処理を終了する。なお、メタデータ・証明書ファイルの検証の実施後、不正であれば、登録エラーとして処理を終了する。
ステップ９０１４にて、ログイン制御部４２はステップ９００１で受信したＩＤプロバイダ種別を用いて後述するマスター登録判断処理を実行する。マスター登録判断処理の結果が正常応答で合った場合、ステップ９０１５へ処理を継続する。ＩＤプロバイダが事前情報をグループ毎に管理する情報処理システムであり、かつ事前情報が既に保持されている場合、Ｓ９０１４以降の処理が実行される。これは商談対応なので、テナントの管理者から予め事前情報を取得している場合に対応している。サービスプロバイダのシステム管理者は、テナントの管理者が登録を実行する前に事前情報を格納しておくのである。結果、テナントの管理者に対するＩＤプロバイダの登録の負担を軽減可能である。
ステップ９０１５にて、ログイン制御部４２はＩＤプロバイダマスターテーブル５２の共有Ｅｎｔｉｔｙ ＩＤ５２４を取得する。
ステップ９０１６にて、ログイン制御部４２は前ステップで取得したＥｎｔｉｔｙ ＩＤを用いて後述する重複登録判断処理を実行する。重複登録判断処理の結果が正常応答で合った場合、ステップ９０１７へ処理を継続する。
ステップ９０１７にて、ログイン制御部４２はＩＤプロバイダ登録を実施する。より具体的には、データベースサーバー１５のＩＤプロバイダ管理テーブル５３に対して以下の情報を登録する。ユーザー情報に含まれるテナントＩＤ、ＩＤプロバイダマスターテーブル５２の共有Ｅｎｔｉｔｙ ＩＤ５２４、ＩＤプロバイダ種別、および、ＩＤプロバイダ状態である。この際、ＩＤプロバイダ状態は「登録済」を格納する。
次に、ログイン制御部４２におけるマスター登録判断フロー９１について説明する。ステップ９１０１にて、ログイン制御部４２は判断対象であるＩＤプロバイダ種別を受け付ける。
ステップ９１０２にて、ログイン制御部４２はＩＤプロバイダ種別を用いてＩＤプロバイダマスターテーブル５２の共有Ｅｎｔｉｔｙ ＩＤ５２４にＥｎｔｉｔｙ ＩＤが登録されているかを調べる。Ｅｎｔｉｔｙ ＩＤが登録されていない場合はステップ９１０３、登録されている場合はステップ９１０４に処理を分岐する。ステップ９１０３にて、ログイン制御部４２はエラー応答し処理を終了する。ステップ９１０４にて、ログイン制御部４２は正常応答する。
次に、ログイン制御部４２における重複登録判断フロー９２について説明する。ステップ９２０１にて、ログイン制御部４２は判断対象であるＥｎｔｉｔｙ ＩＤを受け付ける。
ステップ９２０２にて、ログイン制御部４２は、Ｅｎｔｉｔｙ ＩＤを用いてＩＤプロバイダ管理テーブル５３にて同一Ｅｎｔｉｔｙ ＩＤのＩＤプロバイダが存在しているか否かを調べる。この際、ＩＤプロバイダ状態５３４が「登録済」「登録予約」の双方を対象とする。結果、同一Ｅｎｔｉｔｙ ＩＤのＩＤプロバイダが存在している場合は利用中であると判断しステップ９２０３へ、存在していない場合は利用していないと判断しステップ９２０４へ処理を分岐する。ステップ９２０３にて、ログイン制御部４２はエラー応答し処理を終了する。ステップ９２０４にて、ログイン制御部４２は正常応答する。
以上説明したフローによって、マルチテナント構成のサービスプロバイダにおいても、テナント毎にＩＤプロバイダとの信頼関係を構築する事ができる。つまりは、ＩＤプロバイダとの信頼関係の構築において、ＩＤプロバイダが単一のＥｎｔｉｔｙ ＩＤしか持たない場合は、サービスプロバイダにて複数のテナントで一つのＩＤプロバイダを共有する事ができる。さらに、ＩＤプロバイダが複数のＥｎｔｉｔｙ ＩＤを持てるものであった場合は、サービスプロバイダにて同一のＥｎｔｉｔｙ ＩＤのＩＤプロバイダが複数のテナントで共有されること無く、動的に構築する事が可能となる。また、ユーザーのＩＤプロバイダの登録負担の軽減、ＩＤプロバイダの誤設定を防ぐことも可能となる。
図１０はＷｅｂアプリケーションサーバー１３における認証設定アプリケーション３３が生成するＩＤプロバイダ選択画面である。認証設定アプリケーション３３はクライアント１２のＷｅｂアクセスリクエストに応じて本画面を応答する。このＩＤプロバイダの一覧が表示された選択画面にて選択可能なＩＤプロバイダは、図８を用いて説明したＩＤプロバイダの登録が行われたものである。なお、ここで説明するＩＤプロバイダの選択にて選択されたＩＤプロバイダが、図７で説明したＳＳＯプロトコルフローにて、認証検証を行うＩＤプロバイダとなる。換言すれば、ユーザーは自身でＩＤプロバイダを選択することができ、任意のＩＤプロバイダでユーザー認証処理を受けることができる。無論、選択できるＩＤプロバイダは登録処理が済んだＩＤプロバイダのみである。
クライアント１２のアクセスが未認証の場合、ログインアプリケーション３２は、フィルタ処理にて図７で説明したユーザー認証処理を行う。そして、認証設定アプリケーション３３は、ログインアプリケーション３２からユーザー認証情報を受け取る。ユーザー認証情報は、ユーザーテーブル５０のユーザーＩＤ５０１、テナントＩＤ５０３である。ユーザー認証情報を受け取った認証設定アプリケーション３３は、ＩＤプロバイダ選択画面を応答し、クライアント１２ではＩＤプロバイダ選択画面１００が提示される。
図中１００１は、登録済みのＩＤプロバイダの一覧の中から、ＳＡＭＬにおけるユーザー認証処理を行うＩＤプロバイダを選択するためのＩＤプロバイダリストである。ＩＤプロバイダリスト１００１は表示項目として、選択状態を示す情報と、ＩＤプロバイダ名、および対応するＥｎｔｉｔｙ ＩＤを表示する。認証設定アプリケーション３３はログイン制御サーバー１４を介してデータベースサーバー１５のＩＤプロバイダ管理テーブル５３から情報を取得してＩＤプロバイダリスト１００１を生成する。その際、取得したユーザー情報のテナントＩＤを用いて取得するＩＤプロバイダの情報を絞り込む。さらに、全てのテナントにおいてＩＤプロバイダとしてログインアプリケーション３２を選択可能に表示する。次に、認証設定アプリケーション３３は、データベースサーバー１５のテナントテーブル５１からテナントＩＤを用いて選択ＩＤプロバイダ種別５１２を取得し、ＩＤプロバイダリスト１００１の対応するＩＤプロバイダを選択状態として表示する。図中１００２はＩＤプロバイダの選択を行わずに終了するためのキャンセルボタンである。図中１００３はＩＤプロバイダの選択を実行するための選択ボタンである。
選択ボタン１００３が押下された場合、認証設定アプリケーション３３は以下の処理を実行する。まず、認証設定アプリケーション３３は、ＩＤプロバイダリストで選択されているＩＤプロバイダのＥｎｔｉｔｙ ＩＤを取得する。これは、ＩＤプロバイダリスト生成時にデータベースサーバー１５のＩＤプロバイダ管理テーブル５３から取得した情報を用いる。そして、認証設定アプリケーション３３は、ユーザー情報、Ｅｎｔｉｔｙ ＩＤ、ＩＤプロバイダ種別らの情報を用いて、ログイン制御サーバー１４に対してＩＤプロバイダ選択依頼を実行する。ログイン制御サーバー１４では、ログイン制御ＡＰＩ４１を介して受け付けたＩＤプロバイダ選択依頼を、ログイン制御部４２にて処理する。
認証設定アプリケーション３３は、ＩＤプロバイダ選択依頼の結果がエラーだった場合は不図示のエラー画面を応答する。ＩＤプロバイダ選択依頼の結果が成功であった場合は、ＩＤプロバイダリスト１００１の選択状態を更新したＩＤプロバイダ選択画面１００を応答する。
ログイン制御部４２は、ＩＤプロバイダ選択依頼を受け付けると、テナントＩＤとＥｎｔｉｔｙ ＩＤを用いてデータベースサーバー１５のＩＤプロバイダ管理テーブル５３にそのＥｎｔｉｔｙ ＩＤが登録されているかを確認する。確認の結果、登録されていない場合はエラー応答する。確認の結果、登録されている場合は、データベースサーバー１５のテナントテーブル５１においてテナントＩＤが一致する情報の選択ＩＤプロバイダ種別５１２、選択ＩＤプロバイダＥｎｔｉｔｙ ＩＤ５１３の情報を更新し成功応答する。以降、特定のテナントにおけるＩＤプロバイダは、特定のテナントに属するユーザーが選択したＩＤプロバイダとなり、クライアントから未認証のアクセスがあった場合、クライアントはそのＩＤプロバイダにアクセスさせられる。
上記処理によって、図９のフローで登録したＩＤプロバイダを図７で説明したＳＳＯシーケンスで利用されるよう設定する事ができる。なお、ＩＤプロバイダの登録、および選択は各テナントの代表である管理者により行われることを想定している。よって、管理者によりＩＤプロバイダの登録、および選択が行われたテナントに属するユーザーがＳ７．５にてテナントＩＤを入力することで、ユーザー認証処理を受けるべきＩＤプロバイダが自動で決定する。そのテナントに属するユーザーのユーザー認証処理が成功したことに応じて発行される認可情報に対しても、そのテナントに属する管理者が設定した事前情報を用いて検証が行われる。
図９のＩＤプロバイダ登録フロー９０にて説明したとおり、メタデータ・証明書の検証はある程度の時間を要する処理になる可能性が高い。そのため、図８のＩＤプロバイダ登録画面８０において、誤ったメタデータ・証明書ファイルで登録してしまった場合、ステップ９０１０にて「登録予約」されてしまう。結果、急ぎで正当なメタデータ・証明書を再登録しようとしても、重複登録判断フロー９２にてＥｎｔｉｔｙ ＩＤが利用されていると判断され再登録できない。つまりは、正当なメタデータ・証明書ファイルを設定するためには、前述のメタデータ・証明書検証の終了を待ち、処理がエラーするのを待たなければならない。
上記課題を解決するための実施例２について図面を用いて説明する。なお、実施例２では、図９の重複登録判断フロー９２以外には差異が無いため説明を省略する。図１１は実施例２に係るログイン制御サーバー１４のログイン制御部４２において重複登録判断リクエストを受けた場合の処理フローである。実施例１では、ユーザーからアップロードされた事前情報が、既に他のグループに対応する事前情報として登録されているか否かを、Ｅｎｔｉｔｙ ＩＤを基に判定する形態であった。しかし、実施例２では、図１１に示すようにその他の判断処理が追加された。
次に、ログイン制御部４２における重複登録判断フロー１１０について説明する。ステップ１１０１にて、ログイン制御部４２は判断対象であるＥｎｔｉｔｙ ＩＤおよび、ユーザー情報に含まれるテナントＩＤを受け付ける。
ステップ１１０２にて、ログイン制御部４２はＥｎｔｉｔｙ ＩＤを用いて、ＩＤプロバイダ管理テーブル５３にて同一Ｅｎｔｉｔｙ ＩＤのＩＤプロバイダが存在しているかを調べる。この際、ＩＤプロバイダ状態５３４が「登録済」「登録予約」の双方を対象とする。結果、同一Ｅｎｔｉｔｙ ＩＤのＩＤプロバイダが存在している場合は利用中であると判断しステップ１１０４へ、存在していない場合は利用していないと判断しステップ１１０３へ処理を分岐する。
ステップ１１０３にて、ログイン制御部４２は正常応答する。
ステップ１１０４にて、ログイン制御部４２はステップ１１０２にて調べて存在した同一Ｅｎｔｉｔｙ ＩＤのテナントＩＤ５３１が、取得したテナントＩＤと同一であるかを調べる。同一である場合は、ＩＤプロバイダ状態５３４が「登録予約」であるかを調べ、該当しない場合はステップ１１０５へ、該当する場合はステップ１１０６へ処理を分岐する。
ステップ１１０５にて、ログイン制御部４２はエラー応答し処理を終了する。ステップ１１０６にて、ログイン制御部４２は正常応答し処理を終了する。
実施例２の構成によれば、誤ったメタデータ・証明書ファイルで登録してしまった場合、ステップ９０１０にて「登録予約」されてしまったとしても、同一テナント内であれば再登録が可能となる。つまりは、正当なメタデータ・証明書ファイルの再設定を、メタデータ・証明書検証の終了を待たずに行う事ができるのでユーザビリティーを向上させることが可能になる。
以上、本発明の実施形態について詳細を説明したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変更が可能である。
１０ ＷＡＮ
１１ ＬＡＮ
１２ クライアント
１３ Ｗｅｂアプリケーションサーバー
１４ ログイン制御サーバー
１５ データベースサーバー
１６ ＩＤプロバイダ

Claims (9)

  1. ユーザーから入力されたユーザー認証情報を用いたユーザー認証処理を行う第１の情報処理システムと通信可能な第２の情報処理システムであって、
    前記ユーザー認証処理が成功したことに応じて前記第１の情報処理システムにより発行され送信される認可情報を、前記第１の情報処理システムにより発行されたことを証明するための電子証明書を少なくとも含む事前情報を用いて署名検証する検証手段と、
    前記検証の結果、送信された前記認可情報が前記第１の情報処理システムにより発行された認可情報であることが少なくとも確認された場合に、前記ユーザー認証処理を行うことなくサービスを提供する提供手段と、
    ユーザー認証処理を行う第１の情報処理システムを登録する指示を前記ユーザーから受け付けた際に、該第１の情報処理システムが前記事前情報をグループ毎に管理する情報処理システムであるか、または前記事前情報を複数のグループで共有させて管理する情報処理システムであるかを判断する判断手段と、
    前記判断手段により該第１の情報処理システムが前記事前情報をグループ毎に管理する情報処理システムであると判断された場合は、前記事前情報を受け付け可能な第１の方法で前記ユーザーのテナントＩＤと該第１の情報処理システムのエンティティＩＤと受け付けた前記事前情報とを関連付けて保存する登録処理を行い、前記判断手段により該第１の情報処理システムが前記事前情報を複数のグループで共有させて管理する情報処理システムであると判断された場合は、前記事前情報を受け付け不可能な第２の方法で前記ユーザーのテナントＩＤと該第１の情報処理システムのエンティティＩＤと予め保有する前記事前情報とを関連付けて保存する登録処理を行う登録手段と、
    を有する第２の情報処理システム。
  2. 前記登録手段は、該第１の情報処理システムが前記事前情報をグループ毎に管理する情報処理システムであり、かつ前記ユーザーが属するグループに対応した前記事前情報は前記グループに対応する事前情報として予め用意されている場合は、前記ユーザーから前記ユーザーが属するグループに対応した前記事前情報を受け付けることなく、予め用意されている前記事前情報を用いて前記登録処理を行うことを特徴とする請求項１に記載の第２の情報処理システム。
  3. 前記登録手段は、前記ユーザーが属するグループに対応した前記事前情報を受け付けた際に、受け付けた前記事前情報が他のグループに対応する事前情報として既に保持されている場合、または未だ前記他のグループに対応する事前情報として保持されてはいないが前記他のグループに対応する事前情報として保持するために事前情報を検証する処理を行っている状態である場合は、前記ユーザーからの指示に伴う登録処理を行わないことを特徴とする請求項１または２に記載の第２の情報処理システム。
  4. 受け付けた前記事前情報を用いて行われる前記検証は、前記ユーザーと同じグループに属するユーザーの前記ユーザー認証処理が成功したことに応じて前記第１の情報処理システムにより発行される認可情報に対しても行われることを特徴とする請求項１乃至３の何れか１項に記載の第２の情報処理システム。
  5. 前記第２の情報処理システムは、データをグループ毎に管理するマルチテナント構成の情報処理システムであって、前記既に保持している前記事前情報は、例外としてグループ間で共有するデータとして管理することを特徴とする請求項１乃至４の何れか１項に記載の第２の情報処理システム。
  6. ユーザー認証処理を行う第１の情報処理システムを登録するための画面であって、前記事前情報を受け付ける必要がない第１の情報処理システムをユーザーが選択した場合は、保持させる前記事前情報を指定することが不可能であり、前記事前情報を受け付ける必要がある第１の情報処理システムをユーザーが選択した場合は、保持させる前記事前情報を指定することが可能である画面を、ユーザーが操作するクライアントに送信することを特徴とする請求項１乃至５の何れか１項に記載の第２の情報処理システム。
  7. 前記ユーザーの指示に従い前記登録手段により登録された第１の情報処理システムの一覧をユーザーが操作するクライアントに送信し、
    前記一覧の中から選択された第１の情報処理システムをユーザー認証処理を行う第１の情報処理システムとして設定し、前記ユーザーからの未認証のアクセスがあった場合は、設定された当該第１の情報処理システムでユーザー認証処理を行わせるため、前記クライアントを当該第１の情報処理システムへアクセスさせることを特徴とする請求項１乃至６の何れか１項に記載の第２の情報処理システム。
  8. ユーザーから入力されたユーザー認証情報を用いたユーザー認証処理を行う第１の情報処理システムと通信可能な第２の情報処理システムにおける制御方法であって、
    前記ユーザー認証処理が成功したことに応じて前記第１の情報処理システムにより発行され送信される認可情報を、前記第１の情報処理システムにより発行されたことを証明するための電子証明書を少なくとも含む事前情報を用いて署名検証する検証ステップと、
    前記検証の結果、送信された前記認可情報が前記第１の情報処理システムにより発行された認可情報であることが少なくとも確認された場合に、前記ユーザー認証処理を行うことなくサービスを提供する提供ステップと、
    ユーザー認証処理を行う第１の情報処理システムを登録する指示を前記ユーザーから受け付けた際に、該第１の情報処理システムが前記事前情報をグループ毎に管理する情報処理システムであるか、または前記事前情報を複数のグループで共有させて管理する情報処理システムであるかを判断する判断ステップと、
    前記判断ステップにおいて該第１の情報処理システムが前記事前情報をグループ毎に管理する情報処理システムであると判断された場合は、前記事前情報を受け付け可能な第１の方法で前記ユーザーのテナントＩＤと該第１の情報処理システムのエンティティＩＤと受け付けた前記事前情報とを関連付けて保存する登録処理を行い、前記判断ステップにおいて該第１の情報処理システムが前記事前情報を複数のグループで共有させて管理する情報処理システムであると判断された場合は、前記事前情報を受け付け不可能な第２の方法で前記ユーザーのテナントＩＤと該第１の情報処理システムのエンティティＩＤと予め保有する前記事前情報とを関連付けて保存する登録処理を行う登録ステップと、を含む制御方法。
  9. ユーザーから入力されたユーザー認証情報を用いたユーザー認証処理を行う第１の情報処理システムと通信可能な第２の情報処理システムにおいて、
    前記ユーザー認証処理が成功したことに応じて前記第１の情報処理システムにより発行され送信される認可情報を、前記第１の情報処理システムにより発行されたことを証明するための電子証明書を少なくとも含む事前情報を用いて署名検証する検証ステップと、
    前記検証の結果、送信された前記認可情報が前記第１の情報処理システムにより発行された認可情報であることが少なくとも確認された場合に、前記ユーザー認証処理を行うことなくサービスを提供する提供ステップと、
    ユーザー認証処理を行う第１の情報処理システムを登録する指示を前記ユーザーから受け付けた際に、該第１の情報処理システムが前記事前情報をグループ毎に管理する情報処理システムであるか、または前記事前情報を複数のグループで共有させて管理する情報処理システムであるかを判断する判断ステップと、
    前記判断ステップにおいて該第１の情報処理システムが前記事前情報をグループ毎に管理する情報処理システムであると判断された場合は、前記事前情報を受け付け可能な第１の方法で前記ユーザーのテナントＩＤと該第１の情報処理システムのエンティティＩＤと受け付けた前記事前情報とを関連付けて保存する登録処理を行い、前記判断ステップにおいて該第１の情報処理システムが前記事前情報を複数のグループで共有させて管理する情報処理システムであると判断された場合は、前記事前情報を受け付け不可能な第２の方法で前記ユーザーのテナントＩＤと該第１の情報処理システムのエンティティＩＤと予め保有する前記事前情報とを関連付けて保存する登録処理を行う登録ステップと、を実行させるためのプログラム。
JP2012116625A 2012-05-22 2012-05-22 情報処理システム、その制御方法、およびそのプログラム。 Expired - Fee Related JP6066586B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2012116625A JP6066586B2 (ja) 2012-05-22 2012-05-22 情報処理システム、その制御方法、およびそのプログラム。
US13/898,166 US9027107B2 (en) 2012-05-22 2013-05-20 Information processing system, control method thereof, and storage medium thereof

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012116625A JP6066586B2 (ja) 2012-05-22 2012-05-22 情報処理システム、その制御方法、およびそのプログラム。

Publications (2)

Publication Number Publication Date
JP2013242776A JP2013242776A (ja) 2013-12-05
JP6066586B2 true JP6066586B2 (ja) 2017-01-25

Family

ID=49622616

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012116625A Expired - Fee Related JP6066586B2 (ja) 2012-05-22 2012-05-22 情報処理システム、その制御方法、およびそのプログラム。

Country Status (2)

Country Link
US (1) US9027107B2 (ja)
JP (1) JP6066586B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6041537B2 (ja) * 2012-06-01 2016-12-07 キヤノン株式会社 システムおよび制御方法およびプログラム
JP6256116B2 (ja) * 2014-03-10 2018-01-10 富士通株式会社 通信端末、セキュアログイン方法、及びプログラム
US11223613B2 (en) * 2014-05-02 2022-01-11 Cloudblue Llc Methods and systems for roles and membership management in a multi-tenant cloud environment
US9948468B2 (en) * 2014-12-23 2018-04-17 Mcafee, Llc Digital heritage notary
CN108769976B (zh) * 2018-06-01 2021-07-20 深圳市知赢科技有限公司 网络附着控制方法、装置和移动终端

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3312335B2 (ja) * 1999-07-30 2002-08-05 株式会社コムスクエア 利用者認証方法、利用者認証システムおよび記録媒体
US6959336B2 (en) * 2001-04-07 2005-10-25 Secure Data In Motion, Inc. Method and system of federated authentication service for interacting between agent and client and communicating with other components of the system to choose an appropriate mechanism for the subject from among the plurality of authentication mechanisms wherein the subject is selected from humans, client applications and applets
AU2003245887A1 (en) * 2002-05-24 2003-12-12 Telefonaktiebolaget Lm Ericsson (Publ) Method for authenticating a user to a service of a service provider
US7606560B2 (en) * 2002-08-08 2009-10-20 Fujitsu Limited Authentication services using mobile device
US7444522B1 (en) * 2002-09-18 2008-10-28 Open Invention Network, Llc Dynamic negotiation of security arrangements between web services
US7788711B1 (en) * 2003-10-09 2010-08-31 Oracle America, Inc. Method and system for transferring identity assertion information between trusted partner sites in a network using artifacts
GB0411861D0 (en) * 2004-05-27 2004-06-30 Koninkl Philips Electronics Nv Authentication of applications
KR100644616B1 (ko) * 2004-06-10 2006-11-10 세종대학교산학협력단 마크업 랭귀지 기반의 단일인증 방법 및 이를 위한 시스템
US9021253B2 (en) * 2004-07-02 2015-04-28 International Business Machines Corporation Quarantine method and system
US7463637B2 (en) * 2005-04-14 2008-12-09 Alcatel Lucent Public and private network service management systems and methods
US8365254B2 (en) * 2005-06-23 2013-01-29 Microsoft Corporation Unified authorization for heterogeneous applications
US20060294042A1 (en) * 2005-06-23 2006-12-28 Microsoft Corporation Disparate data store services catalogued for unified access
NO324315B1 (no) * 2005-10-03 2007-09-24 Encap As Metode og system for sikker brukerautentisering ved personlig dataterminal
US8166404B2 (en) * 2005-10-04 2012-04-24 Disney Enterprises, Inc. System and/or method for authentication and/or authorization
WO2007076459A2 (en) * 2005-12-21 2007-07-05 Digimarc Corporation Rules driven pan id metadata routing system and network
US7953758B2 (en) * 2006-11-10 2011-05-31 Ricoh Company, Ltd. Workflow management method and workflow management apparatus
JP2008176407A (ja) * 2007-01-16 2008-07-31 Toshiba Corp 生体認証システム、装置及びプログラム
CN101267445B (zh) * 2007-03-12 2013-04-17 华为技术有限公司 一种web业务实现系统、装置及方法
JP2009118110A (ja) 2007-11-06 2009-05-28 Nippon Telegr & Teleph Corp <Ntt> 認証システムのメタデータプロビジョニング方法、システム、そのプログラムおよび記録媒体
KR100953092B1 (ko) * 2007-11-06 2010-04-19 한국전자통신연구원 Ｓｓｏ서비스 방법 및 시스템
JP4847483B2 (ja) * 2008-03-10 2011-12-28 日本電信電話株式会社 個人属性情報提供システムおよび個人属性情報提供方法
JP4937171B2 (ja) * 2008-03-26 2012-05-23 みずほ情報総研株式会社 データ開示システム、アクセス制御設定方法、及びアクセス制御設定プログラム
JP4725666B2 (ja) * 2009-08-17 2011-07-13 コニカミノルタビジネステクノロジーズ株式会社 情報機器およびその運用支援方法
US8621654B2 (en) * 2009-09-15 2013-12-31 Symantec Corporation Using metadata in security tokens to prevent coordinated gaming in a reputation system
JP5531659B2 (ja) * 2010-02-12 2014-06-25 日本電気株式会社 属性情報交換システム、属性情報交換方法、属性情報交換プログラム
US8572710B2 (en) * 2010-03-18 2013-10-29 Microsoft Corporation Pluggable token provider model to implement authentication across multiple web services
CN102906776A (zh) * 2010-03-31 2013-01-30 帕特尔有限公司 一种用于用户和服务提供商之间双向认证的方法
JP4892093B1 (ja) * 2010-11-09 2012-03-07 株式会社東芝 認証連携システム及びｉｄプロバイダ装置
US20120278872A1 (en) * 2011-04-27 2012-11-01 Woelfel John Harold System and method of federated authentication with reverse proxy
US20130254840A1 (en) * 2012-03-26 2013-09-26 International Business Machines Corporation Providing multiple authentications to authenticate users with respect to a system and file systems offerred through the system

Also Published As

Publication number Publication date
US20130318590A1 (en) 2013-11-28
US9027107B2 (en) 2015-05-05
JP2013242776A (ja) 2013-12-05

Similar Documents

Publication Publication Date Title
JP6857065B2 (ja) 認証認可サーバー、リソースサーバー、認証認可システム、認証方法及びプログラム
CN110138718B (zh) 信息处理系统及其控制方法
US8627409B2 (en) Framework for automated dissemination of security metadata for distributed trust establishment
US9432353B2 (en) Serialized authentication and authorization services
JP6066647B2 (ja) デバイス装置、その制御方法、およびそのプログラム
JP6141041B2 (ja) 情報処理装置及びプログラム、制御方法
JP6061633B2 (ja) デバイス装置、制御方法、およびそのプログラム。
CN111316267B (zh) 使用委托身份的认证
EP3188454A1 (en) Shared registration system
JP6376869B2 (ja) データ同期システム、その制御方法、認可サーバー、およびそのプログラム
WO2016092630A1 (ja) 情報処理装置、情報処理装置の制御方法、情報処理システム、およびコンピュータプログラム
JPWO2011089712A1 (ja) 認証方法、認証システムおよび認証プログラム
JP2010531516A (ja) 安全でないネットワークを介する装置のプロビジョニング及びドメイン加入エミュレーション
US8806195B2 (en) User interface generation in view of constraints of a certificate profile
JP6066586B2 (ja) 情報処理システム、その制御方法、およびそのプログラム。
JP2020177537A (ja) 認証認可サーバー、クライアント、サービス提供システム、アクセス管理方法とプログラム
JP2016063417A (ja) Ｖｐｎアクセス制御システム、その作動方法及びプログラム、並びにｖｐｎルータ及びサーバ
JP2006031064A (ja) セッション管理システム及び管理方法
JP7099198B2 (ja) 管理装置、管理システム及びプログラム
JP2016115260A (ja) 権限移譲システム、権限移譲システムに用いられる認可サーバー、リソースサーバー、クライアント、媒介装置、権限移譲方法およびプログラム
JP5177505B2 (ja) シングルサインオンによるグループ内サービス認可方法と、その方法を用いたグループ内サービス提供システムと、それを構成する各サーバ
JP2016085638A (ja) サーバー装置、端末装置、システム、情報処理方法及びプログラム
JP2008287359A (ja) 認証装置及びプログラム
JP2013250894A (ja) マッピングサーバーとシングルサインオンシステム、マッピング機能提供方法
JP4882255B2 (ja) 属性証明書管理装置および方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150522

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160324

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160419

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160519

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161011

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161104

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20161122

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20161220

R151 Written notification of patent or utility model registration

Ref document number: 6066586

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

LAPS Cancellation because of no payment of annual fees