JP2016057737A - サービス提供システム及びこれに用いる管理サーバー及び管理方法 - Google Patents

Abstract

【課題】 クラウドサービスで連携元サービスのアカウントが初めて連携を行う時、両サービス共に複数組織のユーザーに利用されていると、連携先のどの組織にアカウントを作成してよいか判別出来ない。
【解決手段】 第一サービスシステムで、認証したユーザーのテナント情報を取得し、第二サービスシステムにクライアント登録を要求し、第二サービスシステムで、該要求に従うクライアント登録と、認証したユーザーのグループ情報とを含む登録結果を第一サービスシステムに送り、第一サービスシステムで、該グループ情報と、認証したユーザーのテナント情報を対応付けて記憶し、第二サービスシステムで、登録クライアントからの認証要求に応じて認証したユーザーのグループ情報を含むＩＤ情報を第一サービスシステムに送り、第一サービスシステムで、該ＩＤ情報が示すアカウントに対応するアカウントの存在を判定し、存在しない場合に新たにアカウントを生成する。
【選択図】 図１

Description

本発明は、複数のサービスが連携しており、連携元サービスにはアカウントがあるが、連携先サービスには連携対応するアカウントがない、という場合に、自動で連携先サービスに連携用アカウントを作成し、サービス連携を提供するシステム及び方法に関する。

近年、クラウドサービスと呼ばれるインターネットを介してソフトウェアの機能を提供するシステムが注目を集めている。最近では、個々のクラウドサービスが連携して、新しいシステムを提供するケースが増えている。また、クラウドサービス同士だけではなく、企業内に設置された端末、例えばＰＣ、タブレットや画像形成装置が、インターネット上のクラウドサービスと連携し、ユーザーに機能を提供するケースも増えている。

ここで、企業内端末やクラウドサービスを利用する際には、不正利用の防止やユーザー識別のために、通常、ユーザー認証が必要となる。そのため、ユーザーが企業内端末とクラウドサービスを連携させる場合や、クラウドサービス同士を連携させる場合には、複数回認証情報の入力を求められ、利便性にかけるという課題がある。

この課題を解決する手段として、複数の認証システム間で連携することで、１度の認証の結果によって複数の認証を受けることができるシングルサインオン技術の利用が広まっている。例えば、Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＳＡＭＬ）プロトコルや、ＯｐｅｎＩＤ Ｆｏｕｎｄａｔｉｏｎが規定しているＯｐｅｎＩＤ Ｃｏｎｎｅｃｔといった技術（非特許文献１）が知られている。

また、ユーザーの認証情報によって連携するのではなく、連携先のシステムのアクセス権に限り、連携元のシステムに対してユーザーのアクセス権限を委譲してサービス連携を行う、認可連携という方式も利用されている。認可連携としては、ＯＡｕｔｈプロトコルや、前述のＯｐｅｎＩＤ Ｃｏｎｎｅｃｔといった技術が知られている。

ここで、認証連携、認可連携のどちらの場合でも、連携を行うためには連携元サービスと連携先サービスの両方に連携用アカウントが必要となる。そのため、連携元のユーザーが増える度に、連携先のクラウドサービス側にアカウントを作成する必要があり、管理者の負担が大きくなるという課題がある。

この課題を解決する手段として、ユーザーが初めてサービスを利用する時に、自動でアカウントを作成し、連携を行うＪｕｓｔ−Ｉｎ−Ｔｉｍｅプロビジョニング（以下「ＪＩＴプロビジョニング」）という技術が知られている。このＪＩＴプロビジョニングの実現方法として、特許文献１の方法が提案されている。これら従来技術では、前もって管理者が連携元サービスの属性と連携先サービスの属性との対応付けを行っておき、ＪＩＴプロビジョニング時にはこの属性対応付け情報に従い、連携先サービスにアカウントを作成する。

特開２００４−３０２９０７

"ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ Ｃｏｒｅ １．０"、Ｎ．Ｓａｋｉｍｕｒａ、Ｊ．Ｂｒａｄｌｅｙ、Ｍ．Ｊｏｎｅｓ、Ｂ．ｄｅ Ｍｅｄｅｉｒｏｓ、Ｃ．Ｍｏｒｔｉｍｏｒｅ、２０１４年２月２５日、＜ＵＲＬ ｈｔｔｐ：／／ｏｐｅｎｉｄ．ｎｅｔ／ｓｐｅｃｓ／ｏｐｅｎｉｄ−ｃｏｎｎｅｃｔ−ｃｏｒｅ−１＿０．ｈｔｍｌ＞

クラウドサービスでは、共有のサーバー上に展開した同一のＷｅｂアプリケーションを複数の企業や組織に提供する「マルチテナントサービス」という形態をとっている。ここで「テナント」とは、従来の専用サーバーを用いてサービスを提供していた企業や組織の単位を意味する。また、クラウドサービスと連携する企業内端末も、複数のグループや組織のユーザーが利用する場合がある。ここで、連携元の企業内端末が複数組織によって利用されており、連携先のクラウドサービスがマルチテナントサービスであった場合、連携先のクラウドサービスがユーザーをどのテナントに作成すればよいか判断出来ない、という課題がある。もしユーザーがアクセス時にアカウントを作成するテナントを指定出来ると、連携先サービスの好きなテナントにアカウントを作成出来てしまうため、セキュリティ的に問題となる。また、管理者が企業内端末とクラウドサービスとの連携を設定する際に、企業内の組織とクラウドサービスのテナントとの対応付けを行っておく場合にも、設定が誤っていた場合には関係の無いテナントにアカウントが作成されてしまう。この場合にも、管理者が好きなテナントにアカウントを作成する設定が行えてしまうため、セキュリティ的に問題となる。
本願発明は、上述した課題を解決するＪＩＴプロビジョニングシステムを提供することを目的とする。

