JP2021051552A - 情報処理装置およびプログラム - Google Patents

Abstract

【課題】２つの異なるシステムにおいて同一ユーザがそれぞれアカウントを登録している場合であって、そのユーザが２つのシステムのいずれかにおいて管理者権限を有していない場合であっても、２つの異なるシステムにおいて登録されている同一ユーザのアカウントどうしを対応付けることを可能とする。【解決手段】一時パスワード発行部３１は、ＡＢＣサービスの管理者からの操作に基づいて、この管理者により指定されたＡＢＣサービスにおけるテナントＩＤと対応づけられた一時パスワードを発行する。制御部３５は、ＸＹＺサービスの管理者が一時パスワードを提示してＡＢＣサービスとの連携を要求してきた際に、一時パスワード発行部３１により発行した一時パスワードと提示された一時パスワードとが一致した場合、この一時パスワードと対応付けられたＡＢＣサービスにおけるテナントＩＤと、ＸＹＺサービスの管理者が指定したテナントＩＤとを対応付ける。【選択図】図９

Description

本発明は、情報処理装置およびプログラムに関する。

特許文献１には、第１サービスシステムにおいて認証したユーザのテナント情報を取得して第２サービスシステムにクライアント登録を要求し、第２サービスシステムにおいてその該要求に従うクライアント登録と、認証したユーザのグループ情報とを含む登録結果を第１サービスシステムに送り、第１サービスシステムにおいてそのグループ情報と、認証したユーザのテナント情報を対応付けて記憶し、第２サービスシステムにおいて登録クライアントからの認証要求に応じて認証したユーザのグループ情報を含むＩＤ情報を第１サービスシステムに送り、第１サービスシステムにおいてそのＩＤ情報が示すアカウントに対応するアカウントの存在を判定し、存在しない場合に新たにアカウントを生成するようにしたサービス提供システムが開示されている。

特開２０１６−５７７３７号公報

本発明の目的は、２つの異なるシステムにおいて同一ユーザがそれぞれアカウントを登録している場合であって、そのユーザが２つのシステムのいずれかにおいて管理者権限を有していない場合であっても、２つの異なるシステムにおいて登録されている同一ユーザのアカウントどうしを対応付けることが可能な情報処理装置およびプログラムを提供することである。

［情報処理装置］
請求項１に係る本発明は、メモリとプロセッサを備え、
前記プロセッサは、
第１システムにおいて管理者権限を有する第１ユーザからの操作に基づいて、前記第１ユーザにより指定された第１アカウントと対応づけられた仮認証情報を発行し、
第２のシステムを利用する第２ユーザが前記仮認証情報を提示して前記第１システムとの連携を要求してきた際に、発行した仮認証情報と提示された仮認証情報とが一致した場合、前記仮認証情報と対応付けられた前記第１アカウントと前記第２ユーザが指定した第２アカウントとを対応付ける情報処理装置である。

請求項２に係る本発明は、前記メモリが、前記仮認証情報と、前記第１ユーザにより指定された第１アカウントとを対応付けて記憶し、
前記プロセッサは、前記第２ユーザが前記仮認証情報を提示して前記第１システムとの連携を要求してきた場合に、前記第２ユーザからの接続要求を前記第１のシステムにおけるログイン画面に転送し、
前記第２ユーザが前記第１システムにログインすることができた旨の情報が返信されてきた場合、前記メモリに記憶されている前記第１アカウントと、ログイン中の前記第２ユーザが使用している第２アカウントとを対応付ける請求項１記載の情報処理装置である。

請求項３に係る本発明は、前記メモリが、前記第２ユーザからの接続要求を前記第１のシステムにおけるログイン画面に転送する際に発行された確認情報を、前記仮認証情報と前記第１アカウントに対応付けて記憶し、
前記プロセッサは、前記第１システムから返信されてきた、前記第２ユーザが前記第１システムにログインすることができた旨の情報に、前記メモリに記憶されている確認情報が含まれている場合に、前記メモリに記憶されている前記第１アカウントと、ログイン中の前記第２ユーザが使用している第２アカウントとを対応付ける請求項２記載の情報処理装置である。

請求項４に係る本発明は、前記仮認証情報が、有効期限が設定されている認証情報であり、
前記プロセッサは、前記第２ユーザが前記仮認証情報を提示して前記第１システムとの連携を要求してきた場合でも、現在の日時が当該仮認証情報の有効期限を過ぎている場合、前記第２ユーザからの前記第１システムとの連携要求を拒否する請求項１記載の情報処理装置である。

請求項５に係る本発明は、前記第１アカウントが前記第１システムにおいて前記第１ユーザおよび前記第２ユーザが属するグループのグループ識別子であり、前記第２アカウントが前記第２システムにおいて前記第１ユーザおよび前記第２ユーザが属するグループのグループ識別子である請求項１から４のいずれか記載の情報処理装置である。

［プログラム］
請求項６に係る本発明は、第１システムにおいて管理者権限を有する第１ユーザからの操作に基づいて、前記第１ユーザにより指定された第１アカウントと対応づけられた仮認証情報を発行するステップと、
第２のシステムを利用する第２ユーザが前記仮認証情報を提示して前記第１システムとの連携を要求してきた際に、発行した仮認証情報と提示された仮認証情報とが一致した場合、前記仮認証情報と対応付けられた前記第１アカウントと前記第２ユーザが指定した第２アカウントとを対応付けるステップとをコンピュータに実行させるためのプログラムである。

請求項１に係る本発明によれば、２つの異なるシステムにおいて同一ユーザがそれぞれアカウントを登録している場合であって、そのユーザが２つのシステムのいずれかにおいて管理者権限を有していない場合であっても、２つの異なるシステムにおいて登録されている同一ユーザのアカウントどうしを対応付けることが可能な情報処理装置を提供することができる。

請求項２に係る本発明によれば、２つの異なるシステムにおいて同一ユーザがそれぞれアカウントを登録している場合であって、そのユーザが２つのシステムのいずれかにおいて管理者権限を有していない場合であっても、２つの異なるシステムにおいて登録されている同一ユーザのアカウントどうしを対応付けることが可能な情報処理装置を提供することができる。

請求項３に係る本発明によれば、確認情報を用いずに第１アカウントと第２アカウントとの対応付けを行う場合と比較して、誤った第１アカウントを第２アカウントと対応付けてしまう可能性を低減することが可能な情報処理装置を提供することができる。

請求項４に係る本発明によれば、仮認証情報に有効期限を設けない場合と比較して、第１アカウントと第２アカウントとの対応付けが不正に行われる可能性を低減することが可能な情報処理装置を提供することができる。

請求項５に係る本発明によれば、２つの異なるシステムにおいて同一のグループユーザがそれぞれアカウントを登録している場合であって、そのグループユーザのうちの個人ユーザが２つのシステムのいずれかにおいて管理者権限を有していない場合であっても、２つの異なるシステムにおいて登録されている同一グループユーザのアカウントどうしを対応付けることが可能な情報処理装置を提供することができる。

請求項６に係る本発明によれば、２つの異なるシステムにおいて同一ユーザがそれぞれアカウントを登録している場合であって、そのユーザが２つのシステムのいずれかにおいて管理者権限を有していない場合であっても、２つの異なるシステムにおいて登録されている同一ユーザのアカウントどうしを対応付けることが可能なプログラムを提供することができる。

本発明の一実施形態の情報処理システムのシステム構成を示す図である。 Open ID Connectのシーケンス例を説明するための図である。 サービス提供サーバ４０に対して連携を許可するサービスのＵＲＬを登録する際の処理を説明するためのシーケンスチャートである。 マルチテナント構成の一例を説明するための図である。 ２つのサービスがマルチテナント構成においてＩＤ連携を行うとした場合の問題点を説明するための図である。 株式会社Ａにおけるユーザ構成例を説明するための図である。 ＡＢＣサービスとＸＹＺサービスのそれぞれにおいて管理者が異なる様子を説明するための図である。 本発明の一実施形態におけるサービス提供サーバ１０のハードウェア構成を示すブロック図である。 本発明の一実施形態におけるサービス提供サーバ１０の機能構成を示すブロック図である。 サービス提供サーバ１０によりＡＢＣサービス、ＸＹＺサービスという２つのサービスにおけるテナントＩＤを連携させるための全体シーケンスを示す図である。 ＡＢＣサービスの管理者であるユーザ００１による操作を説明するためのシーケンスチャートである。 ＡＢＣサービスにおいて登録されているユーザ管理テーブル例を示す図である。 ユーザ００１が連携許可するサービスのＵＲＬとしてＸＹＺサービスのＵＲＬを入力する様子を示す図である。 ユーザ００１の端末装置２０上に発行されたクライアントＩＤが表示される様子を示す図である。 ＡＢＣサービスにおける連携許可サービステーブルの一例を示す図である。 ＡＢＣサービスにより発行されたクライアントＩＤが、ユーザ００１によりＸＹＺサービスにおいて入力される様子を示す図である。 ユーザにより入力されたクライアントＩＤが登録された際の対応付け一時情報テーブルの一例を示す図である。 サービス提供サーバ１０により生成されるリダイレクト情報の一例を示す図である。 ＡＢＣサービスのログイン画面が表示された表示画面例を示す図である。 サービス提供サーバ４０により生成される返信情報例を示す図である。 一時パスワードが発行された際に、対応付け一時情報テーブルが更新される様子を示す図である。 発行された一時パスワードがユーザ００１の端末装置２０上に表示される際の表示画面例を示す図である。 発行された一時パスワードがユーザ００１からユーザ００２に通知される様子を説明するための図である。 サービス提供サーバ１０において登録されているユーザ管理テーブル例を示す図である。 ＸＹＺサービスの管理者であるユーザ００２による操作を説明するためのシーケンスチャートである。 ユーザ００２が一時パスワードをＸＹＺサービスに入力する際の表示画面例を示す図である。 一時パスワードが入力された際に対応付け一時情報テーブルが更新される様子を示す図である。 ユーザ００２の端末装置２０がリダイレクトされたことにより表示されるＡＢＣサービスのログイン画面例を示す図である。 サービス提供サーバ４０により生成される返信情報例を示す図である。 サービス提供サーバ４０からの返信情報と対応付け一時情報テーブルとのチェックを行う際の手順を説明するための図である。 サービス提供サーバ４０から受信した返信情報が条件を満たしている場合に、対応付け一時情報テーブルを更新する際の様子を説明するための図である。 サービス提供サーバ１０に記憶されるテナントＩＤ対応付けテーブルの一例を示す図である。

次に、本発明の実施の形態について図面を参照して詳細に説明する。

図１は本発明の一実施形態の情報処理システムのシステム構成を示す図である。

本発明の一実施形態の情報処理システムは、図１に示されるように、サービス提供サーバ１０、４０と、複数の端末装置２０とがインターネット３０により相互に接続された構成となっている。

ここで、サービス提供サーバ４０は、インターネット３０を介してＡＢＣサービスをユーザに対して提供している。そして、サービス提供サーバ４０は、ユーザ情報をＩＤトークンとして他のサービスに提供する機能を備えておりＩＤプロバイダとも呼ばれている。

また、サービス提供サーバ１０は、インターネット３０を介してＸＹＺサービスをユーザに対して提供している。そして、サービス提供サーバ１０は、ＩＤプロバイダであるサービス提供サーバ４０からのユーザ情報を利用して、ユーザに対して各種サービスを提供する情報処理装置であり、リソースサーバまたはサービスプロバイダとも呼ばれている。