上記課題を解決するため、本発明は、第一の管理サーバーを備える第一のサービスシステムと、第二の管理サーバーを備える第二のサービスシステムとが互いに連携してサービスを提供するシステムであって、第一管理サーバーは、ユーザー認証を行ない、認証したユーザーが所属するテナントを示すテナント情報を取得する手段と、第二サービスシステムに対してクライアント登録要求を行なう手段とを備え、第二管理サーバーは、前記クライアント登録要求に従うクライアント登録と、前記認証したユーザーが所属するグループを示すグループ情報とを含む登録結果を第一管理サーバーに送る手段を備え、第一管理サーバーは、前記グループ情報を受け取り、受け取ったグループ情報と、前記認証したユーザーのテナント情報を対応付けて記憶する手段を備え、第二管理サーバーは、前記登録したクライアントからの認証要求に応じて認証したユーザーのグループ情報を含むＩＤ情報を第一管理サーバーに送る手段を備え、第一管理サーバーは、前記ＩＤ情報を受け取り、受け取ったＩＤ情報が示すアカウントに対応するアカウントの存在を判定する手段と、前記判定する手段により当該アカウントが存在しないと判定された場合に、新たにアカウントを生成する手段とを備えるサービス提供システムを提供する。

本発明により、管理者のログイン情報から自動で連携元の組織と連携先サービスのテナントとの紐付けが行われるため、連携先サービスがＪＩＴプロビジョニング時に、セキュアに連携用のアカウントを作成するテナントを判定できる。

本発明の実施の形態に係るシステムの全体構成を示す図である。 図１のシステムにおけるサーバーのハードウェア構成を示す図である。 図１のシステムにおけるアクセス管理サーバーのソフトウェア構成を示す図である。 図１のシステムにおけるリソースサーバーのソフトウェア構成を示す図である。 実施例１におけるクライアント登録処理のフローを示す図である。 実施例１におけるＯＰ登録画面の一例を示す図である。 実施例１におけるＪＩＴプロビジョニング処理のフローを示す図である。 実施例１におけるＪＩＴプロビジョニング処理で用いる画面の一例を示す図である。 実施例２におけるＪＩＴプロビジョニング処理のフローを示す図である。 実施例３におけるＪＩＴプロビジョニング処理のフローを示す図である。

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

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

ここで、インターネット上のサービスと連携を行うための手法として、ＯｐｅｎＩＤ Ｃｏｎｎｃｅｔという技術がある。ＯｐｅｎＩＤ Ｃｏｎｎｃｅｔを利用することで、複数サービス間でシングルサインオンによる連携や、認可連携が実現できる。

図１は、各種オンラインサービスが存在するサービス提供システムのネットワーク構成を示す図である。インターネット１００は、外部から接続可能なパブリックなネットワークである。イントラネット１０１は、外部から接続不可能なプライベートなネットワーク（例えばＬＡＮ）である。

ＲＰアクセス管理サーバー１０２は、ユーザーの認証情報および認可情報を管理するサービスシステムである。ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔにおいては、Ｒｅｌｙｉｎｇ Ｐａｒｔｙ（以下「ＲＰ」）と呼ばれる。リソースサーバー１０３は、印刷サービスや帳票サービスといったリソースサービスを提供しているオンラインサービスシステムである。リソースサーバー１０３は、インターネット１００を介したクライアント端末１０６あるいは不図示の外部サービスシステムからの要求に応じて、リソースサービスを提供する。なおリソースサーバー１０３に設置されるリソースサービスは１つでもよく、複数でもよい。

ここで、ＲＰアクセス管理サーバー１０２とリソースサーバー１０３が連携し、ＲＰサービスシステム１０４を提供する。なお、ＲＰアクセス管理サーバー１０２とリソースサーバー１０３は同一のサーバー上に構成されていてもよいし、同一のＬＡＮ上に構成されてもよいし、それぞれ個別のＬＡＮ上に構成されてもよい。また、実施例１において各サーバーは１台ずつ設置されているが、複数台で構成されていてもよい。

イントラネット１０５は、外部から接続不可能なプライベートなネットワーク（例えばＬＡＮ）である。クライアント端末１０６は、ＰＣや、スマートフォンやタブレットと呼ばれる携帯端末や、画像形成装置であり、Ｗｅｂブラウザーがインストールされている。

ＯＰアクセス管理サーバー１０７は、企業内ユーザーの認証情報および認可情報を管理するサービスシステムである。ＯｐｅｎＩＤ Ｃｏｎｎｃｅｔにおいては、ＯｐｅｎＩＤ Ｐｒｏｖｉｄｅｒ（以下「ＯＰ」）と呼ばれる。なお、端末１０６とＯＰアクセス管理サーバー１０７は同一のサーバー上に構成されてもよいし、同一のＬＡＮ上に構成されてもよい。また、ＯＰアクセス管理サーバー１０７は、ＲＰサービスシステム１０４に対して、ＯＰサービスシステム１０８を提供する。なお、ＯＰサービスシステム１０８は、不図示のリソースサーバーを含んでもよく、端末１０６を含んでもよい。また、実施例１において各サーバーは１台ずつ設置されているが、複数台で構成されてもよい。

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

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

図３は、ＲＰアクセス管理サーバー１０２およびＯＰアクセス管理サーバー１０７の内部構造を示すブロック図である。図３Ａに示すＲＰアクセス管理サーバー１０２において、要求処理部３００は、ＲＰアクセス管理サーバー１０２がインターネット１００及びイントラネット１０１を経由して受信したＲＰアクセス管理サーバーへの要求を処理する処理部である。また、要求処理部３００は、アクセス制御部３０１から返される応答データを呼び出し元に返す。アクセス制御部３０１は、データ管理部３０２から取得するデータに基づき、各サービスシステムからの認証および認可要求を処理する処理部である。また、アクセス制御部３０１はＪＩＴプロビジョニングのためにデータ管理部３０２に対して、アカウント追加を行う。データ管理部３０２は、ユーザーアカウントのデータや、認可情報を管理する。

図３Ｂに示すＯＰアクセス管理サーバー１０７において、要求処理部３１０は、ＯＰアクセス管理サーバーがイントラネット１０５を経由して受診したＯＰアクセス管理サーバーへの要求を処理する処理部である。また、要求処理部３１０は、アクセス制御部３１１から返される応答データを呼び出し元に返す。アクセス制御部３１１は、データ管理部３１２から取得するデータに基づき、各サービスシステムからの認証および認可要求を処理する処理部である。データ管理部３１２は、ユーザーアカウントのデータや、認可情報を管理する。

図４は、リソースサーバー１０３の内部構造を示すブロック図である。要求処理部４００は、インターネット１００を経由してリソースサービスへの要求を処理する処理部である。例えばリソースサービスが帳票サービスの場合、帳票データ生成要求及び帳票データ取得要求を受信する。また、要求処理部４００は、機能制御部４０１から返される処理結果を呼び出し元に返す。機能制御部４０１は、要求処理部４００が受信した要求に応じて必要な処理を行い、応答データを呼び出し元に返す。また、機能制御部４０１はイントラネット１０１経由でＯＰアクセス管理サーバー１０２に対して認証要求を送信し、認証結果を受信する。処理部４０２は、機能制御部４０１からの要求を受信して、要求に応じた処理を行い、機能制御部４０１に返す。例えば帳票サービスの場合、帳票データ生成要求を受信して、帳票データを生成する。

図５は、ＯＰサービスシステム１０８とＲＰサービスシステム１０４を連携させるために、ＯＰアクセス管理サーバー１０７にＲＰアクセス管理サーバー１０２の情報を登録する登録処理（以下「クライアント登録処理」）のフローである。なお本登録フロー実施時には、ＯＰサービスシステムおよびＲＰサービスシステムの両方にアカウントが用意されているものとする。

ステップＳ５０１において、端末１０６上のＷｅｂブラウザー（不図示）を用いて、ＲＰアクセス管理サーバー１０２にアクセスを行う。アクセスされたＲＰアクセス管理サーバー１０２は、ステップＳ５０２において認証処理を行う。ここでＲＰアクセス管理サーバー１０２は、ＲＰアクセス管理サーバー１０２のアカウントテーブルから、認証したアカウントの所属テナント情報を取得する。

表１ＡにＲＰアクセス管理サーバー１０２が管理しているアカウント情報の例を示す。本実施例では、ユーザーＩＤ「ａｄｍｉｎ＠１００２ＡＡ」で認証したものとする。この場合ＲＰアクセス管理サーバー１０２は、登録実行者の所属テナントとして「１００２ＡＡ」を取得する。なお、データ未格納のカラムについては後述する。

ステップＳ５０３において、ＲＰアクセス管理サーバー１０２は、後述のＯＰ登録画面６００から、登録先ＯＰ情報を受け付ける。ここで登録先ＯＰ情報には、必須情報としてＯＰアクセス管理サーバーのＲＰ登録エンドポイントのＵＲＩが含まれる。また、任意情報としてＯＰ名と認証エンドポイントＵＲＩが含まれる。本実施例では、ＲＰ登録エンドポイントＵＲＩとして「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ／ｒｅｇ」、ＯＰ名として「ＯＰ１」、認証エンドポイントＵＲＩとして「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ／ａｕｔｈ」を指定したものとする。

ステップＳ５０４において、ＲＰアクセス管理サーバー１０２は、自身のＲＰ情報からなるＲＰメタデータを用意し、ＲＰ登録エンドポイントＵＲＩへのリダイレクト指示と共に、端末１０６にクライアント登録要求を返す。このＲＰメタデータには、ＲＰアクセス管理サーバー１０２がＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ連携時のレスポンスを受け取るＵＲＩである、リダイレクトＵＲＩを含んでいる。本実施例では、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／００１．ｘｘ／ｒｅｓ」を指定したものとする。

ステップＳ５０５において、端末１０６上のＷｅｂブラウザーは、ＲＰアクセス管理サーバー１０２から受け取ったＲＰメタデータと共に、クライアント登録要求をリダイレクトする。ステップＳ５０６において、ＯＰアクセス管理サーバー１０７は認証処理を行う。ここでＯＰアクセス管理サーバー１０７は、ＯＰアカウント管理サーバー１０７のアカウントテーブルから、認証したアカウントの所属組織情報（以下、「グループ情報」）を取得する。