このように複数のサービス提供サーバによりインターネット３０を介してサービスが提供されている場合、ユーザはそれぞれのサービス毎にアカウントを登録するのは面倒であるため、あるサービスのアカウントを利用して他のサービスの提供を受けることができるようなアカウントの相互乗り入れが行われている。

このようなアカウントの相互乗り入れは一般的にはＩＤ連携またはIdentify Federationと呼ばれている。このような機能を利用することにより、ユーザは多数のＩＤやパスワードを管理することなく、各種のクラウドサービスを利用することが可能となる。

このようなＩＤ連携を行うための汎用技術であるOpen ID Connectと呼ばれるシーケンスについて図２を参照して説明する。

まず、ステップＳ１０１において、ユーザが端末装置２０からサービス提供サーバ１０にアクセスして、ＡＢＣサービスのアカウントでログインすることを選択する。すると、サービス提供サーバ１０は、ステップＳ１０２において、サービス提供サーバ４０にリダイレクトするためのＵＲＬ(Uniform Resource Locatorの略)を返信する。

そして、端末装置２０は、ステップＳ１０３において、リダイレクトされたＵＲＬにアクセスすることによりサービス提供サーバ４０にアクセスする。その結果、サービス提供サーバ４０は、ステップＳ１０４において、端末装置２０に対してログイン画面を返信する。

そして、ステップＳ１０５において、ユーザが端末装置２０上に表示されたログイン画面にユーザＩＤ、パスワードの入力を行ってログインすると、サービス提供サーバ４０は、入力されたユーザＩＤおよびパスワードを用いて認証を行って認証が成功すると、ステップＳ１０６において、ユーザ情報を含むＩＤトークンを端末装置２０に返信する。

すると、端末装置２０は、ステップＳ１０７において、返信されたＩＤトークンをサービス提供サーバ１０に提示する。すると、サービス提供サーバ１０では、ステップＳ１０８において、端末装置２０から提示されたＩＤトークンが正規に発行されたものであるか否かを電子署名情報等により検証する。

そして、この検証においてＩＤトークンが正規に発行されたものであることが確認された場合、サービス提供サーバ１０は、ステップＳ１０９において、ユーザに対してログインを許可する。

このようなシーケンスにより、ユーザは、サービス提供サーバ１０により提供されるＸＹＺサービスのアカウントを保有していなくても、ＸＹＺサービスを利用することができるようになる。

ここで、ＩＤプロバイダは、マイクロソフト社や、グーグル社のような限られた企業により提供されたサーバであるため限定された数しか存在しないのに対して、リソースサーバは、多数存在している。そのため、セキュリティ上の観点から、予め登録されたリソースサーバのみがＩＤプロバイダと連携することができるよう制限されている場合がある。

このようにＩＤプロバイダであるサービス提供サーバ１０と連携可能なリソースサーバを事前に登録する際には、そのリソースサーバのＵＲＬをサービス提供サーバ４０に対して登録するような設定となっている場合がある。

このようにサービス提供サーバ４０に対して連携を許可するサービスのＵＲＬを登録する際の処理を図３のシーケンスチャートを参照して説明する。

ここで、サービス提供サーバ１０により提供されるＸＹＺサービスを、連携を許可するサービスとして登録する場合について説明する。この場合、ＡＢＣサービスの管理者権限を有するユーザ（以下、単に管理者と称する。）が、ステップＳ２０１において、端末装置２０を介してサービス提供サーバ４０に対してサービス提供サーバ１０のＵＲＬを登録する。

すると、サービス提供サーバ４０では、ステップＳ２０２において、このＵＲＬを連携許可サービステーブルに登録する。すると、あるユーザが、図２に示すようなＸＹＺサービスとＡＢＣサービスとの間でＩＤ連携を行うことができるようになる。

ここで、近年のクラウドサービスでは、１つの装置を用いて複数の顧客を対象にサービスを提供することが行われている。このようなサービスの提供方法は、マルチテナントと呼ばれている。

このようなマルチテナント構成例を図４に示す。図４では、ＡＢＣサービスとＸＹＺサービスの両方のサービスがともにマルチテナント構成となっている場合が示されている。

この図４に示した例では、ＡＢＣサービスとＸＹＺサービスのそれぞれにおいて、各テナントはテナントＩＤにより管理されている。

このような構成の場合、リソースサーバであるＸＹＺサービス側において、どのテナントが、ＩＤプロバイダのどのテナントと対応しているのかという対応情報が必要になる場合がある。

例えば、株式会社Ａに設置されている複合機の出力枚数情報がＸＹＺサービスにおいて管理されていて、株式会社Ａの所属部門情報がＡＢＣサービスにおいて管理されているような場合、複合機の出力枚数を部門別に集計しようとした場合、株式会社ＡのＸＹＺサービスにおけるテナントＩＤと、株式会社ＡのＡＢＣサービスにおけるテナントＩＤとを対応付ける必要がある。

具体的には、株式会社ＡのＸＹＺサービスにおけるテナントＩＤである「１２３Ａ」と、株式会社ＡのＡＢＣサービスにおけるテナントＩＤである「ｘｙｚ−Ａ」とを対応付ける必要がある。

ここで、上記で説明したようにＡＢＣサービスにおいてＸＹＺサービスとの連携を可能とするために、ＸＹＺサービスのＵＲＬを登録した場合、ＸＹＺサービス全体がＡＢＣサービスとの連携が許可されたことになる。つまり、図５に示すように、ＸＹＺサービスのＵＲＬである「https://xyzservice.com/re」をＡＢＣサービスに登録した場合、ＸＹＺサービスにおける全てのテナントがＡＢＣサービスと連携可能となってしまう。

その結果、株式会社ＢのＸＹＺサービスにおけるテナントＩＤと、株式会社ＡのＡＢＣサービスにおけるテナントＩＤとを対応付けることも可能となってしまうことになる。