表２にＯＰアクセス管理サーバー１０７が管理しているアカウントの例を示す。本実施例では、ユーザーＩＤ「ａｄｍｉｎ２」で認証したものとする。この場合ＯＰアクセス管理サーバー１０７は、グループ情報として「グループＢ」を取得する。

ステップＳ５０７において、ＯＰアクセス管理サーバー１０７はクライアント登録を行い、登録結果をステップＳ５０６で受け取ったクライアント登録要求のレスポンスとして端末１０６に返す。ＯＰアクセス管理サーバー１０７は、クライアント登録時に、指定されたリダイレクトＵＲＩが登録済みかを確認し、未登録の場合にはクライアントＩＤを発行し、ＯＰアクセス管理サーバー１０７のＲＰテーブルに登録を行う。さらに、Ｘ．５０９標準仕様の秘密鍵と公開鍵の鍵ペアを生成して格納する。その上でＯＰアクセス管理サーバー１０７は、クライアント登録結果として登録情報をクライアント登録要求のレスポンスとして返す。具体的には、発行したクライアントＩＤと、Ｘ．５０９形式の証明書から抽出した公開鍵と、登録したリダイレクトＵＲＩと、ステップＳ５０６で取得したグループ情報をレスポンスとして返す。なお受け取ったリダイレクトＵＲＩが登録済みだった場合には、新規登録を行わずに登録済みのクライアント情報を利用してもよく、未登録の場合と同様に新規登録を行ってもよい。

表３にＯＰアクセス管理サーバー１０７のＲＰテーブルに登録する情報の例を示す。本実施例では、指定されたリダイレクトＵＲＩ「ｈｔｔｐｓ：／／００１．ｘｘ／ｒｅｓ」が登録済みであるため、クライアントの新規登録は行わず、登録済みのクライアントＩＤ「ＩＤ００１」を利用するものとする。この場合、ＯＰアクセス管理サーバー１０７はクライアントＩＤ「ＩＤ００１」と、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／００１．ｘｘ／ｒｅｓ」と、公開鍵「００１．ｃｅｒ」と、グループ情報「グループＢ」をレスポンスとして返す。

ステップＳ５０８において、端末１０６上のＷｅｂブラウザーは、ＲＰアクセス管理サーバー１０２から受け取ったレスポンスを、ＲＰアクセス管理サーバー１０２に対してリダイレクトする。ステップＳ５０９において、ＲＰアクセス管理サーバー１０２は、受け取ったクライアント登録結果を元に、ＲＰアクセス管理サーバー１０２のＯＰテーブルにＯＰ情報を登録する。その際、ＯＰへの認証要求を行う認証エンドポイントＵＲＩをＯＰＩＤとして登録する。認証エンドポイントＵＲＩは、ステップＳ５０３で受け付けてもよく、端末１０６のブラウザーを介してＯＰアクセス管理サーバーのホストに問い合わせを行って取得してもよい。さらに、受け取ったクライアント登録結果に含まれるグループ情報と、ステップＳ５０２で取得した取得したテナント情報を、ＲＰアクセス管理サーバー１０２のテナントマッピングテーブルに登録する。

表４にＲＰアクセス管理サーバー１０２のＯＰテーブルの例を示し、表５Ａにテナントマッピングテーブルに登録する情報の例を示す。本実施例では、認証エンドポイントＵＲＩが「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ／ａｕｔｈ」、ＯＰ名が「ＯＰ１」、クライアントＩＤが「ＩＤ００１」、リダイレクトＵＲＩが「ｈｔｔｐｓ：／／００１．ｘｘ／ｒｅｓ」となる。ＲＰアクセス管理サーバー１０２のＯＰテーブルにはこのＯＰが登録済みであるため、新規登録は行わない。一方でクライアントＩＤ「ＩＤ００１」、グループ情報「グループＢ」、テナント情報「１００２ＡＡ」はＲＰアクセス管理サーバー１０２のテナントマッピングテーブルに登録されていないため、この情報を新規登録する。

本実施例におけるクライアント追加後のテナントマッピングテーブルの情報の例を表５Ｂに示す。

図６は本実施例におけるＯＰ登録画面の例を示す図である。ＯＰ登録画面６００は、ＯＰ名入力部６０１、ＲＰ登録エンドポイントＵＲＩ入力部６０２、認証エンドポイントＵＲＩ入力部６０３、登録ボタン６０４、登録キャンセルボタン６０５から構成される。ＯＰ名入力部６０１および認証エンドポイントＵＲＩ入力部６０３は必須ではなく、項目が存在しなくてもよいし、空を指定してもよい。

図７は、クライアント登録処理が完了しているＯＰとＲＰ間で、ＪＩＴプロビジョニングを行う際のフローを示す図である。ステップＳ７０１において、端末１０６上のＷｅｂブラウザー（不図示）を用いて、ＲＰアクセス管理サーバー１０２にアクセスを行う。アクセスされたＲＰアクセス管理サーバー１０２は、ステップＳ７０２において、後述のＯＰ選択画面８００を表示し、認証要求を行うＯＰの選択を行う。ＯＰ選択画面では、前述のＲＰアクセス管理サーバー１０２のＯＰテーブルに登録されているＯＰから、認証先のＯＰが選択される。

ステップＳ７０３において、ＲＰアクセス管理サーバーは、選択されたＯＰのＯＰＩＤが示す認証エンドポイントＵＲＩへのリダイレクト指示と共に、端末１０６に認証要求を送る。認証要求には、登録されているクライアントＩＤと、登録されているリダイレクトＵＲＩと、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔを示すスコープ「ＯｐｅｎＩＤ」が含まれる。本実施例では、ＯＰＩＤ「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ／ａｕｔｈ」、ＯＰ名「ＯＰ１」を選択したものとする。この場合、認証エンドポイント「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ／ａｕｔｈ」に対して、クライアントＩＤ「ＩＤ００１」、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／００１．ｘｘ／ｒｅｓ」、スコープ「ＯｐｅｎＩＤ」を含む認証要求を送る。

ステップＳ７０４において、端末１０６上のＷｅｂブラウザーは、ＲＰアクセス管理サーバー１０２から受け取った認証要求をリダイレクトする。ステップＳ７０５において、ＯＰアクセス管理サーバー１０７は、認証要求のパラメーターを確認した上で、後述の認証画面８１０を表示してユーザー認証を行う。その上で、後述の認可確認画面８２０を表示してＲＰサービスへのユーザー情報提供の認可を行う。本実施例では、認証要求で受け取ったクライアントＩＤ「ＩＤ００１」、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／００１．ｘｘ／ｒｅｓ」であるクライアントが、ＯＰアクセス管理サーバー１０７のＲＰテーブルに登録されているため、認証を行う。その上で、「ｕｓｅｒ１」で認証し、認可を行ったものとする。

ステップＳ７０６において、ＯＰアクセス管理サーバー１０７はＩＤトークン（ＩＤ情報）を生成し、Ｘ．５０９形式の証明書から抽出した秘密鍵を利用して署名を行う。その上でＯＰアクセス管理サーバー１０７は、リダイレクトＵＲＩへのリダイレクト指示と共に、ステップＳ７０５で受けた認証要求のレスポンスとして、端末１０６に作成したＩＤトークンを送る。このＩＤトークンは、発行者情報ｉｓｓ、Ｓｕｂｊｅｃｔ識別子ｓｕｂ、ＩＤトークンの対象を示すａｕｄ、ＩＤトークン有効期限ｅｘｐ、ＩＤトークン発行時刻ｉａｔ、グループ情報からなる。なおＳｕｂｊｅｃｔ識別子ｓｕｂには、ステップＳ７０６で認証したアカウントのＵＵＩＤが設定される。

表７にＯＰアクセス管理サーバー１０７のＩＤトークンテーブルに登録する情報の例を示す。本実施例では、ｓｕｂには「ｕｓｅｒ１」のＵＵＩＤである「０００００００３」を設定したＩＤトークンが発行され、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／００１．ｘｘ／ｒｅｓ」にＩＤトークンが返される。

ステップＳ７０７において、端末１０６上のＷｅｂブラウザーは、ＯＰアクセス管理サーバー１０７から受け取ったレスポンスを、指定されたリダイレクトＵＲＩに対してリダイレクトする。ステップＳ７０８において、ＲＰアクセス管理サーバー１０２は、ＲＰアクセス管理サーバー１０２のＯＰテーブルに登録されている公開鍵を利用し、ＩＤトークンの検証を行う。

ステップＳ７０９において、ＲＰアクセス管理サーバー１０２は、ＩＤトークンを発行したＯＰのアカウントに対応するアカウントが登録されているかどうかを確認する。まずＲＰアクセス管理サーバー１０２のテナントマッピングテーブルから、ＩＤトークンのａｕｄと一致するクライアントＩＤかつ、ＩＤトークンのグループと一致するＯＰグループとなる情報を検索し、ＲＰテナントＩＤを取得する。その上で、ＲＰアクセス管理サーバー１０２のアカウントテーブルから、取得したＲＰテナントＩＤに一致するテナント、かつ、ＩＤトークンのｓｕｂと一致するＯＰ側ＵＵＩＤとなるアカウントが存在するかどうかを確認する。もし対応するアカウントが登録されていた場合には、ステップＳ７１０に進み、そのアカウントが実行しているものとしてＲＰサービスを提供する。もしアカウントがなかった場合には、ステップＳ７１１に進む。

本実施例では、ＲＰアクセス管理サーバー１０２のテナントマッピングテーブルから、ａｕｄ「ＩＤ００１」、グループ「グループＢ」と一致するＲＰテナントＩＤ「１００２ＡＡ」が取得される。そしてＲＰアクセス管理サーバー１０２のアカウントテーブルから、テナント「１００２ＡＡ」、ＯＰ側ＵＵＩＤ「０００００００３」と一致するアカウントは存在しないと判断され、ステップＳ７１１へと進む。

ステップＳ７１１において、ＲＰアクセス管理サーバー１０２は、ＩＤトークンを発行したＯＰのアカウントに対応するアカウントを作成する。この場合、ステップＳ７１０で取得したテナントに対し、システムが自動で決定したユーザーＩＤとパスワードでアカウントを作成する。その上で、ＲＰアクセス管理サーバー１０２のアカウントテーブルのＯＰ側ＵＵＩＤに、ＩＤトークンのｓｕｂの値を保存する。その後、ステップＳ７１０に進み、作成したアカウントが実行しているものとしてＲＰサービスを提供する。

本実施例では、テナント「１００２ＡＡ」にユーザーＩＤ「ａｕｔｏ１＠１００２ＡＡ」、パスワード「１２３４５」のアカウントを作成し、ＯＰ側ＵＵＩＤに「０００００００３」を登録する。アカウント追加後のアカウントテーブルの例を表１Ｂに示す。