ここで、このようなテナントＩＤを対応付ける手段としては、ＩＤプロバイダであるサービス提供サーバ４０にユーザをログインさせて、その際に発行されたＩＤトークンを用いる手段が利用されている。具体的には、図２に示したシーケンスにおけるステップＳ１０６において発行されたＩＤトークンにＩＤプロバイダにおけるテナント情報が含まれるため、リソースサーバであるサービス提供サーバ１０では、そのテナント情報におけるテナントＩＤと、自装置におけるおのユーザのテナントＩＤとを対応付けるような方法が用いられる。

ただし、このような方法を用いる場合、図６に示すように、社内の複数部署でそれぞれＸＹＺサービスを利用している場合、管理者００１がユーザ００２に対して連携利用を許可すると、許可していないユーザ００３も連携利用できるようになってしまう。これは、図３に示したように、管理者００１が設定できるのはＸＹＺサービス全体に対する許可設定のためだからである。

このような問題を回避するために、図２のステップＳ１０６に含まれるログインしたユーザが管理者か否かのフラグを確認し、管理者である場合にだけ処理を実行する方法も考えられる。しかし、この方法を用いる場合には、ＡＢＣサービスにおける管理者とＸＹＺサービスにおける管理者とが同一ユーザである必要がある。

つまり、本実施形態の情報処理システムでは、図７に示すように、ＡＢＣサービスとＸＹＺサービスの各サービスにおいて管理者が異なる状態においても、両管理者が許可したテナントに対してのみ対応付けを行いたい場合について説明する。つまり、図６に示したユーザ００３が管理者となっているテナントに対しては対応付けができないような状態としつつ、ユーザ００２が管理者となっているテナントに対してのみ対応付けを行ができるようにする。

次に、本実施形態の情報処理システムにおけるサービス提供サーバ１０のハードウェア構成を図８に示す。

サービス提供サーバ１０は、図８に示されるように、ＣＰＵ１１、メモリ１２、ハードディスクドライブ等の記憶装置１３、ネットワーク３０を介して外部の装置等との間でデータの送信及び受信を行う通信インタフェース（ＩＦと略す。）１４、タッチパネル又は液晶ディスプレイ並びにキーボードを含むユーザインタフェース（ＵＩと略す。）装置１５を有する。これらの構成要素は、制御バス１６を介して互いに接続されている。

ＣＰＵ１１は、メモリ１２または記憶装置１３に格納された制御プログラムに基づいて所定の処理を実行して、サービス提供サーバ１０の動作を制御する。なお、本実施形態では、ＣＰＵ１１は、メモリ１２または記憶装置１３内に格納された制御プログラムを読み出して実行するものとして説明するが、当該プログラムをＣＤ−ＲＯＭ等の記憶媒体に格納してＣＰＵ１１に提供することも可能である。

図９は、上記の制御プログラムが実行されることにより実現されるサービス提供サーバ１０の機能構成を示すブロック図である。

なお、以下の説明においては、リソースサーバであるサービス提供サーバ１０において、株式会社ＡのＡＢＣサービスにおけるテナントＩＤと、株式会社ＡのＸＹＺサービスにおけるテナントＩＤとを対応付けて記憶する場合を用いて説明する。

本実施形態のサービス提供サーバ１０は、図９に示されるように、一時パスワード発行部３１と、ユーザ管理テーブル記憶部３２と、認証処理部３３と、データ送受信部３４と、制御部３５と、対応付け一時情報テーブル記憶部３６と、テナントＩＤ対応付けテーブル記憶部３７とを備えている。

一時パスワード発行部３１は、第１システムであるＡＢＣサービスにおいて管理者権限を有するユーザからの操作に基づいて、このユーザにより指定されたＡＢＣサービスにおけるテナントＩＤと対応づけられた一時パスワードを発行する。ここで、一時パスワードとは、有効期限が設定されており継続的な仕様を前提としない仮認証情報である。

ユーザ管理テーブル記憶部３２は、各ユーザのユーザＩＤ、所属するグループのテナントＩＤ、パスワード、ユーザ種類の情報等が対応付けられたユーザ管理テーブルを記憶する。

認証処理部３３は、ＸＹＺサービスを利用しようとするユーザの認証処理を実行する。

データ送受信部３４は、端末装置２０やサービス提供サーバ４０との間においてデータの送受信を行う。

制御部３５は、第２のシステムであるＸＹＺサービスの管理者権限を有するユーザが一時パスワードを提示してＡＢＣサービスとの連携を要求してきた際に、一時パスワード発行部３１により発行した一時パスワードと提示された一時パスワードとが一致した場合、この一時パスワードと対応付けられたＡＢＣサービスにおけるテナントＩＤと、ＸＹＺサービスの管理者権限を有するユーザが指定したテナントＩＤとを対応付ける。

具体的には、制御部３５は、ＸＹＺサービスの管理者が一時パスワードを提示してＡＢＣサービスとの連携を要求してきた場合に、ＸＹＺサービスの管理者からの接続要求をリダイレクトすることによりＡＢＣサービスにおけるログイン画面に転送する。そして、制御部３５は、ＸＹＺサービスの管理者がＡＢＣサービスにログインすることができた旨の情報が返信されてきた場合、対応付け一時情報テーブル記憶部３６の対応付け一時情報テーブルにおいて記憶されているＡＢＣサービスにおけるテナントＩＤと、ログイン中のＸＹＺサービスの管理者が使用しているＸＹＺサービスのテナントＩＤとを対応付ける。

なお、本実施形態においては、ＸＹＺサービスにおける管理者権限を有するユーザが、ＡＢＣサービスの管理者権限を有するユーザから通知された一時パスワードを用いて、２つのサービスにおけるテナントＩＤの対応付けを行う場合について説明するが、ＸＹＺサービスにおける管理者権限を有するユーザの代わりにＸＹＺサービスを利用するユーザであっても同様の処理を行うことが可能である。

対応付け一時情報テーブル記憶部３６は、一時パスワードと、ＡＢＣサービスの管理者により指定されたＡＢＣサービスにおける株式会社ＡのテナントＩＤとを対応付ける対応付け一時情報テーブルを記憶する。なお、この対応付け一時情報テーブルは、ＸＹＺサービスの管理者からの接続要求をＡＢＣサービスにおけるログイン画面に転送する際に発行されたstateおよびnonceを、一時パスワードとＡＢＣサービスにおけるテナントＩＤに対応付けて記憶する。

ここで、stateおよびnonceとは、ユーザからの接続要求をリダイレクトすることによりサービス提供サーバ４０から返信されてきた返信情報が一連のセッションに基づくものであることを確認するための確認情報である。つまり、リダイレクト情報に含めたstateおよびnonceと、返信情報に含まれているstateおよびnonceが一致することを確認することにより、この返信情報が正規な処理に基づいて返信されたものであることを確認することができる。

つまり、制御部３５は、ＡＢＣサービスから返信されてきた、ＸＹＺサービスの管理者がＡＢＣサービスにログインすることができた旨の情報に、対応付け一時情報テーブルに記憶されているstateおよびnonceが含まれている場合に、対応付け一時情報テーブルに記憶されているＡＢＣサービスのテナントＩＤと、ログイン中のＸＹＺサービスの管理者が使用しているＸＹＺサービスのテナントＩＤとを対応付ける。

テナントＩＤ対応付けテーブル記憶部３７は、制御部３５により対応付けられたＡＢＣサービスにおけるテナントＩＤとＸＹＺサービスにおけるテナントＩＤとの対応関係をテナントＩＤ対応付けテーブルとして記憶する。

なお、一時パスワード発行部３１により発行される一時パスワードは、有効期限が設定されている認証情報である。そのため、制御部３５は、ＸＹＺサービスの管理者が一時パスワードを提示してＡＢＣサービスとの連携を要求してきた場合でも、現在の日時がその一時パスワードの有効期限を過ぎている場合、ＸＹＺサービスの管理者からのＡＢＣサービスとの連携要求を拒否する。

ここで、ＡＢＣサービスにおけるテナントＩＤとは、ＡＢＣサービスの管理者およびＸＹＺサービスの管理者が属するグループである株式会社ＡのＡＢＣサービスにおけるグループ識別子である。また、同様にＸＹＺサービスにおけるテナントＩＤとは、ＡＢＣサービスの管理者およびＸＹＺサービスの管理者が属するグループである株式会社ＡのＸＹＺサービスにおけるグループ識別子である。

次に、本実施形態の情報処理システムにおけるサービス提供サーバ１０の動作について図面を参照して詳細に説明する。

まず、サービス提供サーバ１０によりＡＢＣサービス、ＸＹＺサービスという２つのサービスにおけるテナントＩＤを連携させるための全体シーケンスを図１０に示す。

（１）まず、ＡＢＣサービスの管理者であるユーザ００１が、ＡＢＣサービスを操作して、ＸＹＺサービスとの連携許可を登録する。

（２）次に、ＡＢＣサービスの管理者であるユーザ００１が、ＸＹＺサービスを操作して、一時パスワードの発行処理を行う。

（３）そして、ユーザ００１が、発行した一時パスワードを、ＸＹＺサービスの管理者であるユーザ００２に、電子メールや電話等により通知する。

（４）最後に、ＸＹＺサービスの管理者であるユーザ００２が、ＸＹＺサービスを操作して、通知された一時パスワードを用いて、ＡＢＣサービスにおける株式会社ＡのテナントＩＤと、ＸＹＺサービスにおける株式会社ＡのテナントＩＤとを対応付ける処理を実行する。

以下においてはこの全体シーケンスにおける各処理の詳細について順次説明する。

最初に、上記で説明した全体シーケンスにおける（１）、（２）の処理であるＡＢＣサービスの管理者であるユーザ００１による操作について図１１のシーケンスチャートを参照して説明する。

なお、この説明の前にＡＢＣサービスにおいて登録されているユーザ管理テーブル例を図１２に示す。図１２を参照すると、ユーザ００１は、ユーザＩＤが「Ｕ００１＠ｉｄｐ．ｅｘａｍｐｌｅ．ｃｏｍ」、パスワードが「ｐｗ００１」、ユーザ種類が「管理者」、テナントＩＤが「１２３Ａ」となっているのが分かる。なお、この「１２３Ａ」というテナントＩＤは、株式会社ＡのＡＢＣサービスにおけるグループ識別子である。

また、図１２を参照すると、ユーザ００２は、ユーザＩＤが「Ｕ００２＠ｉｄｐ．ｅｘａｍｐｌｅ．ｃｏｍ」、パスワードが「ｐｗ００２」、ユーザ種類が「一般ユーザ」、テナントＩＤが「１２３Ａ」となっているのが分かる。つまり、ユーザ００１、ユーザ００２はともに株式会社Ａというグループに属するユーザである。

このようなユーザ登録が行われている状態において、ユーザ００１は、ステップＳ３０１において、端末装置２０からサービス提供サーバ４０にアクセスしてユーザＩＤおよびパスワードを入力してログインした後に、ステップＳ３０２において、連携許可を行うＸＹＺサービスのＵＲＬを登録するための処理を行う。このユーザ００１が連携許可するサービスのＵＲＬとしてＸＹＺサービスのＵＲＬを入力する様子を図１３に示す。図１３では、ユーザ００１が端末装置２０から「https://xyzservice.com/re」というＸＹＺサービスのＵＲＬを入力する様子が示されている。