図８は、本実施例におけるＪＩＴプロビジョニングを行う際に利用する画面を示す図である。図８Ａに示すＯＰ選択画面８００は、ＯＰ選択部８０１、選択ボタン８０２から構成される。ＯＰ選択部８０１には、ＲＰアクセス管理サーバー１０２のＯＰテーブルに登録されているＯＰ一覧が表示され、１つのＯＰが選択される。図８Ｂに示す認証画面８１０は、ユーザーＩＤ入力部８１１と、パスワード入力部８１２、認証ボタン８１３、認証キャンセルボタン８１４から構成される。図８Ｃに示す認可確認画面８２０は、認可内容表示部８２１と、認可ボタン８２２、認可キャンセルボタン８２３から構成される。

上に記載した実施例１のサービス連携方法により、管理者の認証情報からＯＰのグループとＲＰのテナントが自動で対応付けられ、ＪＩＴプロビジョニング時にＲＰのアカウントを作成するテナントが自動で決定される。これにより、複数組織のユーザーが利用するＯＰとマルチテナントサービスのＲＰとでＪＩＴプロビジョニングを行う際に、セキュアにＲＰの所属テナントを決定できる。

＜実施例２＞
次に、ＲＰにおいてテナント単位でアカウント数の上限が管理されている場合の処理について説明する。クラウドサービスにおいて、アカウント数で契約を行い、サービス提供を行う形態が知られている。このような形態の場合、ＪＩＴプロビジョニングによって自動でアカウントを作成しようとした際に、アカウント数が上限に達していてアカウントが作成できない、という場合が考えられる。実施例２では、テナント単位でアカウント数の管理をしている場合のＪＩＴプロビジョニングを実現する方式について説明する。

図９は、アカウント数の上限管理を行っているＲＰにおいて、ＪＩＴプロビジョニングを行う際のフローを示す図である。ステップＳ７０１からステップＳ７１０までは、図７で説明したフローと同じである。

ステップＳ９０１において、ＲＰアクセス管理サーバー１０２は、ＲＰアクセス管理サーバー１０２のアカウント数管理テーブルから、対象テナントの現在の利用アカウント数を確認する。もし利用アカウント数が上限未満だったならば、ステップＳ７１１に進み、アカウントを作成してＯＰ側ＵＵＩＤを設定する。もし利用アカウント数が上限に達していたならば、ステップＳ９０２に進む。

表８にＲＰアクセス管理サーバー１０２のアカウント数テーブルに登録する情報の例を示す。本実施例では、ＯＰアクセス管理サーバー１０２のアカウントテーブルに登録されている「ｕｓｅｒ２」で認証を行い、ＩＤトークンを発行したものとする。ステップＳ７０９において、ＲＰテナントが「１００２ＡＡ」と判断され、ＲＰアクセス管理サーバー１０２のアカウント数テーブルから、「１００２ＡＡ」は契約アカウント数「１０」、利用アカウント数「１０」と判定される。アカウント数が上限に達していたため、ステップＳ９０２に進む。

ステップＳ９０２において、ＲＰアクセス管理サーバー１０２は、アカウント作成の判定を行う。本実施例では、アカウント数上限時の対応について、ＲＰアクセス管理サーバー１０２上で事前に設定を行い、テナント単位で管理する。アカウント数が上限に達していた場合の対応としては、利用されていないアカウントを削除または無効化して新アカウントを作成する、新アカウントを作成せずに処理を失敗させる、といった内容が選択できる。もし既存のアカウントを操作して新アカウントを作成する場合には、ステップＳ９０３に進む。もし新アカウントを作成しない場合には、ステップＳ９０４に進む。

なお、アカウントを削除または無効化する場合には、アカウントが利用されていないと判断する期間を合わせて設定できる。アカウントが利用されていないかどうかの判断は、最後にログインした時刻が設定された期間より前か否かで判断する。もしこの期間が設定されていた場合には、対象テナントの各ユーザーが最後にログインした時刻から、削除または無効化するアカウントが存在するかどうかを確認する。削除または無効化するアカウントが存在しなかった場合には、アカウントが作成出来ないので、ステップＳ９０４に進む。

表９にアカウント数上限管理時のテナントマッピングテーブル、表１０Ａにアカウント数上限管理時のアカウントテーブルに登録する情報の例を示す。本実施例では、アカウント数上限管理時のテナントマッピングテーブルにＲＰテナントＩＤ「１００２ＡＡ」は上限時「無効化」、期間「３０日」が設定されているので、アカウント無効化と判定される。続いてアカウント上限時のアカウントテーブルから、テナント「１００２ＡＡ」で最終ログイン日時が３０日以上前のアカウントが存在するかどうか確認する。現在日時が「２０１４／５／１ ０：００」とすると、アカウント「ａｕｔｏ１＠１００２ＡＡ」と「ａｕｔｏ２＠１００２ＡＡ」が、最終ログイン日時が３０日以上前となっている。

ステップＳ９０３において、ＲＰアクセス管理サーバー１０２は、ステップＳ９０２で判定した内容に従ってアカウントの操作を行う。アカウント数上限管理時のアカウントテーブルから、対象となるアカウントを判定し、削除または無効化を行う。その後、ステップＳ７１１において、アカウントを作成してＯＰ側ＵＵＩＤの値を設定する。

本実施例では、テナント「１００２ＡＡ」で最終ログイン日時が３０日より前のアカウントの内、最終ログイン日時が最も古いアカウントである「ａｕｔｏ２＠１００２ＡＡ」が無効化対象アカウントとなる。ＲＰアクセス管理サーバー１０２は「ａｕｔｏ２＠１００２ＡＡ」を無効にし、アカウントテーブルのアカウント状態を無効にする。表１０Ｂにアカウント無効化後のアカウントテーブルに登録する情報の例を示す。

ステップＳ９０４において、ＲＰアクセス管理サーバー１０２は、アカウント数が上限に達していたためアカウントが作成出来ず、サービスが利用できないといったエラーを生成する。

実施例２の方法により、アカウント数が管理されているクラウドサービスにおいて、ユーザーが手動で処理することなく、利用していないアカウントをなくし、利用できるアカウント数を最適化できる。

＜実施例３＞
次に、ＯＰにおいてユーザーの所属グループが変更になった場合の処理について説明する。例えば、ＯＰが企業のイントラネット上にあり、組織単位でアカウントを管理している場合には、アカウントの所属グループが変更されることが考えられる。もしＯＰで認証したアカウントの所属グループが変更になったならば、ＲＰ側のアカウントが所属するテナントも、ＯＰの新グループに対応するテナントに変更される。このような場合に、ＪＩＴプロビジョニングでは、ＯＰの新グループに対応するテナントにアカウントがないと判断され、新たなアカウントが生成される。そのため、古いグループに対応するテナントにアカウントが残ったままになってしまう。実施例３では、アカウントのＯＰ所属グループが変更になった場合のＪＩＴプロビジョニングを実現する方式について説明する。

図１０は、ＯＰのユーザーアカウントの所属グループが変更になった場合に対応する、ＪＩＴプロビジョニングのフローを示す図である。ステップＳ７０１からステップＳ７１０までは、図７で説明したフローと同じである。

ステップＳ１００１において、ＲＰアクセス管理サーバー１０２は、アカウント作成の対象となるテナント以外のテナントに、対応するアカウントが存在するかどうか確認する。ＲＰアクセス管理サーバー１０２は、ステップＳ７０９で判定したテナント以外のテナントに、ＩＤトークンのｓｕｂと一致するＯＰ側ＵＵＩＤが登録されているアカウントが存在するかどうかを確認する。もしＯＰ側ＵＵＩＤが一致するアカウントが存在した場合、ステップＳ１００２に進む。もしＯＰ側ＵＵＩＤが一致するアカウントが存在しなかった場合、ステップＳ７１１に進み、アカウントを作成してＯＰ側ＵＵＩＤの値を設定する。

表１１Ａにグループ変更時のアカウントテーブルに登録する情報の例を示す。本実施例では、ＯＰアクセス管理サーバー１０２のアカウントテーブルに登録されているユーザーＩＤ「ｕｓｅｒ２」、ＵＵＩＤ「０００００００４」の所属グループを、「グループＢ」から「グループＡ」に変更したものとする。ＲＰアクセス管理サーバー１０２は、ステップＳ７０９にてＲＰテナントが「１００１ＡＡ」と判断されているので、「１００１ＡＡ」以外にＯＰ側ＵＵＩＤ「０００００００４」となるアカウントが登録されているかどうかを確認する。この場合、テナント「１００２ＡＡ」のユーザーＩＤ「ａｕｔｏ２＠１００２ＡＡ」に、ＯＰ側ＵＵＩＤ「０００００００４」が登録されているので、ステップＳ１００２に進む。

ステップＳ１００２において、ＲＰアクセス管理サーバー１０２は、アカウントの操作を行う。本実施例では、ＯＰグループ変更時の対応について、ＲＰアクセス管理サーバー１０２上で事前に設定を行い、テナント単位で管理する。グループ移動時の対応としては、アカウントを削除する、アカウントを無効化する、といった内容が選択できる。ＲＰアクセス管理サーバー１０２は、テナント単位で設定されている内容に従い、古いアカウントの削除または無効化を行う。なおアカウントを無効化した場合には、そのアカウントに設定されているＯＰ側ＵＵＩＤの値を削除する。

表１２にグループ変更時のテナントマッピングテーブルに登録する情報の例を示す。本実施例では、グループ変更時のテナントマッピングテーブルから、ＯＰ側ＵＵＩＤ「０００００００４」が登録されていたアカウントの所属テナント「１００２ＡＡ」の移動時の処理を確認する。ここではテナント「１００２ＡＡ」は移動時に「無効化」となっているため、ユーザーＩＤ「ａｕｔｏ２＠１００２ＡＡ」を無効化し、アカウントテーブルの更新を行う。また、表１１Ｂにグループ変更後のアカウントテーブルの情報の例を示す。

実施例３の方法により、ＯＰのアカウントの所属グループが変更になった場合に、ＲＰ上に無駄なアカウントを残すことなく、ＪＩＴプロビジョニングが行える。

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

１０２ ＲＰアクセス管理サーバー
１０６ 端末
１０７ ＯＰアクセス管理サーバー
３０１ アクセス制御部
３０２ データ管理部
３１１ アクセス制御部
３１２ データ管理部

Claims (10)