このようなユーザ００１からの登録要求を受けたサービス提供サーバ４０は、ステップＳ３０３において、ＸＹＺサービスのＵＲＬを連携許可サービステーブルに登録する。

そして、サービス提供サーバ４０は、ステップＳ３０４において、クライアントＩＤを発行し、ステップＳ３０５においてユーザ００１の端末装置２０に送信する。

このようにしてユーザ００１の端末装置２０上に発行されたクライアントＩＤが表示される様子を図１４に示す。また、発行されたクライアントＩＤと、ＸＹＺサービスのＵＲＬと株式会社ＡのテナントＩＤとは、ＡＢＣサービスにおける連携許可サービステーブルにおいて対応付けて記憶される。この連携許可サービステーブルの一例を図１５に示す。

次に、ユーザ００１は、ステップＳ３０６において、ＸＹＺサービスのサービス提供サーバ１０にアクセスして、ステップＳ３０７において、発行されたクライアントＩＤを入力する。ユーザ００１によりクライアントＩＤが入力される様子を図１６に示す。図１６では、ユーザ００１が端末装置２０において、ＡＢＣサービスから発行されたクライアントＩＤをＸＹＺサービスにおいて入力する様子が示されている。

ここで、図１６に示した画面は、ユーザ００１がサービス提供サーバ１０の連携設定ＵＲＬにアクセスすることにより表示される画面であり、マルチテナント管理とは別管理で表示される画面である。つまり、ユーザ００１は、例えＸＹＺサービスにおけるアカウントを保持していなくても操作可能な画面となっている。

そして、サービス提供サーバ１０では、ユーザ００１から入力されたクライアントＩＤが対応付け一時情報テーブルに登録される。このように入力されたクライアントＩＤが登録された際の対応付け一時情報テーブルの一例を図１７に示す。

図１７に示された対応付け一時情報テーブルでは、クライアントＩＤとともにstate、nonce、有効期限、状態の各種情報が対応付けられているのが分かる。図１７に示されるように、クライアントＩＤが登録された際に、stateおよびnonceの情報が発行される。

すると、サービス提供サーバ１０は、ステップＳ３０８において、図１８に示すようなリダイレクト情報を生成してユーザ００１の端末装置２０に送信して、端末装置２０の接続先をリダイレクトさせる。

図１８に示されたリダイレクト情報は、リダイレクト先であるＡＢＣサービスのＵＲＬ、サービス提供サーバ１０において発行されたコード情報であるstateおよびnonce、クライアントＩＤ、リクエスト種別を特定するための情報、ＸＹＺサービスのＵＲＬから構成されている。

そして、ユーザ００１の端末装置２０がリダイレクトされたことにより表示される表示画面例を図１９に示す。図１９に示す表示画面では、ＡＢＣサービスのログイン画面が表示されている。そのため、ユーザ００１は、ステップＳ３０９において、このログイン画面にユーザＩＤおよびパスワードを入力してＡＢＣサービスにログインする。ここで、ＩＤプロバイダであるサービス提供サーバ４０は、ログイン時に入力されたユーザＩＤおよびパスワードが正しいこと、ログインしたユーザ００１の属するテナントのテナントＩＤと対応付けて、クライアントＩＤとＵＲＬが連携許可サービステーブルに登録されていることを確認する。

ここでは、図１５に示した連携許可サービステーブルにおいて、ログインしたユーザ００１の属するテナントのテナントＩＤ「１２３Ａ」、クライアントＩＤ「ｃｉｄ０００５」、ＵＲＬ「https://xyzservice.com/re」が登録されていることが確認される。

よって、ユーザ００１によるログイン処理は正常に行われ、サービス提供サーバ４０は、ステップＳ３１０において、図２０に示すような返信情報を含むリダイレクト情報を生成して端末装置２０に対して送信する。すると、端末装置２０は、ステップＳ３１１において、リダイレクト情報によって指定されたＵＲＬにアクセスすることによりサービス提供サーバ１０に返信情報を送信する。

ここで、図２０に示す返信情報には、株式会社ＡのＡＢＣサービスにおけるテナントＩＤ「１２３Ａ」、ユーザＩＤ「Ｕ００１＠ｉｄｐ．ｅｘａｍｐｌｅ．ｃｏｍ」、ユーザ種類「管理者」、state「１２３１２３」およびnonce「４５６４５６」の情報が含まれている。

すると、サービス提供サーバ１０は、この返信情報に対して以下のようなチェックを行う。

（１）返信情報が「ｉｄｐ．ｅｘａｍｐｌｅ．ｃｏｍ」により正しく署名されていること
（２）返信情報におけるユーザ種類が「管理者」であること
（３）返信情報におけるstateおよびnonceの情報が正しいこと
（４）対応付け一時情報テーブルにおける有効期限が過ぎていないこと
（５）対応付け一時情報テーブルにおける「状態」が「管理者ログイン中」であること

そして、上記の条件が全て満たされた場合、サービス提供サーバ１０は、ＩＤプロバイダであるサービス提供サーバ４０の管理者による連携許可の承認が得られたものであると判定して、ステップＳ３１２において、一時パスワードを発行して対応付け一時情報テーブルを更新する。

このようにして対応付け一時情報テーブルが更新される様子を図２１に示す。図２１を参照すると、一時パスワードが発行されたことにより、発行された一時パスワード「９８７９８７」が登録され、連携先テナントＩＤとしてＡＢＣサービスのテナントＩＤ「１２３Ａ」が登録され、「状態」が「管理者ログイン中」から「一時ＰＷ（パスワードの略）発行中」に変更されているのが分かる。

そして、このようにして発行された一時パスワードがユーザ００１の端末装置２０上に表示される際の表示画面例を図２２に示す。図２２に示した表示画面例では、一時パスワード「９８７９８７」の情報とともに、この一時パスワードの有効期限がユーザ００１に示されていること分かる。