1. 第一の管理サーバーを備える第一のサービスシステムと、第二の管理サーバーを備える第二のサービスシステムとが互いに連携してサービスを提供するシステムであって、
   前記第一の管理サーバーは、ユーザー認証を行ない、認証したユーザーが所属するテナントを示すテナント情報を取得する手段と、前記第二のサービスシステムに対してクライアント登録要求を行なう手段とを備え、
   前記第二の管理サーバーは、前記クライアント登録要求に従うクライアント登録と、前記認証したユーザーが所属するグループを示すグループ情報とを含む登録結果を前記第一の管理サーバーに送る手段を備え、
   前記第一の管理サーバーは、前記グループ情報を受け取り、受け取ったグループ情報と、前記認証したユーザーのテナント情報を対応付けて記憶する手段を備え、
   前記第二の管理サーバーは、前記登録したクライアントからの認証要求に応じて認証したユーザーのグループ情報を含むＩＤ情報を前記第一の管理サーバーに送る手段を備え、
   前記第一の管理サーバーは、前記ＩＤ情報を受け取り、受け取ったＩＤ情報が示すアカウントに対応するアカウントの存在を判定する手段と、前記判定する手段により当該アカウントが存在しないと判定された場合に、新たにアカウントを生成する手段とを備えることを特徴とするサービス提供システム。
2. 前記第一の管理サーバーは、
   前記生成する手段によりアカウントを生成する場合に、テナントのアカウント数の上限に達しているかどうかを確認する手段と、
   前記確認する手段によりアカウント数が上限に達していると確認された場合に、既存のアカウントを操作するかどうかを判断する手段と、
   前記判断する手段により操作すると判断された場合、既存のアカウントを削除または無効化する手段と、
   をさらに備えることを特徴とする、請求項１に記載のサービス提供システム。
3. 前記第一の管理サーバーは、前記無効化する手段により既存のアカウントを削除または無効化してアカウントを生成するか、あるいはアカウントを作成しないかを、テナント単位で判断することを特徴とする、請求項２に記載のサービス提供システム。
4. 前記無効化する手段は、既存のアカウントを削除または無効化する場合、当該アカウントが利用されていない期間に応じて当該アカウントを削除または無効化することを特徴とする、請求項２に記載のサービス提供システム。
5. 前記第一の管理サーバーは、
   前記判定する手段により、前記ＩＤ情報が示すアカウントが当該アカウントに対応するテナントに存在しないと判定された場合、当該アカウントが当該テナントとは別のテナントに存在するかどうかを確認する手段と、
   前記確認する手段により、当該アカウントが前記別のテナントに存在すると確認された場合に、当該アカウントを削除または無効化する手段と、
   をさらに備えることを特徴とする、請求項１に記載のサービス提供システム。
6. 前記第一の管理サーバーは、前記無効化する手段により当該アカウントを削除するか無効化するかを、テナント単位で判断することを特徴とする、請求項５に記載のサービス提供システム。
7. 前記第一のサービスシステムは、ＲＰ（Ｒｅｌｙｉｎｇ Ｐａｒｔｙ）サービスシステムであり、前記第二のサービスシステムは、ＯＰ（ＯｐｅｎＩＤ Ｐｒｏｖｉｄｅｒ）サービスシステムであることを特徴とする、請求項１乃至６のいずれか１項に記載のサービス提供システム。
8. 第一のサービスシステムにおいて用いられる管理サーバーであって、前記第一のサービスシステムは第二のサービスシステムと互いに連携してサービスを提供し、
   前記管理サーバーは、
   ユーザー認証を行ない、認証したユーザーが所属するテナントを示すテナント情報を取得する手段と、
   前記第二のサービスシステムに対してクライアント登録要求を行なう手段と、
   前記第二のサービスシステムより、前記クライアント登録要求に従うクライアント登録と、前記認証したユーザーが所属するグループを示すグループ情報とを含む登録結果を受け取る手段と、
   前記受け取ったグループ情報と、前記認証したユーザーのテナント情報を対応付けて記憶する手段と、
   前記第二のサービスシステムより、前記登録したクライアントからの認証要求に応じて認証したユーザーのグループ情報を含むＩＤ情報を受け取る手段と、
   前記受け取ったＩＤ情報が示すアカウントに対応するアカウントの存在を判定する手段と、
   前記判定する手段により当該アカウントが存在しないと判定された場合に、新たにアカウントを生成する手段と、
   を備えることを特徴とする管理サーバー。
9. 第一のサービスシステムにおいて管理サーバーにより実行される管理方法であって、前記第一のサービスシステムは第二のサービスシステムと互いに連携してサービスを提供し、
   前記管理方法は
   ユーザー認証を行ない、認証したユーザーが所属するテナントを示すテナント情報を取得し、
   前記第二のサービスシステムに対してクライアント登録要求を行ない、
   前記第二のサービスシステムより、前記クライアント登録要求に従うクライアント登録と、前記認証したユーザーが所属するグループを示すグループ情報とを含む登録結果を受け取り、
   前記受け取ったグループ情報と、前記認証したユーザーのテナント情報を対応付けて記憶し、
   前記第二のサービスシステムより、前記登録したクライアントからの認証要求に応じて認証したユーザーのグループ情報を含むＩＤ情報を受け取り、
   前記受け取ったＩＤ情報が示すアカウントに対応するアカウントの存在を判定し、
   前記判定により当該アカウントが存在しないと判定された場合に、新たにアカウントを生成することを特徴とする管理方法。
10. コンピュータを、請求項１〜７のいずれか1項に記載のサービス提供システム、または請求項８に記載の管理サーバーに記載の各手段として機能させるためのプログラム。

Images