そして、このように一時パスワードがサービス提供サーバ１０により発行されると、ユーザ００１は、図２３に示すように、ＸＹＺサービスの管理者であるユーザ００２に発行された一時パスワードを通知する。この一時パスワードの通知は、例えば、電子メール、ＦＡＸ、電話等の様々な方法を用いることができる。つまり、ユーザ００１とユーザ００２とは同じ場所にいる必要はなく、それぞれが異なる場所にいる場合でも本実施形態によるＩＤ連携の処理を実行することができる。

次に、ＸＹＺサービスの管理者であるユーザ００２が、ユーザ００１から通知された一時パスワードを用いて、２つのサービスにおけるテナントＩＤどうしを関連付ける際の処理について説明する。

なお、この説明の前にサービス提供サーバ１０において登録されているユーザ管理テーブル例を図２４に示す。図２４を参照すると、ユーザ００２は、ユーザＩＤが「Ｕ００２＠ｘｙｚｓｅｒｖｉｃｅ．ｃｏｍ」、パスワードが「ａｂｃａｂｃ」、ユーザ種類が「管理者」、テナントＩＤが「ｘｙｚ−Ａ」となっているのが分かる。なお、この「ｘｙｚ−Ａ」というテナントＩＤは、株式会社ＡのＸＹＺサービスにおけるグループ識別子である。

次に、図１０を参照して説明した全体シーケンスにおける（４）の処理である、ＸＹＺサービスの管理者であるユーザ００２による操作について図２５のシーケンスチャートを参照して説明する。

まず、ユーザ００２は、ステップＳ４０１において、端末装置２０を操作してサービス提供サーバ１０にアクセスして図２４に示したようなユーザＩＤおよびパスワードを入力するによりＸＹＺサービスにログインする。

そして、ログイン処理が行われた後に、ユーザ００２は、ステップＳ４０２において、端末装置２０を操作して、ユーザ００１から通知された一時パスワードをＸＹＺサービスに入力する。このようにユーザ００２が一時パスワードをＸＹＺサービスに入力する際の表示画面例を図２６に示す。

このようにして一時パスワードが入力されるとサービス提供サーバ１０では、入力された一時パスワードと同じ一時パスワードが対応付け一時情報テーブルに登録されていて、かつ、「状態」が「一時ＰＷ発行中」であるか否かを検索する。そして、同じ一時パスワードが登録されており、「状態」が「一時ＰＷ発行中」である場合、サービス提供サーバ１０は、図１８に示した構成と同様の構成のリダイレクト情報を生成する。

そして、サービス提供サーバ１０では、対応付け一時情報テーブルが更新される。このように一時パスワードが入力された際に対応付け一時情報テーブルが更新される様子を図２７に示す。

図２７を参照すると、一時パスワードが入力されたことにより対応付け一時情報テーブルでは新たな欄が設けられて、一時パスワード、クライアントＩＤ、「状態」が「ユーザログイン中」、期限、新たなstateおよびnonceが対応付けて記憶されているのが分かる。

次に、サービス提供サーバ１０は、ステップＳ４０３において、生成したリダイレクト情報をユーザ００２の端末装置２０に送信して、端末装置２０の接続先をリダイレクトさせる。

そして、ユーザ００２の端末装置２０がリダイレクトされたことにより表示される表示画面例を図２８に示す。図２８に示す表示画面では、ＡＢＣサービスのログイン画面が表示されている。そのため、ユーザ００２は、ステップＳ４０４において、このログイン画面にユーザＩＤおよびパスワードを入力してＡＢＣサービスにログインする。すると、ＩＤプロバイダであるサービス提供サーバ４０は、ユーザＩＤとパスワードを確認することによりユーザ００２の認証処理を実行し、認証処理が正常に行われると、ステップＳ４０５において、図２９に示すような返信情報を含むリダイレクト情報を生成して端末装置２０に対して送信する。すると、端末装置２０は、ステップＳ４０６において、リダイレクト情報によって指定されたＵＲＬにアクセスすることによりサービス提供サーバ１０に返信情報を送信する。

この図２９に示した返信情報には、ユーザ００２のユーザ情報が含まれており、株式会社ＡのＡＢＣサービスにおけるテナントＩＤ「１２３Ａ」、ユーザＩＤ「Ｕ００２＠ｉｄｐ．ｅｘａｍｐｌｅ．ｃｏｍ」、ユーザ種類「一般ユーザ」、state「５５５２２２」およびnonce「ｄｅｆ００６」の情報が含まれている。

すると、サービス提供サーバ１０は、この返信情報に対して以下のようなチェックを行う。

（１）返信情報が「ｉｄｐ．ｅｘａｍｐｌｅ．ｃｏｍ」により正しく署名されていること
（２）返信情報におけるstateおよびnonceの情報が正しいこと
（３）対応付け一時情報テーブルにおける有効期限が過ぎていないこと
（４）対応付け一時情報テーブルにおける「状態」が「ユーザログイン中」であること
（５）対応付け一時情報テーブルにおいて、同一の一時パスワードが登録された記録情報のうちの、「状態」が「一時ＰＷ発行中」である記録情報における連携先テナントＩＤが、サービス提供サーバ４０から返信された返信情報におけるテナントＩＤと一致すること

具体的には、サービス提供サーバ１０は、図３０に示すようなチェックを行う。

（１）まず、サービス提供サーバ４０からの返信情報に含まれるstateおよびnonceである「５５５２２２」と「ｄｅｆ００６」と一致する記録情報を対応付け一時情報テーブルから検索する。

（２）次に、この記録情報における一時パスワードを参照して「９８７９８７」という情報を取得する。

（３）そして、この「９８７９８７」という一時パスワードと同一の一時パスワードが登録されている記録情報を検索する。

（４）次に、検索により見つかった記録情報の連携先テナントＩＤ「１２３Ａ」を取得する。

（５）最後に、（４）において取得した連携先テナントＩＤ「１２３Ａ」が、返信情報におけるテナントＩＤ「１２３Ａ」と一致することを確認する。

図３０に示した返信情報と対応付け一時情報テーブルでは、上記の条件が満たされている。そのため、サービス提供サーバ１０では、対応付け一時情報テーブルが、図３１に示すように更新される。具体的には、「状態」が「一時ＰＷ発行中」であった記録情報における「状態」が「終了（管理者）」に変更され、「状態」が「ユーザログイン中」であった記録情報における「状態」が「終了（一般ユーザ）」に変更されるとともに連携先テナントＩＤとして「１２３Ａ」が登録される。

このような処理が行われた結果、サービス提供サーバ１０では、ステップＳ４０７において、ＡＢＣサービスにおける株式会社ＡのテナントＩＤ「１２３Ａ」と、ＸＹＺサービスにおける株式会社ＡのテナントＩＤ「ｘｙｚ−Ａ」との対応付けが行われる。

そして、このような対応付けが行われたことにより、サービス提供サーバ１０におけるテナントＩＤ対応付けテーブルでは、図３２に示すように、自装置における株式会社ＡのテナントＩＤ「ｘｙｚ−Ａ」と対応付けて、連携先であるサービス提供サーバ４０のテナントＩＤ「１２３Ａ」が連携先テナントＩＤとして登録される。

上記各実施形態において、プロセッサとは広義的なプロセッサを指し、汎用的なプロセッサ（例えばＣＰＵ：Central Processing Unit、等）や、専用のプロセッサ（例えばＧＰＵ：Graphics Processing Unit、ＡＳＩＣ：Application Specific Integrated Circuit、ＦＰＧＡ：Field Programmable Gate Array、プログラマブル論理デバイス等）を含むものである。

また上記各実施形態におけるプロセッサの動作は、１つのプロセッサによって成すのみでなく、物理的に離れた位置に存在する複数のプロセッサが協働して成すものであってもよい。また、プロセッサの各動作の順序は上記各実施形態において記載した順序のみに限定されるものではなく、適宜変更してもよい。

１０ サービス提供サーバ
１１ ＣＰＵ
１２ メモリ
１３ 記憶装置
１４ 通信インタフェース
１５ ユーザインタフェース装置
１６ 制御バス
２０ 端末装置
３０ インターネット
３１ 一時パスワード発行部
３２ ユーザ管理テーブル記憶部
３３ 認証処理部
３４ データ送受信部
３５ 制御部
３６ 対応付け一時情報テーブル記憶部
３７ テナントＩＤ対応付けテーブル記憶部
４０ サービス提供サーバ

Claims (6)

1. メモリとプロセッサを備え、
   前記プロセッサは、
   第１システムにおいて管理者権限を有する第１ユーザからの操作に基づいて、前記第１ユーザにより指定された第１アカウントと対応づけられた仮認証情報を発行し、
   第２のシステムを利用する第２ユーザが前記仮認証情報を提示して前記第１システムとの連携を要求してきた際に、発行した仮認証情報と提示された仮認証情報とが一致した場合、前記仮認証情報と対応付けられた前記第１アカウントと前記第２ユーザが指定した第２アカウントとを対応付ける、
   情報処理装置。
2. 前記メモリは、前記仮認証情報と、前記第１ユーザにより指定された第１アカウントとを対応付けて記憶し、
   前記プロセッサは、前記第２ユーザが前記仮認証情報を提示して前記第１システムとの連携を要求してきた場合に、前記第２ユーザからの接続要求を前記第１のシステムにおけるログイン画面に転送し、
   前記第２ユーザが前記第１システムにログインすることができた旨の情報が返信されてきた場合、前記メモリに記憶されている前記第１アカウントと、ログイン中の前記第２ユーザが使用している第２アカウントとを対応付ける請求項１記載の情報処理装置。
3. 前記メモリは、前記第２ユーザからの接続要求を前記第１のシステムにおけるログイン画面に転送する際に発行された確認情報を、前記仮認証情報と前記第１アカウントに対応付けて記憶し、
   前記プロセッサは、前記第１システムから返信されてきた、前記第２ユーザが前記第１システムにログインすることができた旨の情報に、前記メモリに記憶されている確認情報が含まれている場合に、前記メモリに記憶されている前記第１アカウントと、ログイン中の前記第２ユーザが使用している第２アカウントとを対応付ける請求項２記載の情報処理装置。
4. 前記仮認証情報は、有効期限が設定されている認証情報であり、
   前記プロセッサは、前記第２ユーザが前記仮認証情報を提示して前記第１システムとの連携を要求してきた場合でも、現在の日時が当該仮認証情報の有効期限を過ぎている場合、前記第２ユーザからの前記第１システムとの連携要求を拒否する請求項１記載の情報処理装置。
5. 前記第１アカウントが前記第１システムにおいて前記第１ユーザおよび前記第２ユーザが属するグループのグループ識別子であり、前記第２アカウントが前記第２システムにおいて前記第１ユーザおよび前記第２ユーザが属するグループのグループ識別子である請求項１から４のいずれか記載の情報処理装置。
6. 第１システムにおいて管理者権限を有する第１ユーザからの操作に基づいて、前記第１ユーザにより指定された第１アカウントと対応づけられた仮認証情報を発行するステップと、
   第２のシステムを利用する第２ユーザが前記仮認証情報を提示して前記第１システムとの連携を要求してきた際に、発行した仮認証情報と提示された仮認証情報とが一致した場合、前記仮認証情報と対応付けられた前記第１アカウントと前記第２ユーザが指定した第２アカウントとを対応付けるステップと、
   をコンピュータに実行させるためのプログラム。

Images